Pin mcp-server-time e2e image by digest

[amirejaz]

Summary

E2E Tests Core (proxy) is failing on every PR in the repo with timeout waiting for MCP server to be ready. Three specs fail: TimeStreamableHttpMcpServer, and both Proxy Stdio E2E proxy modes.

Same root cause as #6159, a different image. Tag 2026.7.10 of mcp-server-time is mutable; dockyard rebuilds it and resolves Python dependencies fresh each time. The 2026-07-31 rebuild picked up the mcp Python SDK 2.0.0 released 2026-07-28. mcp-server-time imports McpError from mcp.shared.exceptions, which 2.x moved, so the container now exits on startup:

ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'

The server never becomes ready, and the proxy suites time out waiting for it.

• Pin mcp-server-time to the last build that resolved a 1.x mcp (sha256:5cca77de…, the 2026-07-27 build of the same tag).
• Point the two affected suites at the pinned constant rather than the "time" registry entry. The registry resolves "time" to the moving :2026.7.10 tag and is not fixable from this repo, so referencing it leaves CI hostage to an upstream rebuild.
• stdio_proxy_over_streamable_http_mcp_server_test.go gains an explicit --transport stdio, which the registry entry previously supplied.

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• E2E tests (task test-e2e)
• Linting (task lint-fix)

Ran both affected suites locally against a locally-built thv:

	unpinned ("time")	pinned digest
TimeStreamableHttpMcpServer	FAIL — timeout waiting for MCP server to be ready	pass (43s)
Proxy Stdio E2E (both modes)	—	pass (87s)

The unpinned run reproduces the CI error exactly, at the same assertion (stdio_proxy_over_streamable_http_mcp_server_test.go:60).

Also confirmed the two builds differ by driving each directly over stdio with an initialize request: the pinned digest returns a result, tag 2026.7.10 exits with the ImportError above.

task lint-fix is clean on the changed files; the one remaining finding (cmd/thv/app/upgrade.go gosec G115) is pre-existing and untouched.

Does this introduce a user-facing change?

No. Test-only.

Special notes for reviewers

This is repo-wide, not specific to any PR. Confirmed by re-running an unrelated PR's previously-green E2E job: same code, 14 hours later, same failure. Unrelated open PRs (#6157, #6150) show the identical 35 Passed | 3 Failed. The last green proxy runs were 2026-07-30 ~14:25.

Coverage tradeoff. These two suites no longer exercise registry-name resolution for "time". That path is still covered by the sibling cases in proxy_stdio_test.go that run "osv", so nothing is lost overall — and the alternative is CI that any upstream rebuild can break.

Second mutable-tag breakage in two days. #6159 pinned ida-pro-mcp for the same reason. Both are dockyard uvx images with unbounded mcp>= constraints meeting the 2.0.0 release. A sweep pinning the remaining dockyard uvx images by digest — or capping the constraint upstream — would stop this recurring; pagerduty-mcp is already safe because it caps mcp[cli]~=1.8.

Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.56%. Comparing base (b7e824c) to head (d367826).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6160   +/-   ##
=======================================
  Coverage   72.56%   72.56%           
=======================================
  Files         736      736           
  Lines       76331    76331           
=======================================
+ Hits        55391    55393    +2     
+ Misses      17019    17017    -2     
  Partials     3921     3921           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.