Repository navigation
daemon: a datagram send the client can get an answer to - #494
Merged
Merged
Conversation
CmdSendTo is fire-and-forget: a failed send is only logged, so pilotctl dgram and Driver.SendTo report success for datagrams the daemon never sent. It cannot start replying — the IPC envelope has no request ID, and existing drivers deliver any CmdError to whichever request they have in flight. Add an opt-in pair, CmdSendToConfirm (0x39) / CmdSendToOK (0x3A): same payload, dispatched inline like CmdSendTo so datagrams keep their order, replying OK once the datagram is handed to the tunnel or CmdError with the cause. Advertised as the dgram_confirm feature in the info reply. CmdSendTo is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3 tasks done
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
1 participant
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.
Pull Request
Summary
SendToover IPC is fire-and-forget: the daemon logs a failed datagram and the client is told nothing. In a lab, 1,617 sends failed inside the daemon (ephemeral ports exhausted) while everypilotctl dgramexited 0. The daemon cannot simply start replying: the IPC envelope has no request ID, and an existing driver hands any error frame to whichever unrelated request it has in flight.Changes
CmdSendToConfirm(0x39) /CmdSendToOK(0x3A): the same payload asCmdSendTo, dispatched inline so datagrams keep their order, answered with OK once the datagram is handed to the tunnel orCmdErrorwith the cause.dgram_confirmis listed in the info reply's features.CmdSendTois unchanged and still silent, so existing drivers behave exactly as before.This is the daemon half. The driver method is in pilot-protocol/common (
feat/dgram-confirm);pilotctl dgramswitches to it in a follow-up once that is released.Test Plan
go build ./...,go vet ./..., unit suite withGOWORK=offTestIPCSendToConfirmRepliesWithOutcome(unit),TestSendToConfirmReportsDaemonSendFailure(integration, raw frames)go test -parallel 4 -count=1 ./tests/: one failure,TestManualSnapshotTrigger, which uses fixed port 127.0.0.1:18080; another process on the test machine was listening there, and the test fails the same way on a cleanmaincheckoutChecklist
go.mod/go.sumunchanged🤖 Generated with Claude Code