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

x3ntrix · June 26, 2025, 9:24am

I have…

[x ] Read the following guideline: https://docs.squidex.io/01-getting-started/installation/troubleshooting-and-support. I understand that my support request might get deleted if I do not follow the guideline.
[x ] Used code blocks with ``` to format my code examples like JSON or logs properly.

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

Create new rule
Set trigger to “Manually triggered”
Add Webhook
Method: Get
Url: https://localhost/${EVENT_APPID.NAME}/
Trigger rule
Check logs (Attemps > Output)
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

Sebastian · June 26, 2025, 7:01pm

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

x3ntrix · July 1, 2025, 7:19am

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.

Sebastian · July 1, 2025, 1:10pm

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

x3ntrix · July 1, 2025, 2:16pm

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:

Sebastian · July 2, 2025, 8:51am

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

x3ntrix · July 2, 2025, 11:26am

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.

x3ntrix · July 2, 2025, 1:34pm

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.

Sebastian · July 2, 2025, 2:57pm

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.

Sebastian · July 4, 2025, 7:48am

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