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

fix(drain): consider checking parent jobs when draining #992

Merged
merged 15 commits into from
Jan 28, 2022

Conversation

roggervalf
Copy link
Collaborator

When we call drain, we were not considering checking the parent dependencies, so those records could be moved to wait or paused depending on how many dependencies they still have, this way we don't end in an scenario where parents have dependencies but the actual child record is deleted

expect(keys.length).to.be.eql(5);

const countAfterEmpty = await queue.count();
expect(countAfterEmpty).to.be.eql(1);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this job is the parent that was moved to wait state, before it was in waiting-children state

rcall("ZREM", parentPrefix .. "waiting-children", parentId)

if rcall("HEXISTS", parentPrefix .. "meta", "paused") ~= 1 then
rcall("RPUSH", parentPrefix .. "wait", parentId)
if parentPrefix == baseKey then
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we should only delete those records that belongs to the same queue that runs this script, on the contrary case, move it to wait or paused

Copy link
Contributor

@manast manast left a comment

Choose a reason for hiding this comment

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

Is this ready?

@roggervalf
Copy link
Collaborator Author

Is this ready?

Yes, this one is ready

```

{% hint style="info" %}
Locked jobs (in active state) could not be removed. An error would be thrown.
Copy link
Contributor

Choose a reason for hiding this comment

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

"could" -> "can", "would" -> "will"


There are 2 possible cases:

1. There are not pending dependencies; in this case the parent is moved to wait state, we may try to process this job.
Copy link
Contributor

@manast manast Jan 28, 2022

Choose a reason for hiding this comment

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

-> "to the wait status"

There are 2 possible cases:

1. There are not pending dependencies; in this case the parent is moved to wait state, we may try to process this job.
2. There are pending dependencies; in this case the parent is kept in waiting-children state.
Copy link
Contributor

Choose a reason for hiding this comment

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

-> "in the waiting-children status"


# Having pending dependencies

We may try to remove all its pending decendents first.
Copy link
Contributor

Choose a reason for hiding this comment

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

"decendents" -> "descendents"

We may try to remove all its pending decendents first.

{% hint style="warning" %}
in case one of the children is locked, we would stop the deletion process.
Copy link
Contributor

Choose a reason for hiding this comment

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

"in" -> "In", "we would" -> "it will"

```

{% hint style="warning" %}
Parent jobs that belong to the queue being drained will be kept in **waiting-children** state if they have pending children, but if they do not have any pending children they will just be removed.
Copy link
Contributor

Choose a reason for hiding this comment

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

state -> status

Copy link
Contributor

@manast manast left a comment

Choose a reason for hiding this comment

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

LGTM, just a couple of typos in the documentation

@roggervalf roggervalf merged commit 81b7221 into master Jan 28, 2022
@roggervalf roggervalf deleted the fix-consider-parent-dependencies-in-drain branch January 28, 2022 16:08
github-actions bot pushed a commit that referenced this pull request Jan 28, 2022
## [1.67.3](v1.67.2...v1.67.3) (2022-01-28)

### Bug Fixes

* **drain:** consider checking parent jobs when draining ([#992](#992)) ([81b7221](81b7221))
@github-actions
Copy link

🎉 This PR is included in version 1.67.3 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants