Skip to content

feat(amazonq): apply merged unit tests under the loaded repo's beam card - #2966

Draft
cslong wants to merge 2 commits into
mainfrom
dev/longachr/ut-beam-apply-merged-tests
Draft

cslong wants to merge 2 commits into
mainfrom
dev/longachr/ut-beam-apply-merged-tests

Conversation

@cslong

@cslong cslong commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

Problem

On a Beam to IDE job, getTransformationPlan skips the completed-step apply pass, because the beamed source is already transformed. Unit tests generated after Local Build Verification on a beam are new on top of that source, so their Merge Tests diff is never applied to the local solution.

Solution

In the beam branch of getTransformationPlan, apply finished "Merge Tests" steps at or below the loaded repo's steps (beamScopeStepIds, which the IDE already sends), in plan order, once each:

  • Only nodes in scope and their descendants are searched, so a step added under the repo's beam card after it was loaded is still found, and another repo's tests are never applied.
  • Uses the existing download-and-apply path, so the local-edit protection and checkpoints-applied.json bookkeeping apply; already-applied steps are skipped, so it's safe on every poll.
  • A step that fails to apply marks the diff context failed, like the other apply paths.
  • Nothing is applied without a scope or a solution path (the beamed-repos listing passes neither).
  • Only Merge Tests steps under a beam card (named <repo> (beamed) by the web orchestrator) are applied. Unit test steps sit under the card where the run was started: a web transform's own run is under the repo's transform card, and its tests are already in the beamed zip, so it is never applied again even if the scope covers that card. Each run started from the IDE adds its own Merge Tests step and is applied once.
  • The general completed-step pass stays skipped on beam.

No behaviour change until a beam plan contains a Merge Tests step.

Testing: new unit tests in atxTransformHandler.test.ts ("getTransformationPlan on a beam: merged unit tests"): only the loaded repo's finished step is applied; nothing without a scope or solution path; already-applied and unfinished steps are skipped; a failure is reported; a plan with no unit test step does nothing; the web transform's Merge Tests is skipped when the scope includes its card; two runs on the beam card are applied once each, in plan order. npx ts-mocha on the netTransform tests: 496 passing; atxTransformHandler.test.ts with the beam-card guard: 329 passing; no new eslint or tsc errors; prettier clean.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@codecov-commenter

codecov-commenter commented Oct 22, 2026 •

Copy link
Copy Markdown

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 91.50943% with 9 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
...anguage-server/netTransform/atxTransformHandler.ts 91.50% 7 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

On a beam, getTransformationPlan skips the completed-step apply because the
beamed source is already transformed. Unit tests generated after Local Build
Verification are new on top of it, so finished Merge Tests steps under the
loaded repo's steps (beamScopeStepIds) are now downloaded and applied, once each.
Nothing changes until a beam card has a Merge Tests step.
…m card

Unit test steps sit under the card where the run was started. A web transform's own
run is under the repo's transform card and its tests are already in the beamed zip,
so applying its Merge Tests diff again would duplicate them if the IDE's scope covers
that card. Only Merge Tests steps under a beam card ("<repo> (beamed)") are applied;
each run started from the IDE is applied once, in plan order.
@cslong
cslong force-pushed the dev/longachr/ut-beam-apply-merged-tests branch from 25ec32a to 79d2d70 Compare October 27, 2026 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants