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.

arm1n · July 12, 2025, 4:40pm

@Sebastian I tried dev-8394 and for me it also doesn’t work. When inspecting the network panel it seems that the changes of the Url* field are not even captured, i.e. all requests are sent to the API with the old value. This might also explain the problems of @x3ntrix with the failed field validation of Url* field. Could you give that one another look please? Thanks a lot!

Edit: After switching from Firefox to Chrome, it turned out that I’m able to persist the rule definition from Url* field, so it seems to be a browser problem only. The variable substitution is then working as previously, thanks!

Sebastian · July 14, 2025, 7:28am

I will check the problem with the browser

arm1n · July 14, 2025, 2:52pm

Thanks Sebastian, one more thing I noticed while working with the new rules interface is that the “Cancel all” button on the right in the events log seems to be noop without any error code, as the DELETE request successfully goes through, but the events stay in the log and stick with states like “Pending” etc.

Sebastian · July 14, 2025, 5:42pm

I think they probably work by setting the “DueTime” of the events to null, which basically cancels them. But they do not reflect the state.

arm1n · July 16, 2025, 2:02pm

Thanks @Sebastian, I cannot see where this could be set in the Rules UI?

Sebastian · July 19, 2025, 8:38pm

I have fixed the bug now. It was a backend problem.