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: forefront request fetching in RQv2 #2689

Merged
merged 8 commits into from
Oct 3, 2024
Merged

Conversation

barjin
Copy link
Contributor

@barjin barjin commented Oct 1, 2024

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

@barjin barjin requested review from janbuchar and vladfrangu October 1, 2024 11:10
@barjin barjin self-assigned this Oct 1, 2024
@github-actions github-actions bot added this to the 99th sprint - Tooling team milestone Oct 1, 2024
@github-actions github-actions bot added t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics. labels Oct 1, 2024
@barjin barjin force-pushed the fix/rq-forefront-batching branch from 81b4ec4 to 259d529 Compare October 1, 2024 12:09
@barjin barjin marked this pull request as draft October 1, 2024 14:15
barjin added a commit that referenced this pull request Oct 2, 2024
We neglected the `prolong` and `deleteRequestLock` methods
with #2681 , so these do not respect the `forefront`-enforced request
ordering. This PR fixes this omission.

Prerequisite for #2689 
Related to #2669
@barjin barjin force-pushed the fix/rq-forefront-batching branch from 259d529 to 0546643 Compare October 2, 2024 11:33
@barjin barjin marked this pull request as ready for review October 2, 2024 11:43
@barjin barjin requested a review from vladfrangu October 2, 2024 13:24
this._cacheRequest(getRequestId(uniqueKey), {
requestId: id,
uniqueKey,
wasAlreadyPresent: true,
wasAlreadyHandled: false,
});
}

for (const id of forefront ? headIdBuffer.reverse() : headIdBuffer) {
Copy link
Member

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

Copy link
Contributor Author

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 🥲

@barjin barjin merged commit 03951bd into master Oct 3, 2024
9 checks passed
@barjin barjin deleted the fix/rq-forefront-batching branch October 3, 2024 10:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

bug: RequestQueue.addRequest's forefront option doesn't work
2 participants