-
Notifications
You must be signed in to change notification settings - Fork 872
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
Connection lost moves "reserved" jobs to "ready" #626
Comments
What would you like to happen to them instead? If you want them to be deleted, you can get much the same effect by deleting each job as soon as it's reserved. If you want them to remain reserved, that would require some changes to the protocol. The server currently has no way to identify a client other than by its connection. When a new connection appears, as far as the server knows, it's a new unrelated client. If we wanted the new connection to get all the reservations from a previous connection, we would need to come up with a way for clients to identify themselves that is durable across multiple connections. Or do you have a third option in mind? |
@kr Thank you for the explanation! I was thinking about the second option ("remain reserved"), but now I see that it's not supported by design. What about buried and delayed statuses? Are they permanent or do they depend on the connection as well? |
Reserved is the only status that is tied to a connection. The other statuses aren't, so they won't be changed by a client disconnecting. |
Is it possible to avoid jobs moving from "reserved" to the "ready" state when connection is broken?
I've tried to re-connect on socket error but it turned out that all jobs that were "reserved" using the broken connection get to the "ready" state and as a result, available for taking again.
The text was updated successfully, but these errors were encountered: