Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[16.0][FIX] queue_job: fix deadlock #672

Open
wants to merge 1 commit into
base: 16.0
Choose a base branch
from

Conversation

BT-sschmid
Copy link

Fix a deadlock condition when there are dependent stored fields on queue.job:state.

Example:

  • Sale-Order has a stored computed field which depends on job-state.
  • A job updates a sale-order record.
  • A exception is raised and in the final error-handling with a child cursor in
    with registry(job.env.cr.dbname).cursor() as new_cr:
    the job's state is updated, which also triggers an update in the sale order. Result is a deadlock.

This commit adds a rollback in case of error during job execution, so that any locks are released.

Fix a deadlock condition when there are dependent stored fields on `queue.job:state`.

Example:
 - Sale-Order has a stored computed field which depends on job-state.
 - A job updates a sale-order record.
 - A exception is raised
and in the final error-handling with a child cursor in https://github.com/OCA/queue/blob/c93a25366d2c51339ae4530a42eb7393bdc98b12/queue_job/controllers/main.py#L144
the job's state is updated, which also triggers an update in the sale order.
Result is a deadlock.

This commit adds a rollback in case of error during job execution, so that any locks are released.
@OCA-git-bot
Copy link
Contributor

Hi @guewen,
some modules you are maintaining are being modified, check this out!

@BT-sschmid BT-sschmid changed the title queue_job: fix deadlock [16.0][FIX] queue_job: fix deadlock Jul 12, 2024
Copy link
Contributor

@amh-mw amh-mw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though I generally agree with the intent of this change, there is already some rollback code in the enclosing runjob call, specifically a rollback in the event of a RetryableJobError. It makes me question why the except (FailedJobError, Exception) stanza doesn't rollback as well, choosing instead to grab a different cursor to commit the job state.

@BT-sschmid
Copy link
Author

BT-sschmid commented Aug 14, 2024

Though I generally agree with the intent of this change, there is already some rollback code in the enclosing runjob call, specifically a rollback in the event of a RetryableJobError. It makes me question why the except (FailedJobError, Exception) stanza doesn't rollback as well, choosing instead to grab a different cursor to commit the job state.

now I got your comment ^^
Indeed I also don't see the need to use a new cursor if the tx is rolled back. If you agree I change it to just rollback.

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.

3 participants