feat(daemon): Negotiate media-send capability to skip stopping the daemon#27
Merged
Merged
Conversation
added 2 commits
June 4, 2026 02:57
…emon `tg msg send --sticker/--gif` unconditionally took the local MTProto path, so a running daemon's account lock forced users to `tg daemon stop` before sending media. That local-only gate existed only to dodge a stale daemon silently dropping the unknown Sticker/Gif SendQuery fields and posting an empty message. Have the daemon advertise a media-send capability in its Hello frame and route sticker/GIF sends over IPC when the connected daemon supports it. This is dev-build safe (a capability, not a version string) and additive on the wire: an older daemon omits the feature and the client falls back. When a media send hits a daemon too old to relay it, return a clear busy error pointing at `daemon restart` / `daemon stop` instead of a bare lock failure. Text sends are unchanged — version-agnostic and always routed through a reachable daemon.
The send-path gate is no longer the canDaemonSend helper (removed in favor of capability negotiation). Update reply's comments to point at newSend instead.
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.
Summary
msg send --sticker/--gifused to always take the local MTProto path, so a running daemon's account lock forcedtg daemon stopbefore every media send. That local-only gate existed only to avoid a stale daemon silently dropping the unknownSticker/GifSendQueryfields (→ empty message).msg.send.mediacapability in its Hello frame; the client routes sticker/GIF sends over IPC when the connected daemon supports it. Capability-based (not version-string), so it's dev-build safe and additive on the wire — an older daemon omits the feature and the client falls back.busyerror pointing atdaemon restart/daemon stop, instead of a bare lock failure. Text sends are unchanged (version-agnostic, always routed through a reachable daemon). File attachments still take the local path (IPC can't carry the bytes).Test plan
go build ./...,go vet ./...,golangci-lint run,go test ./...SupportsMediaSendtrue only when the feature is advertised (old daemon → false); Hello frame advertisesFeatureMediaSend.msg send --gifand--stickersucceed while the daemon holds the account lock (a local fallback wouldErrBusy), proving they routed over IPC — nodaemon stopneeded.busyerror (exit 72) with restart/stop guidance; a plain text send still routes through the old daemon.