Skip to content

test(mcp): ask for JSON where the coverage test asserts a JSON field - #2248

Merged
DeusData merged 1 commit into
mainfrom
fix/1714-freshness-merge-loss
Sep 20, 2026
Merged

DeusData merged 1 commit into
mainfrom
fix/1714-freshness-merge-loss

Conversation

@DeusData

Copy link
Copy Markdown
Owner

Restores main to a fully green mcp suite. One test, one request parameter, no assertion changed.

What broke

#1787 merged correct production code together with a test that cannot pass on today's main.

check_index_coverage answers in the compact table by default, where a field name never appears:

main.go main.go coverage_unavailable metadata_match read_source_and_reindex []

The test asserts on the JSON field spelling:

strstr(response, "\"freshness\":\"metadata_match\"")

Both halves are correct — they were written against different response formats. That branch was cut on 2026-09-02, before the default changed, and never rebased. The neighbouring coverage tests already pass "format":"json" for exactly this reason; this one predates them.

The fix

The request gains format=json; the assertions are untouched. Asserting the JSON field rather than a bare strstr for metadata_match is what keeps it exact — that value also appears in the table's recommended_action column and would be satisfied by any other path's row.

Verification

  • build/c/test-runner mcp318 passed, 0 failed, 4 skipped.
  • Before the change, the same suite on identical production code: 317 passed, 1 failed.
  • The second assertion (a seconds-truncated hash must report metadata_changed) executes and passes, so the test still exercises the nanosecond-exactness it was written to pin.

What this is not

Not a production defect. coverage_path_freshness on main uses cbm_path_info_utf8 exactly as #1787 intended, and the Windows second-vs-nanosecond truncation it fixes is gone.

How it reached main

I merged #1787 on a CI green that was 18 days old, without re-running it against the current base. The contract calls green perishable; I applied that reasoning to another PR the same day and skipped it here. Nothing about @umi008's work was at fault — it passes on its own head.

#1787 landed correct production code and a test that cannot pass on today's
main. The test is the only thing wrong, and only in how it asks.

check_index_coverage answers in the compact table by default, where a field
name never appears:

    main.go main.go coverage_unavailable metadata_match read_source_and_reindex []

The test asserts on the JSON field spelling:

    strstr(response, "\"freshness\":\"metadata_match\"")

Both halves are right; they were simply written against different response
formats. The branch was cut on 2026-09-02, before that default changed, and
was never rebased -- its CI green is from a main that no longer exists. The
neighbouring coverage tests already pass "format":"json" for exactly this
reason; this one predates them.

So the request gains format=json and the assertions are untouched. Asserting
the field rather than a bare strstr for "metadata_match" is what keeps the
check exact: the value also appears in the table's recommended_action column
and would be matched by any other path's row.

Verified: build/c/test-runner mcp -> 318 passed, 0 failed, 4 skipped. Before
this change the same suite reported 317 passed, 1 failed on identical
production code.

What this is NOT: a production defect. coverage_path_freshness on main uses
cbm_path_info_utf8, exactly as #1787 intended, and the Windows second-vs-
nanosecond truncation it fixes is gone. I checked that by reading origin/main
rather than the local checkout, which was stale at 59a05eb and still carried
the old helper -- that misreading briefly convinced me the merge had dropped
the fix, and it had not.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
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