Connection lost moves "reserved" jobs to "ready"

[evgenybf]

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.

1. Reserve an only available job and check that its state is RESERVED:

$ echo -e 'watch my-tube\r\nstats-job 3\r\nreserve\r\nstats-job 3\r\n' | nc 127.0.0.1 11300
WATCHING 2
OK 158
---
id: 3
tube: my-tube
state: ready
pri: 666
age: 449
delay: 0
ttr: 10000
time-left: 0
file: 0
reserves: 6
timeouts: 0
releases: 0
buries: 0
kicks: 0

RESERVED 3 5
abcde
OK 164
---
id: 3
tube: my-tube
state: reserved
pri: 666
age: 449
delay: 0
ttr: 10000
time-left: 9999
file: 0
reserves: 7
timeouts: 0
releases: 0
buries: 0
kicks: 0

3. Check its state again - it's READY:

$ echo -e 'watch my-tube\r\nstats-job 3\r\n' | nc 127.0.0.1 11300

WATCHING 2
OK 158
---
id: 3
tube: my-tube
state: ready
pri: 666
age: 449
delay: 0
ttr: 10000
time-left: 0
file: 0
reserves: 6
timeouts: 0
releases: 0
buries: 0
kicks: 0

[kr]

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?

[evgenybf]

@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?

[kr]

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.