sapedbd has no version command; it only says so in a log line

Type

Debt — a missing affordance, not a missing capability

Found while

SAPE-1

Triage

Defer

Status

Open

Severity

Low — the question is answerable two other ways; this is the first place somebody will look

Description

SAPE-1 gave the daemon a version and two ways to state it: the first line it prints when it starts listening, and the productVersion field of every welcome. Both require the daemon to run.

Somebody holding the binary — in a container they are trying to identify, on a host they do not have the secret for, writing a bug report — cannot ask it what it is. cmd/sapedbd/main.go parses no arguments at all: it builds a context, calls service.Run, and exits. An argument is not refused; it is not looked at.

The CLI has exactly the command that is missing here, and its own declaration explains why it exists: internal/cli/cli.go:324-338 marks version standalone: true — the only command in the table that names no database — "Asking a binary what it is must work before any of those exist — on a host with no databases, in a container someone is trying to identify, in a bug report written by somebody who was never given the secret." That reasoning applies to the daemon at least as strongly, and the daemon did not get it.

Evidence

Measured at sapedb 248fa02, by building and running, not by reading:

$ go build -o /tmp/sapedbd ./cmd/sapedbd
$ env -u SAPEDB_SECRET /tmp/sapedbd version
sapedb: SAPEDB_SECRET is not set, so no connection could be verified
exit 1

$ env -u SAPEDB_SECRET /tmp/sapedbd --version
sapedb: SAPEDB_SECRET is not set, so no connection could be verified
exit 1

• The argument is silently discarded, not refused. Both invocations take the ordinary startup path and fail on the missing secret, so the error a user gets says nothing about the thing they asked for. That is slightly worse than a clean "unknown command".
• Compare: sapedb version (the CLI) prints sapedb <version> and exits 0, with no secret, no directory and no database.
• The two working answers both need a running process:
  • internal/service/service.go:196-197 — sapedb %s listening on %s as %s, databases in %s, with build.Version first. That needs a valid SAPEDB_SECRET, a bindable address and a writable directory before it prints anything.
  • The welcome's productVersion (internal/server/server.go:544, 580), which needs a connection and therefore a connection string.
• The version itself is present in the binary either way: both commands link the same internal/build and are stamped by the same STAMP in the Makefile (Makefile:33-34) and the same -ldflags in the Dockerfile. So this is purely about there being no way to ask.

Triage

Does it lose data, break a promise on a public surface, or stop somebody installing and running? No. The version is stamped into the daemon and reachable two ways, both of which are measured (version_live_test.go covers the stamped build and the client reading productVersion). No promise made anywhere says sapedbd takes arguments — its package doc says the opposite, that everything comes from the environment so the same image runs unchanged in a container, under systemd, or on a laptop.

Defer. The honest summary is that the capability shipped and one affordance did not. SAPE-1's acceptance criteria were about the version being embedded, printable and readable over a connection, and all three hold.

Worth recording anyway, because "no arguments, everything from the environment" is a good rule that has one natural exception, and version is it: it is the question you ask before you have an environment to configure.

If deferred, what it costs to wait

• Nothing freezes. Adding one argument to a binary that currently reads none cannot break anybody, now or after the tag — there is no existing caller passing arguments whose meaning could change.
• The cost is paid in support, repeatedly and in small amounts: every "which version is this container running?" gets answered by starting the daemon with a valid configuration, or by reading a log the person may not have. docker run --rm image version is the shape people will try first, and it currently fails with a message about a secret.
• It also makes SAPE-3 (prebuilt binaries and a published image) less useful than it should be: the whole point of a published artifact is that somebody who did not build it can identify it, and for the daemon they cannot.
• Cheap and worth doing together when it is done: make an unrecognised argument a refusal rather than a silence. A daemon that accepts and ignores --version is a daemon that will accept and ignore a mistyped flag somebody thought was configuring it.