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(ws server): batch wait until all methods has been executed. #542

Merged
merged 8 commits into from
Nov 1, 2021

Conversation

niklasad1
Copy link
Member

@niklasad1 niklasad1 commented Oct 27, 2021

This fixes a bug in the ws-server when any async methods are included in batch, the futures were not awaited on that "may" cause method calls to be ignored. In worst case just send back ]

let futs = batch
.into_iter()
.filter_map(|req| m.execute_with_resources(&tx_batch, req, conn_id, r));
futures_util::future::join_all(futs).await;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit funny to read the responses off a different future in collect_batch_response. Is it possible to add that result-reading task to futs and join_all on that?

Copy link
Member Author

@niklasad1 niklasad1 Oct 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, we just need to close the channel after the method calls futures has completed.

otherwise, collect_batch_response won't complete.

Methods::execute_with_resource -> BoxFuture<()> thus only possible to read result via another future/channel i.e, not directly from the result from the future without any major refactoring....

Comment on lines 304 to 305
let r = &resources;
let m = &methods;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These re-borrows are a bit awkward, not sure if there's a way around that though (impl AsRef for Methods?). :/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lemme check if I can remove the async move below otherwise it's required :(

Copy link
Contributor

@dvdplm dvdplm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

if !batch.is_empty() {
let futs = batch
.into_iter()
.filter_map(|req| m.execute_with_resources(&tx_batch, req, conn_id, r));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that responses could come back in a different order to the request order in the batch?

eg if we have a batch request to first slow_hello and then say_hello, and then collect those up via a channel, we'll get the say_hello response back first.

Do we care that the response order might not match the request order (if I'm even right about this!)?

Copy link
Member Author

@niklasad1 niklasad1 Nov 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good question, yes responses could be in different order but it's intended because the spec doesn't require responses to be in order 👇

The Response objects being returned from a batch call MAY be returned in any order within the Array. The Client SHOULD match contexts between the set of Request objects and the resulting set of Response objects based on the id member within each Object.

I should have put a comment in the code about this but it's kind of an optimization :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah awesome, gotcha!

Copy link
Collaborator

@jsdw jsdw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Should the test confirm that 2 responses come back?

@niklasad1 niklasad1 merged commit 092081a into master Nov 1, 2021
@niklasad1 niklasad1 deleted the reproduce-batch-issue-ws branch November 1, 2021 11:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants