Skip to content

Simplify Future for RequestDispatch - #554

Open
stepancheg wants to merge 2 commits into
google:mainfrom
stepancheg:future-for-dispatch
Open

Simplify Future for RequestDispatch#554
stepancheg wants to merge 2 commits into
google:mainfrom
stepancheg:future-for-dispatch

Conversation

@stepancheg

@stepancheg stepancheg commented Mar 25, 2026

Copy link
Copy Markdown
Contributor

Stop type-erasing RequestDispatch::terminal_error.

The field is already on a type generic over the transport, so it can be
Option<ChannelError<C::Error>>. That removes ChannelError::{upcast_any, downcast} and the dyn Any round-trip in poll.

The context is this: terminal_error only works for inflight requests, but this
is not enough to provide good diagnostics if we are sending request to a
dispatch which has already failed.

Instead, there can be a field like Arc<OnceCell<SomeError>> shared between
dispatch and channel, so that if writing to channel or reading back from oneshot
channel fails, we could attach that error as error source.

So I start by cleaning up existing code.

@stepancheg
stepancheg force-pushed the future-for-dispatch branch 2 times, most recently from 2b4f63b to 728d8af Compare March 25, 2026 19:02
@stepancheg

Copy link
Copy Markdown
Contributor Author

Bump.

@stepancheg

Copy link
Copy Markdown
Contributor Author

Hello?

@tikue

tikue commented May 31, 2026

Copy link
Copy Markdown
Collaborator

Sorry for the delay, I'll take a look soon.

@stepancheg

Copy link
Copy Markdown
Contributor Author

Bump.

Comment thread tarpc/src/client.rs
.clone()
.downcast()
.expect("Invariant: ChannelError must store a C::Error");
ready!(self.shut_down_with_terminal_error(cx, e.clone().upcast_error()));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I'm not sure this change works, because shut_down_with_terminal_error can return Pending and then be called again. The request dispatcher closes the pending requests channel and then waits for the other end of the channel to be closed, so Pending can be returned if the other end isn't immediately closed.

Sorry that there aren't good tests for this that would have caught this problem earlier. Would you like to try adding a test?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Instead, there can be a field like Arc<OnceCell<SomeError>> shared between dispatch and channel, so that if writing to channel or reading back from oneshot channel fails, we could attach that error as error source.

That sounds good too, but won't there be a regression if this PR is merged without the new field?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good catch, thanks! This PR is now much simpler, only removes Any and uses generics. But most of complexity I wanted to remove, stays.

I used AI to add tests that reproduce the problem. Tests are not very readable, not sure how much value in them.

@tikue

tikue commented Aug 1, 2026

Copy link
Copy Markdown
Collaborator

Apologies again for the long delay. Life got in the way.

@stepancheg
stepancheg force-pushed the future-for-dispatch branch 3 times, most recently from cce6864 to 8b8c31c Compare August 2, 2026 23:43
@stepancheg
stepancheg force-pushed the future-for-dispatch branch from 8b8c31c to 79427a3 Compare August 2, 2026 23:44
@stepancheg
stepancheg requested a review from tikue August 2, 2026 23:58
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.

2 participants