Found while answering the version question on #1977. Filing separately because it is a defect in its own right and should not be bundled into that change.
The container branch never succeeds
blacklist-test.sh:253-254 tries the database inside the application container first, then falls back to the host:
if ! count=$(ssh_t "docker exec $(printf %q "$TARGET_CONTAINER") sqlite3 $(printf %q "$TARGET_DB_PATH") $qq" 2>/dev/null); then
count=$(ssh_t "sqlite3 $(printf %q "$TARGET_DB_PATH") $qq" 2>/dev/null || echo "")
The application image has no sqlite3 binary. Checked on a live deployment:
container: OCI runtime exec failed: exec: "sqlite3": executable file not found
host : 3.45.1
That is correct by design rather than a packaging mistake: the server uses a pure-Go SQLite driver with no CGO (Dockerfile line 15 says so in as many words), and the apk add line installs mosquitto, mosquitto-clients, supervisor, caddy and wget. The CLI was never needed.
So the first branch fails on every run, silently, and the script always uses the host binary. A fallback that is the only path is a fallback in name only, and it costs a docker exec round trip per query plus the misleading impression that the container is being queried.
Failures and empty results look identical
Both branches discard stderr, and the second adds || echo "". So count is the empty string when:
- the query returned no rows, which is a legitimate answer
sqlite3 is not installed on the host either- the database path is wrong
- the SQL is malformed
- SSH failed
A QA script that cannot distinguish "the blacklist is working" from "I could not ask" is reporting on itself, not on the system.
Suggested shape
Probe once for a working sqlite3 and where it lives, then use it. If neither location has one, exit with a message naming what is missing rather than proceeding with an empty count. Keep stderr on failure paths, or capture it into the failure message.
Related: #1977 rewrites the query construction in this same call site. Whoever takes that one may find it easier to do this first, since both touch the same two lines. Not a blocker either way.
Found while answering the version question on #1977. Filing separately because it is a defect in its own right and should not be bundled into that change.
The container branch never succeeds
blacklist-test.sh:253-254tries the database inside the application container first, then falls back to the host:The application image has no
sqlite3binary. Checked on a live deployment:That is correct by design rather than a packaging mistake: the server uses a pure-Go SQLite driver with no CGO (
Dockerfileline 15 says so in as many words), and theapk addline installs mosquitto, mosquitto-clients, supervisor, caddy and wget. The CLI was never needed.So the first branch fails on every run, silently, and the script always uses the host binary. A fallback that is the only path is a fallback in name only, and it costs a
docker execround trip per query plus the misleading impression that the container is being queried.Failures and empty results look identical
Both branches discard stderr, and the second adds
|| echo "". Socountis the empty string when:sqlite3is not installed on the host eitherA QA script that cannot distinguish "the blacklist is working" from "I could not ask" is reporting on itself, not on the system.
Suggested shape
Probe once for a working
sqlite3and where it lives, then use it. If neither location has one, exit with a message naming what is missing rather than proceeding with an empty count. Keep stderr on failure paths, or capture it into the failure message.Related: #1977 rewrites the query construction in this same call site. Whoever takes that one may find it easier to do this first, since both touch the same two lines. Not a blocker either way.