What
On Bitbucket Cloud, pr status goes through cloud.get_pull_request_status() (tools/bitbucket/src/magpie_bitbucket/cloud.py:495-510). It fetches only the /statuses endpoint and returns:
{"pull_request_id": ..., "values": [...], "paginated": True, "pages": [...]}
normalize.pull_request_status() (normalize.py:306-327) reads the state from raw["pull_request"] and the head commit from raw["commit"]. The Cloud payload has neither, so every Cloud pr status reports "state": "unknown" and "commit": null, whatever the pull request's real state. The Data Center backend sets both keys (datacenter.py:277-300), so it is only Cloud.
cloud.get_pull_request_merge_checks() (cloud.py:476-492) already works around the gap: it falls back to the reviews payload when status.get("pull_request") is missing.
test_cli_pr_status_cloud (tests/test_bitbucket.py:878-887) mocks get_pull_request_status() with a hand-built dict that has a commit key the Cloud backend never produces, so the real Cloud payload is never exercised and the test passes.
Why it matters
state is what a caller uses to tell an open pull request from a merged or declined one before acting on its checks. The impact is low today: no skill binds to this adapter yet (pr-triage/contract-binding.md names github, jira-patch and mail-patch as change-request backends). The build checks themselves are reported correctly; it is the pull request metadata that is missing, although the API has it.
Suggested fix
- Have Cloud
get_pull_request_status() also fetch the pull request and return it under pull_request, with the source commit under commit, the shape Data Center already returns.
- Test the Cloud path from the backend's real output: either record the fixture from
get_pull_request_status(), or go through the CLI with a fake transport, as tools/gitlab/tests/conftest.py does.
Related
Found via
An architecture pass over tools/bitbucket; reproduced by reading the Cloud and Data Center payloads on main (37670575).
What
On Bitbucket Cloud,
pr statusgoes throughcloud.get_pull_request_status()(tools/bitbucket/src/magpie_bitbucket/cloud.py:495-510). It fetches only the/statusesendpoint and returns:{"pull_request_id": ..., "values": [...], "paginated": True, "pages": [...]}normalize.pull_request_status()(normalize.py:306-327) reads the state fromraw["pull_request"]and the head commit fromraw["commit"]. The Cloud payload has neither, so every Cloudpr statusreports"state": "unknown"and"commit": null, whatever the pull request's real state. The Data Center backend sets both keys (datacenter.py:277-300), so it is only Cloud.cloud.get_pull_request_merge_checks()(cloud.py:476-492) already works around the gap: it falls back to the reviews payload whenstatus.get("pull_request")is missing.test_cli_pr_status_cloud(tests/test_bitbucket.py:878-887) mocksget_pull_request_status()with a hand-built dict that has acommitkey the Cloud backend never produces, so the real Cloud payload is never exercised and the test passes.Why it matters
stateis what a caller uses to tell an open pull request from a merged or declined one before acting on its checks. The impact is low today: no skill binds to this adapter yet (pr-triage/contract-binding.mdnamesgithub,jira-patchandmail-patchas change-request backends). The build checks themselves are reported correctly; it is the pull request metadata that is missing, although the API has it.Suggested fix
get_pull_request_status()also fetch the pull request and return it underpull_request, with the source commit undercommit, the shape Data Center already returns.get_pull_request_status(), or go through the CLI with a fake transport, astools/gitlab/tests/conftest.pydoes.Related
pr statuspath.Found via
An architecture pass over
tools/bitbucket; reproduced by reading the Cloud and Data Center payloads onmain(37670575).