[BUG] <New Periodic Threshold> Occasionally, a pop-up error message appears; however, the error may disappear after refreshing the page or making changes.

[love01211]

Is there an existing issue for this?

• [x] I have searched the existing issues

Current Behavior

Expected Behavior

No response

Steps To Reproduce

1.New Periodic Threshold 2.input hreshold Rule 3.Preview 4.save 5.edit 6.Preview 7."Expression is not fully parsed, may have syntax errors or incomplete inputs"

Environment

HertzBeat version(s):1.7.3

Debug logs

No response

Anything else?

No response

[Duansg]

Is = the full-width equal sign ＝? Is there an error-prone threshold expression?

[love01211]

Is = the full-width equal sign ＝? Is there an error-prone threshold expression?

I’m sure I used the = sign; there were no issues at all when I first configured it.

[Duansg]

Is = the full-width equal sign ＝? Is there an error-prone threshold expression?

I’m sure I used the = sign; there were no issues at all when I first configured it.

I'm sorry, I haven't been able to reproduce this issue. Could you try to reproduce it? That way, you can provide me with more information.

[love01211]

• Template Change:

      - field: admin_status
        # change 1 -> 0
        type: 0
        i18n:
          zh-CN: 配置状态
          en-US: Config Status
      - field: oper_status
        # change 1 -> 0
        type: 0
        i18n:
          zh-CN: 当前状态
          en-US: Current Status

• error log： 2025-09-18 16:07:16.270 [periodic-alert-threshold-worker-0] ERROR org.apache.hertzbeat.alert.service.impl.DataSourceServiceImpl Line:90 - Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs 2025-09-18 16:08:16.270 [periodic-alert-threshold-worker-0] ERROR org.apache.hertzbeat.alert.service.impl.DataSourceServiceImpl Line:90 - Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs

• configure alert json file： hertzbeat_alertDefine_2025-09-18.json

[love01211]

• Template Change:

  - field: admin_status
    # change 1 -> 0
    type: 0
    i18n:
      zh-CN: 配置状态
      en-US: Config Status
  - field: oper_status
    # change 1 -> 0
    type: 0
    i18n:
      zh-CN: 当前状态
      en-US: Current Status
  

• error log： 2025-09-18 16:07:16.270 [periodic-alert-threshold-worker-0] ERROR org.apache.hertzbeat.alert.service.impl.DataSourceServiceImpl Line:90 - Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs 2025-09-18 16:08:16.270 [periodic-alert-threshold-worker-0] ERROR org.apache.hertzbeat.alert.service.impl.DataSourceServiceImpl Line:90 - Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs

• configure alert json file： hertzbeat_alertDefine_2025-09-18.json

@Duansg

[Duansg]

@love01211 hi, Could you provide your threshold expression?

[love01211]

@love01211 hi, Could you provide your threshold expression?

Of course： interfaces_oper_status == 2

[Duansg]

@love01211 hi, Could you provide your threshold expression?

Of course： interfaces_oper_status == 2

I verified the preview function and promql parsing, and they are all normal at present. Can you reproduce this abnormality?

[love01211]

@love01211 hi, Could you provide your threshold expression?

Of course： interfaces_oper_status == 2

I verified the preview function and promql parsing, and they are all normal at present. Can you reproduce this abnormality?

I don't know how to reproduce this issue, but I will try to set up a new Hertzbeat system. If I have a process for reproducing the issue, I will @you.

[Duansg]

@love01211 hi, Could you provide your threshold expression?

Of course： interfaces_oper_status == 2

I verified the preview function and promql parsing, and they are all normal at present. Can you reproduce this abnormality?

I don't know how to reproduce this issue, but I will try to set up a new Hertzbeat system. If I have a process for reproducing the issue, I will @you.

Okay, thanks.

[love01211]

@Duansg I think I've found the pattern: after configuring the alert rules, the backend error logs will show an error:

2025-09-18 17:28:43.236 [http-nio-1157-exec-8] ERROR org.apache.hertzbeat.alert.calculate.PeriodicAlertRuleScheduler Line:75  - Alert rule is null or rule id is null.

Then, after waiting for 30 minutes, the first error message appears: "Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs."

[Duansg]

@Duansg I think I've found the pattern: after configuring the alert rules, the backend error logs will show an error:

2025-09-18 17:28:43.236 [http-nio-1157-exec-8] ERROR org.apache.hertzbeat.alert.calculate.PeriodicAlertRuleScheduler Line:75  - Alert rule is null or rule id is null.

Then, after waiting for 30 minutes, the first error message appears: "Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs."

@love01211 Hi, thank you for your assistance and response. that's odd.

The purpose of this exception is to verify whether the expression has been fully consumed and to check for invalid expressions. However, the expression you provided appears to be parsed correctly.

Could you please export the data from hzb_alert_define to facilitate our further troubleshooting?

