Public: anyone can read this; the crew can change it.
A test pins issue dependencies: a pull can neither wait nor be waited on, and another repository's issue is refused #7136
Check · Review · Land · Live done — Landed and live in production.
I added `test/dependency-refusals.test.ts`, which pins the refusals of issue dependencies. Its 3 tests pass and `tsc --noEmit` is clean. I changed no module, because the test found no wrong behaviour. Two of your three "done" items only hold in part, though, because of how the API route works.
shipped production is serving it deploy 97ab7b8
I added test/dependency-refusals.test.ts, which pins the refusals of issue dependencies. Its 3 tests pass and tsc --noEmit is clean. I changed no module, because the test found no wrong behaviour. Two of your three "done" items only hold in part, though, because of how the API route works.
- Issue waiting on a pull:
POST …/issues/:n/dependenciesanswers 422not_an_issue, and/mapshows no edge afterwards. - Pull waiting on an issue: the API cannot say
not_an_issuehere. The issues route doesn't serve a pull as the waiting side, so it answers 404. The test pins that 404 and callsaddDependencydirectly to pinnot_an_issue./mapshows no edge afterwards. - Another repository's issue: the route looks the blocker up by number inside the same repository, so
cross_repocan't come out of the API. A number that exists only in the other repository answers 422, with no edge on/map. The test pins that, and pinscross_repothroughaddDependencydirectly.
I left both routing behaviours alone. If you want the API to return not_an_issue for the pull case, the issues route would have to serve pulls. If you want it to return cross_repo, the blocker would need a form that names its repository. Either of those is a separate change.
I ran only the new test and the type check, not the whole suite.
Test-only change; no UI or runtime surface, so the preview is unchanged. The three tests pin the refusals through both the API and the core, and each checks that /map gains no edge. They are honest about the 404 and 422 the route gives in place of not_an_issue and cross_repo. Two things I would do next: (1) the pull-waits-on-issue case pins a 404 that comes from routing rather than from the dependency rules, so if the issues route ever serves pulls this test breaks for the wrong reason. Open an issue to make the route return not_an_issue and tighten the assertion then. (2) The cross-repo API check relies on the foreign number being higher than any number in this repo. Assert that explicitly (expect(foreign.number).toBeGreaterThan(pull.number)) so the setup cannot drift silently.
I added
test/dependency-refusals.test.ts, which pins the refusals of issue dependencies. Its 3 tests pass andtsc --noEmitis clean. I changed no module, because the test found no wrong behaviour. Two of your three "done" items only hold in part, though, because of how the API route works.POST …/issues/:n/dependenciesanswers 422not_an_issue, and/mapshows no edge afterwards.not_an_issuehere. The issues route doesn't serve a pull as the waiting side, so it answers 404. The test pins that 404 and callsaddDependencydirectly to pinnot_an_issue./mapshows no edge afterwards.cross_repocan't come out of the API. A number that exists only in the other repository answers 422, with no edge on/map. The test pins that, and pinscross_repothroughaddDependencydirectly.I left both routing behaviours alone. If you want the API to return
not_an_issuefor the pull case, the issues route would have to serve pulls. If you want it to returncross_repo, the blocker would need a form that names its repository. Either of those is a separate change.I ran only the new test and the type check, not the whole suite.
Closes #7133