[SOLVED] Unable to create a new rule

[mappr]

I have…

• [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

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

When trying to create a new rule of type IF Content Changed THEN Webhook the Rule is not created and shows an error message. In the network tab we can see that the POST request to create the rule is giving a 500 response.

Expected behavior

It should be possible to create a new rule.

Minimal reproduction of the problem

Go to the rules page and try to create a new rule of the specified type.

Environment

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

Version: [VERSION]

Browser:

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

Others:

Payload:
{“trigger”:{“handleAll”:null,“schemas”:[{“schemaId”:“33f7dd0a-6229-46c3-b59c-4ef6d578597c”}],“triggerType”:“ContentChanged”},“action”:{“url”:“https://MyURL”,“method”:“POST”,“payload”:null,“payloadType”:null,“headers”:null,“sharedSecret”:“secret”,“actionType”:“Webhook”},“isEnabled”:false}

[Sebastian]

Thanks, I will provide a fix today or tomorrow. There are several issues, but it should work if you check and uncheck the “All schemas” checkbox.

[slalFe]

Hello, would the changes you’ve made in https://github.com/Squidex/squidex/commit/399968ef9c7442387d010406d18775c10b61b8ad#diff-c2af4acffcb8e4b63df9c40a98ff45c613c4931a5e1358ff534a043e2e28dd19 impact creating via the Squidex.ClientLibrary? We’ve noticed that our rules are not getting triggered sometimes (testing out self hosted 7.1) and are trying to narrow down the issue, but now I am wondering/hoping this is it!

Edit: Oh nm, just wiped out our instance and recreated and Rules now work as expected. Wonder why Rules were not being triggered (yes they were definitely enabled and clustering:worker was set to true!)

[Sebastian]

It is not related to the error here at all.

The root cause of this bug is an error in the UI, which was providing the “HandleAll” property of the content changed trigger as null to the backend. The old JSON serializer was accepting that, the new one is more strict and was throwing an error. Unfortunately the error was swallowed.

The commit has just increased the timeout for messages. Actually the messaging is only really relevant for backups, because there are the following message types:

1. Start and stop an event consumer. If the message is not handled properly, nothing happens.
2. Start and stop of backup processes.
3. Start and stop of restore processes.
4. Running the rules over the UI (not the normal process).
5. Usage handling for the cloud to send out emails when you are running low of API calls.

The normal rule flow is independent and just runs as event consumer in the background and consumes the events.