fix: Health check DB-error grep produced doubled "0\n0" on the healthy path

Run #2006 proved the deploy itself is fully working now: checks 1-5
all passed (HTTP 200, login content, CSS, service active, release
verified) -- only check 6 failed, and the log shows exactly why:

   [6/6] DB authentication errors found in logs (0
  0 occurrences)

`grep -c PATTERN` exits with status 1 whenever the count is 0, even
though it still correctly prints "0" to stdout. The old
`grep -c ... || echo "0"` therefore printed grep's own "0" AND (because
grep's nonzero exit triggered the `||`) a second "0" from the fallback
-- a two-line "0\n0" that can never equal the string "0" in the
subsequent `[ "$DB_ERRORS" = "0" ]` check. So the *healthy* case (zero
DB errors) was the one that always failed this check.

Fixed by using `|| true` instead of `|| echo "0"`: it neutralizes
grep's exit code (needed to avoid an instant abort under `set -e
-o pipefail`, same class of bug as the earlier `git config user.name`
incident) without adding any extra output.
This commit is contained in:
2026-07-12 01:18:45 +09:00
parent 1db1c46b32
commit 451d7939c0
+8 -1
View File
@@ -315,7 +315,14 @@ jobs:
# 2026-07-12: this check would have caught it, the HTTP check alone
# did not.)
sleep 2
DB_ERRORS=$(journalctl -u quantengine --since '1 minute ago' --no-pager 2>/dev/null | grep -c '28P01\|password authentication failed' || echo "0")
# NOTE: `grep -c` exits 1 when the count is 0 (no matches),
# even though it correctly prints "0". Combined with
# `|| echo "0"`, a healthy zero-error result triggered BOTH
# grep's own "0" output AND the fallback's "0", producing a
# two-line "0\n0" that never equals the string "0" below.
# Use `|| true` instead, which only neutralizes the exit
# code without adding a second line.
DB_ERRORS=$(journalctl -u quantengine --since '1 minute ago' --no-pager 2>/dev/null | grep -c '28P01\|password authentication failed' || true)
if [ "$DB_ERRORS" = "0" ]; then
echo "✓ [6/6] No DB authentication errors in recent logs"
else