Hi Sebastian
Could you elebrate a bit around how rules, and retries and implemented?
What i’m curious to know, is if a content is updated, but rules fails, could there be a race condition, if the content is changed again and that rules don’t fail, and the previous failed rules suceed with a retry?
The retry mechanism is only supposed to handle errors in the external system, e.g. a temporary downtime or networking issues.
When a content is updated an event is created with a version.
The rule enqueuer runs in the background and creates jobs for all events that have a matching rule. But the event does not contain the full information, e.g. a ContentStatusChanged event does not contain the data. Therefore the rule enqueuer asks for the content with the version from the event and enriches the event, for example with the content field data.
Then a job is created from the event and stored in the database.
Another background process, the rule dequeuer, takes the job and tries to execute it. When it fails the job in the DB is updated with a new schedule-time and then executed again when the time has passed.
When you click the Enqueue-button for an event, the schedule-time is set to Now()
Okay, so basicly this means that when we rule is executed that last version of content is always published, and not the state it was in when the event happend?
No!. Each event has a version:
e.g.
ContentCreated: 0
ContentUpdated: 1
ContentPublished: 2
ContentUpdated: 3
So lets say you have a rule that is triggered when a content is published. Then the rule enqueuer asks for the content item with version: 2.
Because of the full history it is no issue to restore the state of a content or asset or whatever at any given point of time. So even if the rule enqueuer is paused and continued a year later it would be enriched with the content data when the event has been created.
Okay, so is it’s up to the consumer to ensure that version 2 don’t override version 3, in case of version 2 fails, and version 3 succed before version 2 manage to succeed?
Yes, thats right.
I think this quote is really good:
Squidex also does not ensure “exactly once”, it is at least once guarantee.
Okay, thanks, it could be that you based on key could ensure order, like kafka
Yes, I do that, but only for the happy path.
Okay thanks for the clarification
