Repository navigation
Conversation
ackSendAsync is reached only from actPassupAck, which only the Accepted state has an edge to, so the sole ACK ever offered to Acks() is the one to a 2xx. Nothing receives it: DialogServer reads Acks() on the non-2xx branch, and that ACK goes to actConfirm, which does not pass up. So the non-blocking send always failed, a goroutine was spawned to hold the ACK, and at Timer L it logged "ACK missed" at WARN. A two hour soak produced 8939 of them, one per answered call. Buffering by one holds the ACK without the goroutine, and lets a consumer that arrives after the transaction is done still read it. The send can no longer block, so the default branch logs at Debug. Also fixes the Acks() comment: the channel is created in NewServerTx, not on demand. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
fridokus
force-pushed
the
ack-buffer
branch
from
September 17, 2026 07:11
f2bb744 to
2c1ac0d
Compare
Owner
|
The chosen fix only moves the existing Committed locally as |
emiago
added a commit
that referenced
this pull request
Oct 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ackSendAsyncis reached only fromactPassupAck, and only the Accepted state has an edge to it — so the only ACK ever offered toAcks()is the one to a 2xx. Nothing receives it:DialogServerreadsAcks()on the non-2xx branch, and that ACK goes toactConfirm, which doesn't pass up.So the non-blocking send always failed, a goroutine was spawned to hold the ACK, and at Timer L it logged
ACK missedat WARN. A 2h soak produced 8939 of them — one per answered call.A one-slot buffer holds the ACK without the goroutine, and lets a consumer that arrives after the transaction is done still read it. The send can no longer block, so
defaultlogs at Debug.Also corrects the
Acks()comment: the channel is created inNewServerTx, not on demand.Two tests: an ACK sent before the receive is still delivered (so the buffer can't be dropped without the goroutine coming back), and nothing logs
ACK missedwhen no one ever receives.Separately, and not touched here:
DialogServerwaiting onAcks()in the non-2xx branch looks wrong, since only the 2xx ACK is ever passed up. Happy to open an issue if you want that changed.