Variable resolution in Webhook URL stopped working after updating from 7.18.0 to 7.20.0

I have…

I’m submitting a…

  • [x ] Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • Documentation issue or request

Current behavior

Variables (e.g. ${EVENT_APPID.NAME}) in the Url field of the Webhook step are not resolved.

Expected behavior

The variable is in the URL is resolved. It worked in version 7.18.0.

Minimal reproduction of the problem

  1. Create new rule
  2. Set trigger to “Manually triggered”
  3. Add Webhook
    Method: Get
    Url: https://localhost/${EVENT_APPID.NAME}/
  4. Trigger rule
  5. Check logs (Attemps > Output)
  6. URL contains the unresolved variable

Environment

App Name: e.g. treesize

  • [x ] Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: 7.20.0

Browser:

  • Chrome (desktop)
  • Chrome (Android)
  • Chrome (iOS)
  • [x ] Firefox
  • Safari (desktop)
  • Safari (iOS)
  • IE
  • Edge

Hi,
I will provide a fix tomorrow. I think it is a one-liner.

Hi @Sebastian,

I tried docker tag dev-8391 assuming that it contains https://github.com/Squidex/squidex/ommit/78a7d35bd4c2b4338fc048806529010466ad1230. Unfortunately, it doesn’t work. Now, the webhook is not even attempted.

Can you check the logs? I was testing and it was working fine for me …

Nothing in the logs. No error, no warning.

{
  "logLevel": "Information",
  "message": "Adding rule job for Rule(trigger=ManualTrigger)",
  "ruleTrigger": "ManualTrigger",
  "timestamp": "2025-07-01T14:08:11Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-c250f1f58f5bebce1b090f09aab607f9-9f3eb7ef144bb513-01",
    "requestPath": "/api/apps/dummy/rules/dd7fce32-2412-43d8-8dba-48a5d05ab300/trigger",
    "requestMethod": "PUT",
    "routeValues": {
      "area": "api",
      "action": "TriggerRule",
      "controller": "Rules"
    }
  },
  "category": "Squidex.Domain.Apps.Entities.Rules.RuleEnqueuer"
}
{
  "logLevel": "Information",
  "message": "HTTP request executed.",
  "elapsedRequestMs": 19,
  "filters": {
    "appId": "0dd2b12e-5df6-4a6f-b057-5ce4bf3e5177",
    "appName": "dummy",
    "userId": "655ddcde9e22151f70d6bfc9",
    "clientId": "squidex-frontend",
    "costs": 1
  },
  "timestamp": "2025-07-01T14:08:11Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-c250f1f58f5bebce1b090f09aab607f9-335fa4683fca4055-01",
    "requestPath": "/api/apps/dummy/rules/dd7fce32-2412-43d8-8dba-48a5d05ab300/trigger",
    "requestMethod": "PUT"
  }
}
{
  "logLevel": "Information",
  "message": "HTTP request executed.",
  "elapsedRequestMs": 4,
  "filters": {
    "appId": "0dd2b12e-5df6-4a6f-b057-5ce4bf3e5177",
    "appName": "dummy",
    "userId": "655ddcde9e22151f70d6bfc9",
    "clientId": "squidex-frontend",
    "costs": 0
  },
  "timestamp": "2025-07-01T14:08:17Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-2fe9374fed1a6963e66b6922ef1a8dfe-495be6dbc4238e29-01",
    "requestPath": "/api/apps/dummy/rules/events",
    "requestMethod": "GET"
  }
}
{
  "logLevel": "Information",
  "message": "HTTP request executed.",
  "elapsedRequestMs": 8,
  "filters": {
    "appId": "0dd2b12e-5df6-4a6f-b057-5ce4bf3e5177",
    "appName": "dummy",
    "userId": "655ddcde9e22151f70d6bfc9",
    "clientId": "squidex-frontend",
    "costs": 0
  },
  "timestamp": "2025-07-01T14:08:32Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-29475f92157db455df02014331300dce-160306918f5d4bbe-01",
    "requestPath": "/api/apps/dummy/rules/events",
    "requestMethod": "GET"
  }
}
{
  "logLevel": "Information",
  "message": "HTTP request executed.",
  "elapsedRequestMs": 4,
  "filters": {
    "appId": "0dd2b12e-5df6-4a6f-b057-5ce4bf3e5177",
    "appName": "dummy",
    "userId": "655ddcde9e22151f70d6bfc9",
    "clientId": "squidex-frontend",
    "costs": 0
  },
  "timestamp": "2025-07-01T14:08:33Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-d9e588604dc279ace646ce0557a35a1e-d76f18c1897a3483-01",
    "requestPath": "/api/apps/dummy/rules/events",
    "requestMethod": "GET"
  }
}
{
  "logLevel": "Information",
  "message": "HTTP request executed.",
  "elapsedRequestMs": 1,
  "filters": {
    "costs": 0
  },
  "timestamp": "2025-07-01T14:08:39Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-1ef171eb3a0cc8389948145fb2ac4a43-923b72b0e0d7c0bb-01",
    "requestPath": "/healthz",
    "requestMethod": "GET"
  }
}
{
  "logLevel": "Information",
  "message": "HTTP request executed.",
  "elapsedRequestMs": 4,
  "filters": {
    "appId": "0dd2b12e-5df6-4a6f-b057-5ce4bf3e5177",
    "appName": "dummy",
    "userId": "655ddcde9e22151f70d6bfc9",
    "clientId": "squidex-frontend",
    "costs": 0
  },
  "timestamp": "2025-07-01T14:08:51Z",
  "app": {
    "name": "Squidex",
    "version": "7.0.0.0",
    "sessionId": "de877ae3-b1e2-4870-8889-06fc5b497565"
  },
  "web": {
    "requestId": "00-7e0b9e5f03abf5ac5c97233c945fc87f-47fbb47121fc1bd5-01",
    "requestPath": "/api/apps/dummy/rules/events",
    "requestMethod": "GET"
  }
}

I thought, that recreating the rule could help, but then I found a new problem. I cannot create a webhook step because the URL is not accepted when I click the Add button:

To be sure that it isn’t related to the variable, I tried a normal URL, but same problem:

I will test it again. the API tests also run a few webhook rules, so I am confused by that tbh.

I created a new clean instance on a test system with the dev-8391 image, create an app and the rule and I can confirm that it works. The problem must be with our stored data or configuration. I will investigate further.

I performed some more tests, and it looks like our database it damaged. When I create a backup of an app in the productive system and restore it on the test system, everything works fine. No problems when resolving the variable, and also no problems when creating a new rule with a webhook. Therefore, I consider the issue fixed. Thank you for your support and the fast fix.

Looks like we will need to backup/export everything, start with a clean database, and import everything back to repair our productive system.

I think I found another bug/problematic behavior while testing. When the type of the URL is changed from text to script and the rule is executed, nothing happens. The status remains pending. Like in my image above. While in this state, it was not possible for me to execute any other rule for any app. I needed to cancel the problematic rule and restart the container.
I assume something goes wrong because ‘http:’ is interpreted as a goto label and the rest of the URL as a comment.

I think I found another bug/problematic behavior while testing. When the type of the URL is changed from text to script and the rule is executed, nothing happens. The status remains pending. Like in my image above. While in this state, it was not possible for me to execute any other rule for any app. I needed to cancel the problematic rule and restart the container.
I assume something goes wrong because ‘http:’ is interpreted as a goto label and the rest of the URL as a comment.

It should fail, because technically it is nto a valid script, but it should always terminate.

I have fixed that. Exception in the “preparation” for an action (when scripts are evaluated) were not captured properly.