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(tonic): flush accumulated ready messages when status received #1756

Merged
merged 1 commit into from
Jun 25, 2024

Conversation

jfoster-twilio
Copy link
Contributor

#1423 introduced logic to buffer multiple ready messages in order to amortize the cost of sends to the underlying transport. This also introduced a change in behavior for tonic in the following scenario:

A stream of ready messages less than the yield threshold is trailed by a status. Previously the ready messages would all have been yielded from the stream and sent, followed by the status. After the change was introduced the status is yielded from the stream and sent but the accumulated ready messages in the buffer are never sent out.

This change adjusts the logic to restore the previous behavior while still retaining the amoritization benefits. Namely it flushes the accumulated ready messages prior to yielding the status ensuring they are sent out from the stream in the order they are read.

Motivation

When upgrading tonic versions in our application we noticed some of our existing integration tests started failing. The pattern in these failures was that they involved a server stream yielding a message which was followed shortly after by a status message, and the observed behavior was that the client only received a status message from the stream and not the message that was sent in the stream first. The intent is to fix this to unblock our upgrade of tonic and restore the previous behavior while still retaining the benefits of amortization introduced in #1423.

Solution

This change checks to see if there are any accumulated messages in the buffer after polling a status message from the underlying stream and yields them first. On the subsequent poll it will then yield the status message.

hyperium#1423 introduced logic to buffer multiple ready messages in order
to amortize the cost of sends to the underlying transport. This
also introduced a change in behavior for tonic in the following
scenario:

A stream of ready messages less than the yield threshold is
trailed by a status. Previously the ready messages would all
have been yielded from the stream and sent, followed by the
status. After the change was introduced the status is yielded
from the stream and sent but the accumulated ready messages in the
buffer are never sent out.

This change adjusts the logic to restore the previous behavior
while still retaining the amoritization benefits. Namely it
flushes the accumulated ready messages prior to yielding the status
ensuring they are sent out from the stream in the order they are read.
@djc djc added this pull request to the merge queue Jun 25, 2024
@djc
Copy link
Contributor

djc commented Jun 25, 2024

This makes a lot of sense, thanks!

Merged via the queue into hyperium:master with commit d312dcc Jun 25, 2024
16 checks passed
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