Submission requirements
Problem summary
The v0.43.0 PR execution-context resolver can report a successful but incorrect base SHA for a shallow synthetic PR merge checkout. When HEAD has two parents, it runs git merge-base HEAD^1 HEAD^2; if that fails because the checkout lacks sufficient ancestry, it silently uses HEAD^1 as the base and writes successful aw-context/pr/base.sha and head.sha files.
That fallback can make a review agent inspect only the delta from the current target tip rather than the PR's true merge-base. The failure is silent: downstream instructions receive apparently valid 40-character SHAs rather than an error signal.
This is related to the broader PR-context work tracked in #860, but it is a correctness bug in the existing built-in context implementation rather than only a request for richer precomputed diff artifacts.
Reproduction details
Use ado-aw v0.43.0 with PR execution context and a shallow checkout that contains the synthetic merge commit and both immediate parents but not enough history to find their common ancestor.
The current implementation in scripts/ado-script/src/shared/merge-base.ts follows this path:
const p1 = gitOk(["rev-parse", "HEAD^1"]);
const p2 = gitOk(["rev-parse", "HEAD^2"]);
const mergeBase = gitOk(["merge-base", p1, p2]) ?? "";
baseSha = mergeBase.length > 0 ? mergeBase : p1;
Because p1 and p2 are valid full SHAs, the later format validation passes and the resolver returns success with baseSha = p1.
A production PR-review workflow had to add a source-level prepare step that fetches both target and source history at progressively larger depths, reruns git merge-base, overwrites the generated context SHAs only after resolving the true ancestor, and fails if no merge-base can be found. The workaround uses targeted depths rather than fetching all history.
PR #1425 / issue #1413, included in v0.43.0, adds progressive target-branch deepening for create-pull-request diff-base discovery. It does not change the synthetic-merge fallback above, which remains present on current origin/main.
Expected behavior: built-in PR context either resolves the true merge-base after targeted progressive deepening or reports a failure.
Observed behavior: it silently substitutes the target parent and reports success.
Proposed next step
Remove the successful HEAD^1 fallback. If merge-base HEAD^1 HEAD^2 fails, progressively deepen the required target and source refs using authenticated targeted fetches, then retry. If the true merge-base still cannot be resolved, write the existing failure context instead of staging a plausible but incorrect base SHA. Add a regression test where both parents resolve but their common ancestry is initially absent.
Submission requirements
.github/agents/ado-aw.agent.md.githubnext/ado-aw.Problem summary
The v0.43.0 PR execution-context resolver can report a successful but incorrect base SHA for a shallow synthetic PR merge checkout. When
HEADhas two parents, it runsgit merge-base HEAD^1 HEAD^2; if that fails because the checkout lacks sufficient ancestry, it silently usesHEAD^1as the base and writes successfulaw-context/pr/base.shaandhead.shafiles.That fallback can make a review agent inspect only the delta from the current target tip rather than the PR's true merge-base. The failure is silent: downstream instructions receive apparently valid 40-character SHAs rather than an error signal.
This is related to the broader PR-context work tracked in #860, but it is a correctness bug in the existing built-in context implementation rather than only a request for richer precomputed diff artifacts.
Reproduction details
Use ado-aw v0.43.0 with PR execution context and a shallow checkout that contains the synthetic merge commit and both immediate parents but not enough history to find their common ancestor.
The current implementation in
scripts/ado-script/src/shared/merge-base.tsfollows this path:Because
p1andp2are valid full SHAs, the later format validation passes and the resolver returns success withbaseSha = p1.A production PR-review workflow had to add a source-level prepare step that fetches both target and source history at progressively larger depths, reruns
git merge-base, overwrites the generated context SHAs only after resolving the true ancestor, and fails if no merge-base can be found. The workaround uses targeted depths rather than fetching all history.PR #1425 / issue #1413, included in v0.43.0, adds progressive target-branch deepening for create-pull-request diff-base discovery. It does not change the synthetic-merge fallback above, which remains present on current
origin/main.Expected behavior: built-in PR context either resolves the true merge-base after targeted progressive deepening or reports a failure.
Observed behavior: it silently substitutes the target parent and reports success.
Proposed next step
Remove the successful
HEAD^1fallback. Ifmerge-base HEAD^1 HEAD^2fails, progressively deepen the required target and source refs using authenticated targeted fetches, then retry. If the true merge-base still cannot be resolved, write the existing failure context instead of staging a plausible but incorrect base SHA. Add a regression test where both parents resolve but their common ancestry is initially absent.