[love01211]

@Duansg I think I've found the pattern: after configuring the alert rules, the backend error logs will show an error:

2025-09-18 17:28:43.236 [http-nio-1157-exec-8] ERROR org.apache.hertzbeat.alert.calculate.PeriodicAlertRuleScheduler Line:75  - Alert rule is null or rule id is null.

Then, after waiting for 30 minutes, the first error message appears: "Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs."

@love01211 Hi, thank you for your assistance and response. that's odd.

The purpose of this exception is to verify whether the expression has been fully consumed and to check for invalid expressions. However, the expression you provided appears to be parsed correctly.

Could you please export the data from hzb_alert_define to facilitate our further troubleshooting?

Of course,I just modified the alert rule., here is the SQL insert statement.select * from hzb_alert_define where type = 'periodic'

INSERT INTO "public"."hzb_alert_define" ("id", "annotations", "creator", "datasource", "enable", "expr", "gmt_create", "gmt_update", "labels", "modifier", "name", "period", "template", "times", "type") VALUES (7, NULL, 'admin', 'promql', 't', 'cpu_usage == 0', '2025-09-18 17:28:43.229194', '2025-09-18 17:30:18.085477', '{"severity":"warning"}', 'admin', '测试cpu告警', 60, '${instance}(${host})cpu告警', 1, 'periodic');

[Duansg]

@Duansg I think I've found the pattern: after configuring the alert rules, the backend error logs will show an error:

2025-09-18 17:28:43.236 [http-nio-1157-exec-8] ERROR org.apache.hertzbeat.alert.calculate.PeriodicAlertRuleScheduler Line:75  - Alert rule is null or rule id is null.

Then, after waiting for 30 minutes, the first error message appears: "Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs."

@love01211 Hi, thank you for your assistance and response. that's odd. The purpose of this exception is to verify whether the expression has been fully consumed and to check for invalid expressions. However, the expression you provided appears to be parsed correctly. Could you please export the data from hzb_alert_define to facilitate our further troubleshooting?

Of course,I just modified the alert rule., here is the SQL insert statement.select * from hzb_alert_define where type = 'periodic'

INSERT INTO "public"."hzb_alert_define" ("id", "annotations", "creator", "datasource", "enable", "expr", "gmt_create", "gmt_update", "labels", "modifier", "name", "period", "template", "times", "type") VALUES (7, NULL, 'admin', 'promql', 't', 'cpu_usage == 0', '2025-09-18 17:28:43.229194', '2025-09-18 17:30:18.085477', '{"severity":"warning"}', 'admin', '测试cpu告警', 60, '${instance}(${host})cpu告警', 1, 'periodic');

Hi, @love01211 . I'm very sorry, i tried it again but still couldn't reproduce the issue. However, I suspect this error isn't caused by the threshold expression you provided. I'll submit a PR shortly that addresses the following:

1. Resolve the issue Alert rule is null or rule id is null.
2. Add exception logging to obtain the threshold expression for errors.

You can build according to the contents of this PR and review the specific error details.

[love01211]

ok

@Duansg I think I've found the pattern: after configuring the alert rules, the backend error logs will show an error:

2025-09-18 17:28:43.236 [http-nio-1157-exec-8] ERROR org.apache.hertzbeat.alert.calculate.PeriodicAlertRuleScheduler Line:75  - Alert rule is null or rule id is null.

Then, after waiting for 30 minutes, the first error message appears: "Calculate query parse error promql: Expression is not fully parsed, may have syntax errors or incomplete inputs."

@love01211 Hi, thank you for your assistance and response. that's odd. The purpose of this exception is to verify whether the expression has been fully consumed and to check for invalid expressions. However, the expression you provided appears to be parsed correctly. Could you please export the data from hzb_alert_define to facilitate our further troubleshooting?

Of course,I just modified the alert rule., here is the SQL insert statement.select * from hzb_alert_define where type = 'periodic' INSERT INTO "public"."hzb_alert_define" ("id", "annotations", "creator", "datasource", "enable", "expr", "gmt_create", "gmt_update", "labels", "modifier", "name", "period", "template", "times", "type") VALUES (7, NULL, 'admin', 'promql', 't', 'cpu_usage == 0', '2025-09-18 17:28:43.229194', '2025-09-18 17:30:18.085477', '{"severity":"warning"}', 'admin', '测试cpu告警', 60, '${instance}(${host})cpu告警', 1, 'periodic');

Hi, @love01211 . I'm very sorry, i tried it again but still couldn't reproduce the issue. However, I suspect this error isn't caused by the threshold expression you provided. I'll submit a PR shortly that addresses the following:

1. Resolve the issue Alert rule is null or rule id is null.
2. Add exception logging to obtain the threshold expression for errors.

You can build according to the contents of this PR and review the specific error details.

Ok, but I'm not a professional developer. I'll try to conduct tests.