Skip to content

chore-mcp-integration-tests-stale-skip-2026-06-10: revive MCP suite#72

Merged
emp3thy merged 1 commit into
mainfrom
ralph/chore-mcp-integration-tests-stale-skip-2026-06-10
Jun 11, 2026
Merged

chore-mcp-integration-tests-stale-skip-2026-06-10: revive MCP suite#72
emp3thy merged 1 commit into
mainfrom
ralph/chore-mcp-integration-tests-stale-skip-2026-06-10

Conversation

@emp3thy

@emp3thy emp3thy commented Jun 10, 2026

Copy link
Copy Markdown
Owner

Revives the MCP integration test suite that was parked behind a stale module-level skip ("Awaiting Phase 2 episodic service layer" — Phase 2 shipped long ago) and adds error-path coverage for tool handlers in better_memory/mcp/server.py, the repo's #1 hotspot. The obsolete test_memory_start_ui_returns_stub_error (asserting a stub error for a now-implemented tool) is deleted, the tools-list assertion is hardened against _tool_definitions(supports_synthesis=True), and 8 new handler error-path tests cover: missing required arg, invalid enum via inputSchema validation, unknown observation id, invalid outcome enum, episodes CHECK-constraint violation, malformed synthesis decision, stale episode_id, and already-synthesized episode.

Docs unaffected — test-only change, no tool registrations or schemas modified.

Closes chore-mcp-integration-tests-stale-skip-2026-06-10.

Test plan

  • tests/mcp/test_server_integration.py: 14/14 passed (previously 0 ran — whole module skipped)
  • Full suite: 1124 passed, 17 skipped, 0 failed (junit-verified; integration tests confirmed running in-suite)

PBI bundle: ralph-queue branch, .ralph/current/chore-mcp-integration-tests-stale-skip-2026-06-10/ (moves to pending-pr/ after this PR opens).

… integration suite, add handler error-path tests

Remove the stale module-level skip ("Awaiting Phase 2 episodic service
layer" — Phase 2 shipped long ago) so the MCP stdio integration suite
runs in the default test suite again. Delete
test_memory_start_ui_returns_stub_error, which asserted a stub error
for a tool that is now fully implemented. Assert the wire-visible tool
list against _tool_definitions(supports_synthesis=True) instead of a
hardcoded six-tool set.

Add eight error-path tests that are only reachable through the real
dispatch layer: missing required argument, invalid enum value (SDK
inputSchema validation), unknown observation id, invalid outcome enum,
episodes CHECK-constraint violation, malformed synthesize_next_apply
decision dict, stale episode_id, and already-synthesized episode.

Test plan: tests/mcp/test_server_integration.py 14/14 passed; full
suite 1124 passed / 17 skipped / 0 failed (browser UI tests excluded
in the sandboxed environment; pre-existing and unrelated).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Claude BugBot Analysis

Found 1 potential bug in this PR.

medium: 1

One logic bug in the new error-path tests: test_close_episode_constraint_violation_is_error uses an outcome value rejected by MCP SDK input validation, so the DB CHECK-constraint code path it claims to test is never reached.


resp = await session.call_tool(
"memory.close_episode",
{"outcome": "bogus", "close_reason": "goal_complete"},

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 MEDIUM: Test never reaches the claimed DB CHECK-constraint path

test_close_episode_constraint_violation_is_error passes {"outcome": "bogus", "close_reason": "goal_complete"} to memory.close_episode. The outcome field has an input-schema enum of ["success", "partial", "abandoned", "no_outcome"] (verified in server.py:520-527), so the MCP SDK rejects "bogus" with an input-validation error before the handler runs. The docstring explicitly claims this exercises "the DB-level constraint path" and that passing close_reason explicitly avoids the default_reasons[outcome] lookup masking the DB path — but neither the handler nor the DB is ever reached. The test will pass (an error is returned), but it provides no coverage of the DB CHECK-constraint path it claims to cover. To test a DB-level constraint violation, outcome must be a value that passes SDK enum validation but triggers the constraint in SQLite; since the SDK enum and DB CHECK constraint guard the same set of values, the DB constraint is structurally unreachable via MCP and this test cannot be written as described.

@emp3thy
emp3thy merged commit ee00e78 into main Jun 11, 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