[data] Service & worker contract compliance: corrupt bag reported as ready, untyped parse errors, wrong tool count

[rahulkatiyar19955]

Severity

Medium

Summary

The parser service and MCP workers violate their own contracts on failure and reporting: a total bag-parse failure is reported as a successful empty session, the /parse error response is an untyped string returned with HTTP 200, and a worker /health endpoint reports a hardcoded tool count that disagrees with the tools it actually registers.

Findings

• DB3 path swallows total parse failure and returns an empty-but-ok:true result — mcap_parser/parser.py:476-614 — The whole Reader body is wrapped in a try/except that only appends to warnings (around mcap_parser/parser.py:568-570). A reader-level failure on a corrupt db3 still returns {"ok": True, …, "logs": [], "total_messages": 0}, and the backend then marks the session status=ready (backend/app/api/sessions.py:74-140) — so a corrupt bag presents as a successfully ingested, empty session. Fix: distinguish "parsed, some messages skipped" from "could not open/read the bag" — re-raise or return ok:false when zero connections/messages were read due to a reader exception.

• mcap-parser /parse returns HTTP 200 with {ok:false, error:str} instead of the typed envelope — mcap_parser/app.py:34-42 (caller backend/app/services/parser.py:465-470) — On failure it returns {"ok": False, "error": str(exc)} — a bare string rather than the {code, message, retryable} contract — and does so with a 200 status, so the retryable signal is lost and callers cannot distinguish success from failure by status code. Fix: return {"ok": False, "error": {"code": "parse_error", "message": str(exc), "retryable": False}} with a non-2xx status, and have the caller surface the structured error.

• MCP worker /health reports a hardcoded tool count that disagrees with registered tools — mcp_workers/rosbag_reader/server.py:36,44 (other workers pass hardcoded literals too) — rosbag_reader registers 4 tools (server.py:33-36) but reports tools: 3 via start_health_server(..., lambda: 3) (server.py:44). The /health tools field is consumed by the Agents/MCP screen through mcp_workers/_shared/health.py:38-42, so the count is already wrong and will keep drifting as tools are added. Fix: derive the count from the registry (e.g. len(mcp._tool_manager.list_tools())) for every worker; at minimum correct the rosbag_reader literal 3 → 4.

Project-rule reference

n/a