🐛🧑‍💻 - Bugbot recommends an undeclared setup dart input despite the versioned upstream contract #739

Is there an existing issue for this?

• I have searched the existing issues.

Searches for enable-problem-matcher and for external Action input contracts in this repository returned no matching issue. This is distinct from the earlier optional-check diagnostic report #728 and inherited-binary progress report #727.

Which actions are affected?

Pull Request

Which platforms are affected?

Linux

Description

Bugbot confidently recommends replacing a declared and implemented external Action input with an undeclared input. Applying the suggestion would restore the exact pre-publication failure that this release fixes.

Consumer vypdev/zstandard PR176, frozen head d80fb5335d9de5fd2cbc7e2007954f0b9a1075a5, tree 36ccfe6582bbd6eb4b619bb9bae02d8789cb67e8, contains the publication-only correction:

- uses: dart-lang/setup-dart@v1
  with:
    sdk: ${{ inputs.dart-version }}
    problem-matcher: false

Bugbot posted review comment4384754781 at2026-10-27T03:17:06Z, medium severity, correctness category, 94% confidence, with the title "Use the setup-dart matcher input name". It asserts that v1 uses enable-problem-matcher, calls the supplied input unrecognized, claims the regression fixture repeats that wrong contract and proposes:

enable-problem-matcher: false

The primary upstream evidence contradicts that claim. Fresh reads at approximately03:30UTC resolve dart-lang/setup-dart tagv1 to 6afc89df92d6eb3834022f73cd65adc8cdfcb92d:

• Action manifest lines20–23 declares problem-matcher, defaulttrue. Declared inputs are exactly sdk, architecture, flavor, problem-matcher; enable-problem-matcher is absent. Manifest blob eadbfde8d51d64b3d3060258f76b5929753752d0.
• Implementation lines144–151 explicitly reads core.getInput('problem-matcher') and suppresses the matcher when its value is false. Implementation blob 80399c93965c53f61f9d90ec04e0de2afe7c8fc3.
• Compiled official module, Git blob 3018b0fccaff4d0238255b881c1c33bc0ee6f3e8, SHA256 4dc97bdd14690566ba9525f970335aab478772a551b68ebc90c685e6c0b2c3ee was executed in three isolated local cases. This independently checks the real upstream module rather than just repeating the consumer fixture's expected key.

Observed isolated results:

The unknown suggested key is never read. Its default-enabled matcher resolves against the inherited parent composite action path, reproducing a missing dart-analyzer.json command. Real GitHub Actions reports this as a step failure before package upload; the preceding consumer publication job demonstrates that failure shape. We did not apply the bad suggestion or attempt another publication to demonstrate it.

The official module smoke tests use a fake cached SDK/version file, a parent composite directory without a matcher asset, stubbed Action exec/tool-cache and OIDC APIs, and the real upstream compiled SDK logic. No network, real credential request, package upload or native build occurs. Node24.20.0 on macOS arm64 is the local smoke host; this is not a claim of real registry authentication. The consumer's 50 preparation-contract tests, including the five publication cases, separately pass on Linux in run40443071171, job121987746279.

Reproducing the issue

1. Open the consumer PR/head above, with a local composite invoking dart-lang/setup-dart@v1 and problem-matcher: false. The changed regression fixture supplies that same input intentionally, matching the actual upstream manifest.
2. Run the normal installed PR Bugbot workflow. Run40443071419 / job121987747845, runner ubuntu-runner-2, completes successfully and posts the false finding.
3. Finding identity: publish-package:22:matcher-input-name; fingerprint fp-a7a42af8; semantic key sf-b12ab0fb; review5661824639; thread PRRT_kwDONFe3186wiTKa; changed line22 of .github/actions/publish-package/action.yml.
4. Compare the versioned upstream manifest/implementation linked above. The finding's Evidence paragraph repeats the incorrect input-name assertion without an upstream reference.
5. To reproduce the suggested regression without publishing: download the exact compiled module above and verify its hash; create a temporary cached SDK containing version3.13.2; inject the normal SDK JS-interop globals with stubbed SDK cache/exec/OIDC and a core.getInput implementation using the real manifest defaults. Set a temporary GITHUB_ACTION_PATH whose parent composite lacks the matcher asset. Run each input case in a fresh Node process. Both cases still request the fixture token and register its environment-variable reference; only the supported key disables the failing matcher command.

Expected: external Action API claims should be grounded in the exact referenced version's manifest or implementation. A correct declared input should not receive a high-confidence correctness finding or a suggestion to use an undeclared key. When the external contract cannot be verified, the finding should express that limitation or abstain. A regression fixture for this case should retain the declared problem-matcher contract and reject the proposed alias.

copilot Version

vypdev/copilot@v3, resolved by this PR job to 39679e26a22b40a5a4a40e8f167f46273157182e (3.10.5). Existing configuration reports agent-model: gpt-6-luna, findings-model: gpt-6-luna, bugbot-effort: smart. No model, policy or permission settings were changed for this report.

Relevant Log Output

2026-10-27T03:16:30.0903121Z Download action repository 'vypdev/copilot@v3' (SHA:39679e26a22b40a5a4a40e8f167f46273157182e)
2026-10-27T03:16:33.9438129Z bugbot-effort: smart
2026-10-27T03:16:33.9445882Z agent-model: gpt-6-luna
2026-10-27T03:16:33.9446969Z findings-model: gpt-6-luna

Additional context and comments

We preserve Copilot engine/generated workflows, installed profile, credentials, approval policy and version-tag Action references. The frozen release source remains unchanged; the false-positive thread will be answered with primary evidence and resolved through normal human review. Please handle any engine/prompt/evidence-quality correction upstream.

We have not established whether the false assertion comes from stale model knowledge, external-source access limitations or another internal cause. The separate review-state cancellation (submitted event followed three seconds later by edited) was correctly superseded by a successful workflow under configured cancel-in-progress concurrency; it is not being reported as an engine failure.