Shipped daemons log version=unversioned, and conn= means two different things

[scgopi]

Two gaps in the #289 diagnostics, found by an end-to-end check of the shipped 0.1.64-beta5 (build 255). Everything else in #289 passed — this is what did not.

A. Every shipped daemon logs version=unversioned build=unversioned

DaemonIdentity reads Bundle.main, but the graphcoded target in Project.swift declares no infoPlist, and otool -l finds no __info_plist section in the shipped binary. Confirmed on the live daemon, not only in a test build.

So #289's acceptance criterion — "daemon startup identity/version so logs reveal client and daemon version skew" — is unmet in the field, even though the field is present and populated with a placeholder. A log that says unversioned looks like it is telling you something.

This matters more than a cosmetic gap: version skew is exactly what #295 and #310 turned out to hinge on, and a support log that cannot name the daemon's build cannot settle it.

One-line fix in Project.swift.

B. conn= means two different things

Record	conn= holds
connect, request, handled, disconnect	an integer, with the uuid8 in id=
write, write-stall, backlog-drop	the uuid8

So grep conn=51 misses the stall lines, and grep conn=FDFF93AC misses the request lines. You have to join through the connect line to see one connection's whole story — and anyone triaging a stall hits this first, which is the case the diagnostics exist for.

Pick one identifier per field name. id= already carries the uuid8 on the connect line, so the integer is the odd one out.

What passed, for the record

Worth stating because it is the thing #289 was built for, and it works:

event=write-stall conn=FDFF93AC fd=4 bytes=257012 remaining=248820 blocked_ms=263.1
event=write       conn=FDFF93AC ms=18084.6 blocked_ms=17982.5 errno=32
event=connect     conn=51 id=FDFF93AC peer=15063

peer=15063 is the wedged client's own pid, and a healthy peer's memoNode finished at handle_ms=4.9 alongside it — the blocked write and the healthy command legible side by side, which is precisely what could not be told during #288.

Also verified: all seven phases separately timed; request logged on receipt proven live (152 request lines against 144 handled, so 8 hung requests each already carried conn/seq/kind); the size bound real (6 MB driven through, always exactly .log + .log.1, no .2); no content leaks under 9 nonces through bodies, topics, memos, renames and failure paths; and the cost below the noise floor — a daemon with logging disabled was slower or equal in 6 of 7 rounds, at ~225 bytes per request.

Related: #289, #288

🤖 Generated with Claude Code

https://claude.ai/code/session_01BP43ags4cn8fq2ZZdv85J9