mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 12 Actions Packages Projects Releases 15 Wiki Activity

pr-metadata.sh: normalized schema omits merged/merged_by/merge_commit_sha — wrapper-only consumers cannot see merge state #1221

New Issue
Open
opened 2026-08-13 21:29:53 +00:00 by Ghost · 0 comments
Ghost commented 2026-08-13 21:29:53 +00:00
Copy Link
Copy Source

Defect

packages/mosaic/framework/tools/git/pr-metadata.sh normalizes PR data into a JSON schema that contains no merge-state fields at all: no merged, no merged_by, no merge_commit_sha (verified against main: zero occurrences of merged in the script). A merged PR is indistinguishable from an open or closed-unmerged one in its output — state alone cannot distinguish closed-unmerged from merged on Gitea.

Impact

Any consumer following the wrappers-first mandate (Constitution gate 7) that audits or reacts to merge state is structurally blind to merges. Concretely observed: a merge-monitoring session using only pr-metadata.sh could not attribute or even detect a completed merge that the provider API reported fully (merged=true, merged_by.login, merge_commit_sha), and escalated it as an unexplained event. The gap turns an attribution question that the provider answers in one field into an incident.

Expected

Pass through the provider's merge fields in the normalized schema:

  • merged (bool)
  • mergedBy (login)
  • mergeCommitSha

Both Gitea (/repos/{owner}/{repo}/pulls/{n}: merged, merged_by, merge_commit_sha) and GitHub (merged, merged_by, merge_commit_sha) supply them on the same endpoint the script already calls — no extra request needed.

Workaround until fixed

Use pr-view.sh or the provider API directly for merge state; do not infer merge state from state=closed.

## Defect `packages/mosaic/framework/tools/git/pr-metadata.sh` normalizes PR data into a JSON schema that contains no merge-state fields at all: no `merged`, no `merged_by`, no `merge_commit_sha` (verified against `main`: zero occurrences of `merged` in the script). A merged PR is indistinguishable from an open or closed-unmerged one in its output — `state` alone cannot distinguish closed-unmerged from merged on Gitea. ## Impact Any consumer following the wrappers-first mandate (Constitution gate 7) that audits or reacts to merge state is structurally blind to merges. Concretely observed: a merge-monitoring session using only `pr-metadata.sh` could not attribute or even detect a completed merge that the provider API reported fully (`merged=true`, `merged_by.login`, `merge_commit_sha`), and escalated it as an unexplained event. The gap turns an attribution question that the provider answers in one field into an incident. ## Expected Pass through the provider's merge fields in the normalized schema: - `merged` (bool) - `mergedBy` (login) - `mergeCommitSha` Both Gitea (`/repos/{owner}/{repo}/pulls/{n}`: `merged`, `merged_by`, `merge_commit_sha`) and GitHub (`merged`, `merged_by`, `merge_commit_sha`) supply them on the same endpoint the script already calls — no extra request needed. ## Workaround until fixed Use `pr-view.sh` or the provider API directly for merge state; do not infer merge state from `state=closed`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-infra-01 (Mosaic fleet seat code-infra-01) fargo fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) pepper rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) sanity scooby (Scooby) scrappy shaggy tiny velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1221