Add --json output mode to send - #107
Open
BigCatMellow wants to merge 1 commit into
Open
Conversation
hcom send prints only human-readable feedback on success, and the
event ID that send_message() writes to the DB (db.log_event) was
discarded before it ever left the function (let _event_id = ...).
That makes it impossible for a caller to learn which exact event a
send became without guessing (e.g. "read the newest event"), which
is unsafe under concurrency or retries.
Adds an opt-in --json flag that prints one line of JSON
({"event_id": <int>, "delivered_to": [...]}) instead of the normal
feedback, mirroring how --quiet already provides an alternate output
mode without changing default behavior. send_message()'s return type
now carries the event ID out to its one caller in cmd_send (and the
few unit tests that call it directly).
BigCatMellow
added a commit
to BigCatMellow/MAPS_Lean
that referenced
this pull request
Aug 18, 2026
MAPS wants exact event-correlation IDs from hcom send's --json output (work/tasks referencing this were blocked on this) but the upstream PR adding it (aannoo/hcom#107) is open and unreviewed, with no maintainer response as of 2026-08-17. hcom is not vendored into this repo -- it's installed separately via uv/pip (see docs/FRESH_INSTALL.md) -- so this just points the install source at the fork branch that already has the fix, instead of waiting on upstream. HCOM_SOURCE is a script variable/env override, defaulting to the fork's git+https URL, with the revert path (back to plain "hcom") documented inline and in FRESH_INSTALL.md. Verified: `pip install git+https://github.com/BigCatMellow/hcom@send-json-event-receipt` in a clean venv builds and installs hcom 0.7.25 successfully; confirmed via `gh pr diff 107` that the fork branch's send.rs actually adds the --json flag. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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.
What
Adds an opt-in
--jsonflag tohcom sendthat prints a single line of JSON on success instead of the normal human-readable feedback:{"event_id": 3, "delivered_to": ["nova"]}Why
send_message()already computes the event ID it just logged (db.log_event(...)), but the value is discarded (let _event_id = ...) and the function's return type only ever exposeddelivered_to. There's currently no way for a script or another tool wrappinghcom sendto learn which exact database event a given send became — a caller would have to guess (e.g. "read the newest event afterward"), which isn't safe under concurrency or retries.How
send_message()'s return type changes fromResult<Vec<String>, String>toResult<(i64, Vec<String>), String>so the already-computed event ID survives the call. All call sites (the one production call incmd_send, plus the unit tests in this file that callsend_message()directly) are updated to match.cmd_send()gets a newif args.json { ...; return 0; }branch inserted immediately before the existingif args.quiet { ... }check — structurally parallel to how--quietalready provides an alternate output mode. When--jsonis not passed, execution reaches the exact same code as before this change.--jsondoesn't change anything on a failed send (stillError: ...to stderr, exit 1).Testing
cargo build— clean, no warnings.cargo clippy --all-targets -- -D warnings— clean.cargo test— 2169 passed, 3 pre-existing failures unrelated to this change (confirmed viagit stash+ rerun against the unpatched tree:db::tests::test_open_raw_rejects_non_temp_path,db::tests::test_open_raw_rejects_temp_symlink_to_non_temp_path,paths::tests::test_is_test_temp_path_rejects_non_temp— all fail identically without this diff, caused by running the checkout under a temp path).send --jsoncalls print monotonic real event IDs,--jsonoutput is exactly one parseable JSON line with nothing else on stdout,--json --quiettogether still prints exactly one JSON line, and error paths are unaffected.Kept the diff as small as possible — one file, no unrelated changes.