Skip to content

test(health): assert detectBlindspot's branch, not the build that made the DB - #24

Merged
MXAntian merged 1 commit into
mainfrom
fix/blindspot-test-hermetic
Aug 3, 2026
Merged

MXAntian merged 1 commit into
mainfrom
fix/blindspot-test-hermetic

Conversation

@MXAntian

@MXAntian MXAntian commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

The problem

The (d) missing recall_log reads as "not instrumented" check relies on the table being absent at that point. That is not a property of the test — it is a property of whichever engine created DB_PATH.

A build that instruments recall creates recall_log in initMemory(). The "no table" state becomes unreachable and the check fails with a perfectly correct value:

✗ (d) missing recall_log reads as "not instrumented"
    — {"available":false,"reason":"no recall_log rows in the last 7 days"}

Nothing is wrong with detectBlindspot. The test simply cannot reach the branch it wants to assert.

The fix

DROP TABLE IF EXISTS recall_log before the check — one line, tests the logic either way. The test already recreates the table two lines later for the empty/stalled cases, so this fits what it was already doing.

How it turned up

Rebasing a downstream runtime (which does instrument recall) onto main. It reads as a real regression in #15's work and costs a while to disbelieve — worth removing.

Verification

engine before after
no instrumentation 63/63 63/63
with instrumentation 62/1 63/0

🤖 Generated with Claude Code

…e the DB

The "(d) missing recall_log reads as not instrumented" check relies on the
table being absent at that point. That is not a property of the test — it is a
property of whichever engine created DB_PATH. A build that instruments recall
creates recall_log in initMemory(), the "no table" state becomes unreachable,
and the check fails with a perfectly correct value:

  ✗ (d) missing recall_log reads as "not instrumented"
      — {"available":false,"reason":"no recall_log rows in the last 7 days"}

Nothing is wrong with detectBlindspot there; the test simply cannot reach the
branch it wants to assert. Dropping the table first tests the logic either way.

Found while rebasing a downstream runtime (which does instrument recall) onto
main — the kind of failure that reads as a real regression and costs a while to
disbelieve.

Verified against both engines: 63/63 on a build without instrumentation, and
62/1 -> 63/0 on one with it.

Co-authored-by: 千夏 <qianxia@clawgamers.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@MXAntian
MXAntian marked this pull request as ready for review August 3, 2026 05:53
@MXAntian
MXAntian merged commit c69069f into main Aug 3, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant