Skip to content

Race condition at AdminMiddleware #154

Open
@spumer

Description

@spumer

Hi. We have a lot of tasks in ENQUEUED status but they executed and jobs well done.

I think we have small race condition at middleware callbacks:

  1. Scheduler emit before_enqueue
  2. Scheduler publish task to queue
  3. Worker got task from queue
  4. Worker emit before processing (update task status=RUNNING)
  5. Worker done task
  6. Worker emit after processing. (update task status=DONE)
  7. Scheduler emit afer_enqueue (update task status=ENQUEUED)

In logs this looks like this:
image

You can see different order for Create and Update logs. But last log is Update. Do not worry, message logged before SQL operation and this is not equal reflection of SQL updates.


So, i want make a PR to fix that. I see two solutions for that case:

  1. Optimistic locks: check row version at update and ignore if it changed (this require schema update)
  2. Do not allow change status from DONE/RUNNING to ENQUEUED. Check status when update. (control state flow)

@amureki what do you think about that?

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions