Seen on 0.9.2 running ecr review --pr <n> --stack-aware locally against expo/universe (stacked PRs 29434-29439).
The verify pass (and sometimes reviewers) read the local checkout instead of the materialized PR head tree. Concrete cases:
On universe#29437 the verifier dropped two findings with "No env.production.yaml exists, only env.staging.yaml" and "mise.toml has no deploy:production task, line 41 hardcodes --vpc-connector=pipeline-staging". The PR adds exactly those files and changes that line. It was describing main, not the PR head.
On universe#29434 the verifier dropped a finding saying "production main.tf lines 32-36 list only 10.8.0.0/16, 172.22.0.0/18, 172.22.64.0/20, the 10.10.0.0/28 entry exists only in staging". The diff adds 10.10.0.0/28 to the production file.
On universe#29436 (stacked on 29434) the security agent reported the secret production__cf_logs_kafka as "only declared for staging" even though the head branch includes the 29434 commit that adds it to production.
In these runs the dropped findings happened to be wrong anyway, but a verifier reading the wrong tree will eventually drop a true finding for a false reason, and it already produced one artifact warning (the 29436 secret one). No "falling back to your checked-out files" warning was printed, so the fallback was either silent or the verify pass never got the pinned tree in the first place.
Seen on 0.9.2 running
ecr review --pr <n> --stack-awarelocally against expo/universe (stacked PRs 29434-29439).The verify pass (and sometimes reviewers) read the local checkout instead of the materialized PR head tree. Concrete cases:
On universe#29437 the verifier dropped two findings with "No env.production.yaml exists, only env.staging.yaml" and "mise.toml has no deploy:production task, line 41 hardcodes --vpc-connector=pipeline-staging". The PR adds exactly those files and changes that line. It was describing main, not the PR head.
On universe#29434 the verifier dropped a finding saying "production main.tf lines 32-36 list only 10.8.0.0/16, 172.22.0.0/18, 172.22.64.0/20, the 10.10.0.0/28 entry exists only in staging". The diff adds 10.10.0.0/28 to the production file.
On universe#29436 (stacked on 29434) the security agent reported the secret production__cf_logs_kafka as "only declared for staging" even though the head branch includes the 29434 commit that adds it to production.
In these runs the dropped findings happened to be wrong anyway, but a verifier reading the wrong tree will eventually drop a true finding for a false reason, and it already produced one artifact warning (the 29436 secret one). No "falling back to your checked-out files" warning was printed, so the fallback was either silent or the verify pass never got the pinned tree in the first place.