Was ContentChanged trigger changed/fixed to support Delete in Squidex v7.x?

Development
1

Good morning,

We have some bulk content changes we run using the Squidex.Client v8.27.0. To avoid triggering the Rule we have around this we disable when creating and updating content, but did not disabled upon deletion as it never used to trigger the Rule. However after migrating to v7.1 of Squidex from v6.9.0 we have found that it DOES trigger the Rule. Here is an example of our trigger:

image
image818×723 20.1 KB

And the payload it creates:
{
“type”: “FruitDeleted”,
“payload”: {
“type”: “Deleted”,
“id”: “00000000-0000-0000-0000-000000000000”,
“created”: “1970-01-01T00:00:00Z”,
“lastModified”: “1970-01-01T00:00:00Z”,
“createdBy”: null,
“lastModifiedBy”: null,
“data”: null,
“dataOld”: null,
“status”: “Unknown”,
“newStatus”: null,
“partition”: 1900351261,
“schemaId”: “12345,fruit”,
“actor”: “client:core-cms-us-admin-client”,
“appId”: “67890,playground”,
“timestamp”: “2022-09-26T09:08:28Z”,
“name”: “FruitDeleted”,
“version”: 0
},
“timestamp”: “2022-09-26T09:08:28Z”
}

Just wanted to confirm that this has changed and that we were accidentally relying on a bug to not trigger the Rule on delete operations?

p.s. Is there a changelog available somewhere for the Squidex.ClientLibrary? I am unsure what the breaking change is that has warranted a major version increment to v9.x. The CLI itself is still on v8.x: https://github.com/Squidex/squidex-samples/releases

2

Yes, could be :wink: … I remember that a bug was fixed but not the details.

EDIT: In 7.1.0 I fixed a bug for schema triggers.

3

Ah yes this commit: https://github.com/Squidex/squidex/commit/6e7828b90cb84016d0e4f7b7bfd6d55429230828

Although now I am testing it some more I have also noticed that our previous logic around bulk creation and updating is no longer working as the Rule is getting triggered:

  1. Disable all Rules
  2. Wait 11 seconds so Rules cache has definitely expired
  3. Perform bulk create and update operation
  4. Wait for response
  5. Enable all Rules
  6. Rule is getting triggered

Has something else changed where bulk operation now returns results before Squidex has finished processing the whole operation? I.e. does it return a result sooner rather than later stating ''yes all bulk operations pass validation" and then put them in a queue to be processed which might trigger a rule if enabled soon after bulk operation has returned it’s results?

Likely something I am doing wrong here but this was working OK before on v6.9.0.

4

For now we are having to just leave the rules disabled after running bulk operations which isn’t ideal. How can we know when the bulk operation has finished processing so that we can enable them again?

Also I have now updated to v9.1 of the Squidex.ClientLibrary just in case it helps but still do not actually know what those changes are.

5

Which bulk operation do you mean? There is nothing running in the background.

6

For example:

var bulkResult = await squidexClient.BulkUpdateAsync(new BulkUpdate()
{
    Jobs = bulkUpdateJobs
});

Soon after this we call:

foreach (var rule in await GetAllRulesAsync())
{
    await rulesClient.EnableRuleAsync(rule.Id);
}
await WaitForSquidexRulesCacheToExpire();

When we were on v6.9.0 the Rules attached the the schema being updated would not be triggered, but as of v7.1.0 they are and I just cannot see why so was just speculating about something processing the bulk update after API has responded OK for the bulk operation. I just tested manually enabling the rules straight after getting a response back from my application that performs the bulk request and the Rules get triggered then too.

Perhaps the answer is just to wait for a minute before re-enabling the rules, I am just surprised we didn’t hit this same issue when using v6.9.0.

7

The bulk endpoint just creates events, these events are then handled in the background and trigger all rules that are configured and enabled at this point of time. If you enable rules afterwards the events might have been processed already.

So basically you cannot pause rules, individually. If you want to do that, you have to pause the event consumer.

8

Ah right so I think this is what we want as we don’t want the rules firing on this initial bulk operation. We just need to wait an amount of time for all those events to be processed before enabling the rules. Unsure how long that’ll take but we can just say wait for an hour after our biggest bulk operation before enabling the rules.

9

I still do not get it, what do you mean with “all those events”?

10

If we are using the bulk endpoint to create thousands of pieces of content, some of which have large text fields (I think that slows things down a bit, we have to chunk the bulk update as in the past it has taken our Squidex instance down doing it all in one request), then there will be “all those events” to handle in the background after the bulk endpoint has responded saying everything is OK.

11

So your background processes?

12

Yes, if they are triggering Rules after the bulk endpoint has returned an OK response then we cannot enable Rules straight afterwards.

13

I am still super confused by that. Why can you not enable the rule afterwards? There is a little bit of caching involved but this does not help because the events would still be processed.

14

Because they are being triggered and we don’t want them to as this is an initial bulk migration into Squidex and the rules are to keep state in sync across data stores after this initial bulk migration. In 6.9.0 they were not being triggered but in 7.1.0 they are.

Perhaps there is something to do with the background processes executing our custom scripts which update the content which counts as a new event so triggers the rule? I.e. for some content we create in one status and then shift it to another status, and we have custom scripts that always update a value on status changes.

1 Like