Skip to content

[16.0][PORT] queu_job: identity_key enhancements (Port from 14.0) - #619

Closed
QuocDuong1306 wants to merge 2 commits into
OCA:16.0from
QuocDuong1306:16.0-port-imp-queue-job
Closed

[16.0][PORT] queu_job: identity_key enhancements (Port from 14.0)#619
QuocDuong1306 wants to merge 2 commits into
OCA:16.0from
QuocDuong1306:16.0-port-imp-queue-job

Conversation

@QuocDuong1306

Copy link
Copy Markdown
Contributor

Port from: #581

Richard deMeester and others added 2 commits January 22, 2024 11:31
1. In production, a job which is waiting dependencies or which
has started, but not completed, should not be repeated if
the identity_key matches.

2. In tests, the mock queue handler is now enhanced to allow
better mimicking of the identity_key blocks from production.

3. In tests, the mock queue handler now clears the enqueued jobs
after performing them, to better reproduce what a production
environment would do.
Good explanation from Guewen:

Depending on the use case, we should or should not include.
As part of my current work, I use Sidekiq daily.
They have a similar feature, but you can set a per-job parameter unique_until with options:
start (that would mean up to ENQUEUED here) or success (that would be up to STARTED here).

Think about this use case: a job refreshes a cache. Data have changed, we create a pending job. Data change again, no new job because the job is still pending.
Job starts. Data change while the job is running. In this very case, we'd like to enqueue a new job otherwise the cache will be outdated.

I reckon that both cases are valid, but I fear adding this state in the domain may, silently and in subtle ways, existing behaviors.
@QuocDuong1306
QuocDuong1306 marked this pull request as draft January 22, 2024 04:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants