A build cannot identify itself: the bridge reports only a version string, and the SHA is UI-only and configure-time stale

[on8st]

Three symptoms of one gap: there is no reliable way — for a person or a program — to find out which build is running.

1. The bridge cannot distinguish two materially different builds

ping returns:

{QStringLiteral("app"),     QStringLiteral("AetherSDR")},
{QStringLiteral("version"), QCoreApplication::applicationVersion()},
{QStringLiteral("authRequired"), ...}, {QStringLiteral("readOnly"), ...}

version is "26.9.3" on origin/main and on a local integration branch carrying unmerged PRs. Those can differ in ways that change measurements: the branch I was running carried #5752 and #5753, so its dBm conversion was fullScale − lna while main's was dbfs + 0.0 + (referenceLna − lna) — about 19 dB apart at every gain. Both answer ping identically.

This cost real work. I analysed main's conversion for hours against measurements taken through the other binary, and the mismatch only surfaced when someone ran strings on the executable to recover the SHA. A bench harness had no way to ask.

2. The SHA exists but is UI-only

AETHER_GIT_SHA is compiled in and surfaced in exactly one place — the About dialog. Nothing reads it programmatically, and nothing shows it on the main window.

3. It is captured at configure time, so it goes stale

CMakeLists.txt runs git rev-parse --short HEAD inside the configure step. The About dialog's own tooltip already admits the consequence:

the SHA is baked at CMake configure time, so a dev who runs cmake --build after a new commit without re-configuring sees the previous SHA here

A stale build identity is worse than none — it is confidently wrong.

---

Proposal

One change, three surfaces, because splitting them would land one and orphan the others.

(a) Capture git describe, at build time. One string carries both halves of the question:

git rev-parse --short HEAD           →  7e841682
git describe --tags --always --dirty →  v26.9.3-68-g7e841682

That reads as 68 commits past the v26.9.3 release, at 7e84168, and --dirty flags uncommitted work. Moving the capture into a generated header regenerated per build fixes (3); a release build still gets a bare v26.9.3.

(b) Add it to ping — additive, nothing removed:

{ "app": "AetherSDR", "version": "26.9.3",
  "build": { "describe": "v26.9.3-68-g7e841682", "sha": "7e841682",
             "baseline": "v26.9.3", "commitsSinceTag": 68, "dirty": false } }

ping is already in the kSafe read-only verb set, so this grants no new authority — it is a payload addition to an existing read-only verb. health would be an equally reasonable home if you would rather keep ping minimal.

(c) Show it in the status bar via addPermanentWidget(), only when the build is not a clean release tag. Silent for users on a release; visible exactly when someone is running something unofficial. This half was requested by an operator who noticed the transient bottom-left messages and wanted to know what he was actually running.

Why (b) is the valuable half

A harness can then pre-register the build it measured through and refuse, or flag, when the binary does not match what the analysis assumes. In our case that would have failed at the first gate instead of after the conclusions were written — and it generalises to any bug report that includes a bridge transcript.

Deliberately not proposed

Anything that changes what version means, or that exposes branch names or remotes — describe is enough, and a branch name is not a build identity.

Happy to implement whichever parts you want. (a) and (b) are small; (c) has a design question about placement and whether it belongs behind a setting.

🤖 Generated with Claude Code

[on8st]

Implemented locally and load-bearing on a real run, so this is no longer a proposal. Reporting what it cost and what it caught, because the catch is the argument for it.

Shape. A CMake step reads git describe --tags --always --dirty at BUILD time — not configure — and writes a generated header. configure_file() only rewrites when the content differs, so an unchanged HEAD costs nothing and triggers no rebuild. The bridge's ping then carries:

"build": {"describe":"v26.9.3-74-gf9cefa84","sha":"f9cefa84",
          "baseline":"v26.9.3","commitsSinceTag":74,
          "dirty":false,"isRelease":false}

One design note worth stating, because I got it wrong first: the identity must be captured at build time. I tried refreshing it with a reconfigure and it did nothing — the value only moves when the target rebuilds, which is correct (a reconfigure is not a rebuild) but is the opposite of where I first looked.

What it caught, the same day it existed. A bench run's gate asserts that the binary answering IS the tree it was built from. That assertion only became possible with this:

• the worktree's git rev-parse --short HEAD → f9cefa84
• ping's build.sha → f9cefa84
• the string baked into the image, found by strings → f9cefa84

Three independent routes agreeing. Before this, the gate could only grep the binary for an 8-hex SHA it had been told to expect — a constant in the run script. That constant was stale, the gate refused, and refusing is what made us look at the run's other pinned constant: a dBm full-scale figure that belonged to a different build. Had the identity check not failed first, every raw dBFS in that record would have been 17 dB out and entirely plausible.

So the value is not "nice provenance in the record". It is that a run can tell it is being lied to by its own configuration.

What is NOT done here. It is one CMake module, one generated header, one ping field and a status-bar label compiled out on release builds. No protocol version, no capability, no settings key. The status-bar half is cosmetic and separable if only the bridge field is wanted. dirty is git describe's own notion and says nothing about what is dirty.

Happy to file it if the shape is acceptable — say the word and it goes up as a PR rather than sitting here.

🤖 Generated with Claude Code

[on8st]

Independent evidence for this issue, from someone else's crash rather than our argument.

#5813 is a FLEX-6600M crash report filed by @n9rix. Its Windows Event Viewer block opens with:

Faulting application name: AetherSDR.exe, version: 0.0.0.0

and the Windows Error Reporting block that follows carries both versions side by side:

Sig[0]  Package      AetherSDR.AetherSDR_26.9.3.0_x64__j645gtt0jd8mw
Sig[2]  Application  0.0.0.0

So the release is on the packaging and absent from the executable — and the executable is what a crash report names. A maintainer reading that report cannot tell which build faulted without going back to the reporter.

This is a different layer from what this issue proposes, and our local implementation would not have fixed it. Worth being precise, because the two are easy to conflate:

	surface	state
this issue	the bridge's ping reply	implemented locally — v26.9.3-74-gf9cefa84, dirty: false
the crash report	the Win32 VERSIONINFO resource on the .exe	unset on main; nothing in our branch touches it

Same class — the binary cannot say what it is — at two different layers, and only one of them is addressed here. We are not claiming the work on this issue would have made that crash readable; it would not have.

What it does establish is that the class has a real operational cost, observed on a real fault on a platform we do not develop on. If the VERSIONINFO half is worth closing too, that is a separate and probably smaller change, and it belongs to whoever owns the Windows packaging rather than to this issue.

🤖 Generated with Claude Code