-
Notifications
You must be signed in to change notification settings - Fork 735
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: prolong-
and deleteRequestLock
forefront
option
#2690
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request is neither linked to an issue or epic nor labeled as adhoc!
@@ -329,6 +329,7 @@ export class RequestQueueClient extends BaseClient implements storage.RequestQue | |||
internalRequest.orderNo = forefront ? -unlockTimestamp : unlockTimestamp; | |||
|
|||
await request?.update(internalRequest); | |||
if (forefront) this.forefrontRequestIds.push(id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just an approximation - on Platform, the prolongRequestLock
forefront
order is based on the lock expiration order, not the prolong
call order. This means that:
prolong lock on A, 10 seconds, forefront
prolong lock on B, 5 seconds, forefront
...will result in B | A | ...tail
in our implementation but A | B | ...tail
on Platform.
This feature didn't work at all before this PR - this tells me that we don't need to get this detail completely right. Especially since supporting this would require storing the unlock times in the forefront
list and would be a proper mess maintaining with more prolong
and delete
calls.
Turns out we neglected the
prolong
anddeleteRequestLock
methods with #2681 , so these do not respect theforefront
-enforced request ordering. This PR fixes this omission.Prerequisite for #2689
Related to #2669