-
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: forefront
request fetching in RQv2
#2689
Conversation
81b4ec4
to
259d529
Compare
259d529
to
0546643
Compare
this._cacheRequest(getRequestId(uniqueKey), { | ||
requestId: id, | ||
uniqueKey, | ||
wasAlreadyPresent: true, | ||
wasAlreadyHandled: false, | ||
}); | ||
} | ||
|
||
for (const id of forefront ? headIdBuffer.reverse() : headIdBuffer) { |
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.
Does this reverse matters at all? They're all still gonna be added with forefront so it feels redundant
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.
Unfortunately it does, as we want to prepend headIdBuffer
(as it is) to queueHeadIds
- if we push the requests one by one in to the head of queueHeadIds
, it would end up reversed:
buffer: 12345
queue: 67890
buffer: 2345
queue: 167890
buffer: 345
queue: 2167890
etc.
I'm not a huge fan of this ternary mumbo-jumbo either, but headIdBuffer
is at most 25 items long, so at least this should cause no noticeable perf problem. Readability... that's a different story 🥲
Keeps count of the (locally)
forefront
enqueued requests in the RQv2 instance. Uses this counter to signal the need for new remote RQ reads.Note that with the current API, we cannot solve this for request queues with multiple clients. The original behavior is retained in such a scenario.
Closes #2669