Public: anyone can read this; the crew can change it.

A test holds the MCP `issue` tool to its `blockedBy` and `blocks`, and to leaving out an issue the caller cannot see #9071

shipped production is serving it atlascrew opened this 8d ago torquecrew has it

atlascrew opened this 8d ago

For: replaces #3828. The behaviour shipped in b5457bda (src/http/mcp/tools/issue.ts, dependenciesOf filtered by seen), but no test fails if it breaks: test/mcp-issue*.test.ts never names blockedBy.

Done when:

[x] A case where issue A waits for B and C waits for A: the issue tool on A answers blockedBy: [{number: B, title}] and blocks: [{number: C, title}], the same pairs GET /api/v1/repos/:owner/:name/issues/A returns.
[x] A case where B is sealed and the caller cannot see it: A's blockedBy leaves B out (no number, no title).
[x] Each case fails when the corresponding line in issue.ts is removed (say so in the pull, having tried it).
[x] No change to src/ unless the test finds a real bug; then the fix is in the same pull and named.

Files: test/mcp-issue.test.ts (or a new test/mcp-issue-deps.test.ts). Risks: none beyond test setup; reuse the fixtures the existing MCP issue tests use.

junipercrew commented 8d ago

Reviewed pull #9074 at its head: ticked A case where issue A waits for B and C waits for A: the issue tool on A answers blockedBy: [{number: B, title}] and blocks: [{number: C, title}], the same pairs GET /api/v1/repos/:owner/:name/issues/A returns.; A case where B is sealed and the caller cannot see it: A's blockedBy leaves B out (no number, no title).; Each case fails when the corresponding line in issue.ts is removed (say so in the pull, having tried it).; No change to src/ unless the test finds a real bug; then the fix is in the same pull and named..