Skip to content

fix(generator): parse pnpm 12 clap-style help - #4713

Merged
thomhurst merged 23 commits into
mainfrom
issue-4691-pnpm-clap-help
Sep 14, 2026
Merged

thomhurst merged 23 commits into
mainfrom
issue-4691-pnpm-clap-help

Conversation

@thomhurst

@thomhurst thomhurst commented Sep 6, 2026

Copy link
Copy Markdown
Owner

pnpm 12 uses clap-style help that the previous scraper missed, dropping options, possible values, required SBOM arguments, and audit/stage passthrough parameters. Shared helpers parse wrapped descriptions and metadata, retain bracketed prose, preserve distinct CLI enum values, and derive required options from usage.

The pnpm scraper preserves short-only switches and wrapped option-shaped prose in both clap layouts. Boolean flags and optional-value options do not emit unused enums. Optional values retain CliOptionValue for bare switches or explicit values. Whenever no enum is generated, descriptions retain possible values and their individual documentation, including one-value and more-than-twenty-value lists. Cargo adoption and broader enum-helper consolidation remain tracked in #4712.

The shared repeatability detector recognizes "Repeat or comma-separate for multiple", including wrapped wording. This fixes the documented --cpu options on pnpm create and dlx, which omit an ellipsis. Their generated collections repeat the switch. Ordinary comma-separated scalar descriptions and operational retries retain their existing behavior.

Authoritative pnpm 12.4.1 output is incorporated through #4954. It includes typed audit levels, required SbomFormat, audit/stage Params, ConfigureAwait(false) on all 103 service awaits, possible-value documentation, and the corrected Cpu collections. Current source and generated manifest independently match fingerprint a64e31201c7dc54dd2d30167e4060f2b00e65d6e1d51caccccb85b03f1c8df08; command coverage remains 103 commands.

Unrelated Linux validation failures exhausted five-second harness guards in the distributed missing-result and cancellation-observer tests. Both now use the existing 30-second test convention and pass test cancellation into their executors. The observer still retries its transient failure after one millisecond and requires exactly two attempts. The one-second ModuleResultTimeout, TimedOut status, canceled coordinator token, and scheduler completion assertions remain unchanged.

Validation:

  • Seven repeatability regressions fail before the detector fix. All 170 focused pnpm, repeatability-adapter, traversal, and Markdown documentation tests pass afterward; four generator-output cases also pass after simplification and formatting.
  • All 19 Node integration tests pass in [Automated] Update pnpm CLI Options #4954 CI, including pnpm create/dlx rendering as --cpu x64 --cpu arm64. The incorporated generator, Node source, and Node tests are identical to that validated generated head.
  • All 198 distributed tests pass locally after the harness fix. The Release test solution build passes with zero errors and 181 existing warnings; scoped formatting passes.
  • The generator Release build previously passed with zero warnings/errors. Scoped generator severity-info formatting, all 61 API baseline checks, generated freshness validation, and git diff checks pass.
  • Earlier complete generator runs passed 1,419 tests. Local Node and full-generator validation remain delegated to CI after their recorded 2,048 MB limits; no limits were raised or expensive checks retried.

Generation: https://github.com/thomhurst/ModularPipelines/actions/runs/34819042708. Node validation: https://github.com/thomhurst/ModularPipelines/actions/runs/34819430271/job/103898241687. A fresh review/CI cycle is required after the test-only follow-up.

Closes #4691

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 6, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-14T09:20:39.632236Z 4551be2 New commits
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@coderabbitai

coderabbitai Bot commented Sep 6, 2026

Copy link
Copy Markdown

Review Change StackReview Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 3fcaadfc-9a49-49f6-b281-79c9fe582e17

📥 Commits

Reviewing files that changed from the base of the PR and between 4cd8c92 and 7fe35e2.

📒 Files selected for processing (2)
  • tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator.Tests/Scrapers/PnpmCliScraperTests.cs
  • tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Scrapers/Cli/CliScraperBase.cs

Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review.


📝 Walkthrough

Walkthrough

The change adds pnpm 12 clap-style help parsing, including enums, repeatable options, passthrough parameters, and usage validation. It updates pnpm fixtures, tests, generated documentation, public API references, rendering tests, and CLI-generation workflow branches.

Changes

pnpm Clap Help Support

Layer / File(s) Summary
Shared clap parsing primitives
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Scrapers/Cli/CliScraperBase.cs
The shared scraper parses clap summaries, option blocks, metadata trailers, possible values, repeatable values, and usage-required options.
pnpm 12 scraper integration
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Scrapers/Cli/PnpmCliScraper.cs
PnpmCliScraper reads Commands: sections, classifies clap option values, generates enums, maps variadic parameters to passthrough arguments, and excludes folded child command signatures.
pnpm fixtures and scraper validation
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator.Tests/Fixtures/Pnpm/*, tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator.Tests/Scrapers/*
New pnpm help fixtures and tests validate descriptions, option arity, repeatability, possible-value enums, command extraction, positional parameters, and complete install help parsing.
Generated enum documentation and compilation
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Generators/*, tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator.Tests/Generators/MarkdownDocumentationGeneratorTests.cs
Generated enum detection is shared by options and documentation generators. The pnpm audit example uses PnpmAuditAuditLevel.High, and compilation stubs emit the generated enum namespace.
Generated pnpm surface and rendering
docs/docs/mp-packages/cli/pnpm.md, src/ModularPipelines.Node/PublicAPI.Shipped.txt, test/ModularPipelines.Node.UnitTests/Api/PnpmCommandRenderingTests.cs, .github/workflows/generate-cli-options.yml
Generated command documentation, public API references, rendering tests, asynchronous service calls, and Linux and Windows generated-branch handling reflect the updated pnpm command model.

Priority: ➖ Normal

Estimated code review effort: 4 (Complex) | ~60 minutes

Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant PnpmHelp
  participant PnpmCliScraper
  participant CliScraperBase
  participant GeneratedOptions
  PnpmHelp->>PnpmCliScraper: Provide pnpm 12 clap help
  PnpmCliScraper->>CliScraperBase: Parse usage and option blocks
  CliScraperBase->>GeneratedOptions: Create typed options and enums
  GeneratedOptions->>GeneratedOptions: Validate operands and render pnpm commands
Loading

Merge Risk: ⚪ Minimal · up to 7fe35

The updated pnpm help parsing and generated surface have targeted coverage for the documented clap-format behaviors. No actionable merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Out of Scope Changes check ⚠️ Warning The pull request includes changes unrelated to issue #4691. The service template adds ConfigureAwait(false) to generated wrappers. The generation workflow changes generated-branch naming and pull-re… Remove the unrelated ConfigureAwait(false) template changes and tests, and remove the unrelated generated-branch workflow changes. Alternatively, link coding requirements that cover these changes.
Docstring Coverage ⚠️ Warning Docstring coverage is 35.19% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 54 functions across 11 files. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (3 passed)
Check name Status Explanation
Linked Issues check ✅ Passed The pull request meets the coding requirements in issue #4691. PnpmCliScraper now parses pnpm 12.4.1 clap-style help, ignores [OPTIONS] as a positional operand, maps [PARAMS]... to positional ar…
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: updating the generator to parse pnpm 12 clap-style help output.
Full details: Out of Scope Changes check

Explanation

The pull request includes changes unrelated to issue #4691. The service template adds ConfigureAwait(false) to generated wrappers. The generation workflow changes generated-branch naming and pull-request lookup for feature branches. These changes do not implement pnpm clap parsing, pnpm metadata, positional operands, enum generation, or the audit documentation example.

  • Fix all pre-merge checks with AI
✨ Finishing Touches 💡 1
📝 Generate docstrings 💡
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch issue-4691-pnpm-clap-help

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

A rabbit parsed the clap-filled scroll,
Enum carrots grew in a typed meadow,
Passthrough paths hopped through the fields,
Tests guarded each option and trailer,
Documentation followed the trail,
And branch names kept their burrows tidy.

Comment @coderabbitai help to get the list of available commands.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b855f637d9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

await Assert.That(commands.Select(command => command.FullCommand))
.IsEquivalentTo(["pnpm stage", "pnpm stage download", "pnpm stage publish"]);

P2 Badge Remove the parent command placeholder from leaf definitions

With this new clap-style stageHelp, ExtractSubcommands(commandPath, ...) returns no children for the repeated leaf help, so traversal does not call RemoveCommandGroupPlaceholders; NormalizeParentGroupUsage only clears operands for the exact pnpm stage path. Consequently both asserted leaf definitions retain a required Command positional from pnpm stage [OPTIONS] <COMMAND>, producing APIs that require callers to supply the subcommand again and can render commands such as pnpm stage download download. Extend the assertion to cover positionals and normalize repeated parent usage before parsing leaf definitions.

AGENTS.md reference: AGENTS.md:L170-L172

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@github-actions

github-actions Bot commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-help scraper rewrite

Reviewed the diff for PR #4713 (e6deb222) against the stated goal: fix the pnpm scraper for pnpm 12's clap-based --help output, which broke the scheduled options-generation run.

What I checked

  • CliScraperBase.cs: the new shared helpers (ExtractSummaryAboveUsage, ReadClapOptionBlock, SplitPossibleValuesTrailer, TryCreateOptionEnum). Traced the column-tracking state machine in ReadClapOptionBlock (blank-line handling, trailer wrapping via pendingTrailer, the Possible values: list vs. inline [possible values: ...] trailer paths) against the new fixture/unit tests — the indentation/column bookkeeping is consistent and each branch has a corresponding test (aligned layout, block layout, wrapped trailer, Possible values: list with per-value docs, and the -h/--help block-consumption case that prevents a wrapped mention of a switch from being misread as a declaration).
  • PnpmCliScraper.cs: the new regex (PnpmOptionPattern) and ParseOptions correctly distinguish flags from value options via the placeholder rather than name heuristics, handle <X>... (multi-value) and --color[=<COLOR>] (optional, =-attached) shapes, and consume each row's block before the seen/duplicate/--help filtering so skipped rows can't leave orphaned prose for the next declaration to misparse.
  • TryCreateOptionEnum/enum wiring: generic enough to also replace the AWS/Cobra-specific enum factories as described, with sensible bounds (2–20 members) and dedup by member name. GeneratorUtils.UsesGeneratedEnums is a clean, shared extraction used identically by OptionsClassGenerator and the new MarkdownDocumentationGenerator using emission, and DocumentationExampleCatalog/MarkdownDocumentationGeneratorTests were updated consistently for the new PnpmAuditAuditLevel enum.
  • ApplyUsageRequiredOptions (used from the shared base) correctly marks --sbom-format as required since it sits outside [OPTIONS] in the usage synopsis — this addresses the original scheduled-run failure directly.
  • Test coverage is substantial: a full fixture-driven test parses all 70 real options from pnpm install --help (pnpm 12.3.4) and asserts against enums, multi-value options, short forms, and stripped [alias: ...] trailers, in addition to the targeted unit tests. The traversal tests were updated to reflect pnpm 12's Commands:/clap layout instead of the old pnpm 10/11 heuristics they replace.

I did not find correctness issues in the scraper/generator logic that's actually part of this diff (confirmed via gh pr diff --name-only — 10 files, all reviewed). No prior substantive review comments are outstanding to address (Codex's automated review completed with no findings; CodeRabbit hit its OSS rate limit and produced no content to reconcile against).

Nit (non-blocking): ReadClapOptionBlock continues absorbing a line purely by column position, without the looksLikeOptionRow check that AccumulateWrappedDescription uses. That's correct for clap's consistently-aligned output (and the -h, --help test specifically proves it's the right call), but it's a subtle asymmetry between the two block readers in the same base class — a one-line comment noting why the clap reader doesn't need that guard would help future maintainers who skim past the existing docs on the method.

No blocking findings.

@thomhurst

Copy link
Copy Markdown
Owner Author

Pushed review fixes at 5af327c after a clean rebase onto current main.

  • Enum collisions: distinct CLI values now survive to EnumGenerator; the regression verifies their generated EnumValue attributes and disambiguated member name.
  • Repeated-parent usage finding: I could not reproduce the claimed extra Command operand. The current shared parser requires the requested leaf path to match the synopsis. Added assertions to the existing traversal test proving all three definitions have empty PositionalArguments and UsagePositionalArguments; the test passed before any production change for this finding.
  • CodeFactor: extracted trailer parsing and pnpm option construction from the two flagged methods. Added the requested comment explaining why clap indentation is sufficient even when prose starts with a switch.
  • Current pnpm 12.4.1 help exposed prose-declared repeatable options and space-separated optional values. Added red/green regressions and support for both.

Full generator suite: 1,359 passed. Release solution build: zero warnings/errors. Scoped formatting and diff checks passed.

Local regeneration exceeded the repository's 2,048 MB guard (2,550 MB observed); no local retry or limit increase. Tool-only CI regeneration is running with automatic merging disabled: https://github.com/thomhurst/ModularPipelines/actions/runs/34765043823. Its generated changes and validation must be reconciled before merging this PR.

@greptile-apps

greptile-apps Bot commented Sep 13, 2026

Copy link
Copy Markdown

Greptile Summary

This PR updates pnpm option generation for pnpm 12’s clap-style help format.

  • Adds shared parsing for multiline descriptions, possible-value metadata, required options, and generated enums.
  • Preserves pnpm variadic parent parameters and handles repeatable and optional values.
  • Updates generated documentation examples and introduces extensive pnpm fixtures and regression coverage.
  • The generated pnpm models have not yet been refreshed, leaving the newly added rendering tests uncompilable.

Confidence Score: 4/5

The PR is not ready to merge because the new Node rendering tests reference generated Params properties that are absent at the reviewed head.

The parser changes expect pnpm audit and stage generation to produce parent Params operands, but the corresponding generated models have not been committed, so the changed test project cannot compile.

Files Needing Attention: test/ModularPipelines.Node.UnitTests/Api/PnpmCommandRenderingTests.cs and the generated pnpm option files under src/ModularPipelines.Node/Options/

Important Files Changed

Filename Overview
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Scrapers/Cli/PnpmCliScraper.cs Reworks pnpm parsing around clap-style command, option, metadata, and variadic-parameter output.
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Scrapers/Cli/CliScraperBase.cs Adds shared clap block, possible-value, enum, and required-option parsing helpers.
tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator.Tests/Scrapers/PnpmCliScraperTests.cs Adds comprehensive regression coverage for pnpm 12 help parsing and generated metadata.
test/ModularPipelines.Node.UnitTests/Api/PnpmCommandRenderingTests.cs Tests parent variadic parameters that are absent from the currently checked-in generated pnpm classes.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[pnpm 12 help text] --> B[Usage and clap option parsing]
    B --> C[CLI command definition]
    C --> D[Options and enum generation]
    D --> E[Generated pnpm option classes]
    E --> F[Command-line rendering tests]
Loading

Reviews (3): Last reviewed commit: "test(node): render current pnpm parent p..." | Re-trigger Greptile

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5af327cfc2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@thomhurst
thomhurst deployed to Pull Requests September 13, 2026 15:22 — with GitHub Actions Active
@thomhurst

Copy link
Copy Markdown
Owner Author

The first tool-only generation run stopped safely at command coverage validation: pnpm 12.4.1 produced 103 commands versus the old 17-command baseline, but its help no longer lists audit signatures or the six stage children. The uploaded raw help shows parent [PARAMS]... syntax instead.

Fixed the related parameter omission in 0098d3d and recorded explicit coverage reasons for those seven paths. All seven child --help invocations return the parent's synopsis in the current executable. Parent commands remain required coverage sentinels; blanket shrinkage approval remains disabled.

Validation: both new recorded-help cases reproduced the bug before the fix; all 1,361 generator tests now pass. Release build has zero warnings/errors. Scoped formatting and diff checks pass. Fixture blank lines have trailing whitespace removed.

Regeneration for the corrected head is running at https://github.com/thomhurst/ModularPipelines/actions/runs/34766164896, with auto-merge disabled. Its generated changes and integration validation must be reconciled before merging this PR.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0098d3d698

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@thomhurst

Copy link
Copy Markdown
Owner Author

Generation run 34766164896 passed scraping and command coverage: 335 files generated, 103 commands, zero generator errors. It then stopped at the Node integration build because PnpmCommandRenderingTests referenced the removed PnpmStagePublishOptions.

Commit 6fd7a87 updates rendering tests to the current PnpmStageOptions/PnpmAuditOptions Params API. Formatting and diff checks pass. These tests require the pending generated output, so their compilation and execution remain deferred until that output is incorporated; the parent branch is not ready to merge yet.

Corrected generation run: https://github.com/thomhurst/ModularPipelines/actions/runs/34766806886. Auto-merge and blanket coverage approval remain disabled. Once CI publishes its generated commit, I will bring those changes into this PR and run the Node tests and documentation checks.

@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-help scraper rewrite (update)

A prior review of this PR at commit e6deb222 came back clear. Since then, new commits (through current head 6fd7a87) reworked the pnpm scraper/generator to emit a Params passthrough property and a PnpmAuditAuditLevel enum, and updated the generator own tests/doc catalog to match, but the actual generated API under src/ModularPipelines.Node/Options/ was never regenerated. This breaks the build.

Blocking findings

1. test/ModularPipelines.Node.UnitTests/Api/PnpmCommandRenderingTests.cs references properties that do not exist on the generated types

var commandLine = builder.Build(new PnpmStageOptions
{
    Params = ["publish", "package.tgz"],   // no Params member
    ...
});

I read src/ModularPipelines.Node/Options/PnpmStageOptions.Generated.cs and PnpmAuditOptions.Generated.cs directly at the PR head commit: neither has a Params property, and PnpmAuditOptions.AuditLevel is still string?. ModularPipelines.Node.UnitTests.csproj references src/ModularPipelines.Node/ModularPipelines.Node.csproj directly (not a package), so this test file fails to compile, which breaks the whole ModularPipelines.Node.UnitTests project.

2. DocumentationExampleCatalog.cs documents a type that does not exist yet

Around line 158 it emits a sample using PnpmAuditAuditLevel.High for the AuditLevel example, but no PnpmAuditAuditLevel enum exists in the generated output; AuditLevel is still a plain string?. Running the doc generator now produces a non-compiling code sample for users.

3. Stale generated artifacts contradict the new CommandCoverage.Exclusions

PnpmCliScraper.CreateToolDefinition() now excludes pnpm stage publish, pnpm stage download, pnpm stage list, pnpm stage reject, pnpm stage view, and pnpm audit signatures as distinct commands, folding them into the parent Params operand instead. But PnpmStagePublishOptions.Generated.cs, PnpmStageDownloadOptions.Generated.cs, PnpmAuditSignaturesOptions.Generated.cs, etc. are all still present and unremoved, so the shipped API and the new scraper policy are inconsistent with each other.

Why this matters and the suggested fix: per this repo own constraint, generated options must never be hand-edited or left stale; the scraper/generator change and its regenerated output are supposed to land together, with current tool output authoritative. The fix here is not to hand-patch the generated files (that would violate the same rule from the other direction); it is to actually run the generator against the new PnpmCliScraper logic and commit its output as part of this PR, so the generated Options classes, Pnpm.CommandCoverage.json, and the removed stale files all move in lockstep with the scraper/test/doc changes. Right now the PR is split across generator-input changes and generator-output-expectation changes without the regeneration step connecting them, which is what is breaking the build.

I did not find issues in the actual clap-parsing logic itself (CliScraperBase.cs, PnpmCliScraper.cs regex/option-block handling); that part looks sound and well tested by the generator own unit tests. The problem is specifically the missing regeneration of the downstream consumer package.

@greptile-apps

greptile-apps Bot commented Sep 13, 2026

Copy link
Copy Markdown

Too many files changed for review (357 files, 100 file limit).

Bypass the limit by tagging @greptile-apps to review.

@thomhurst

Copy link
Copy Markdown
Owner Author

Incorporated the Linux-generated commit from #4861 and rebased onto current main. Required SBOM options, enums, and audit/stage Params are now committed in this PR. Current head: 3996816.

The generated review correctly flagged bare awaits. Added the shared ConfigureAwait(false) template fix and four generator regressions; all 1,365 generator tests pass. Final generation from that template is running at https://github.com/thomhurst/ModularPipelines/actions/runs/34767616658 and will update #4861 for incorporation here.

Linux generation already built the Node solution. The local Node build hit the 2,048 MB guard at 2,140 MB, so Node build/test execution is deferred to CI without retrying locally. Documentation validation is still running. This PR remains unready to merge until the remaining generated update and validations complete.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

return await _command.ExecuteCommandLineToolAsync(options, executionOptions, cancellationToken);

P2 Badge Regenerate wrappers after changing await emission

At this head, GeneratorUtils now emits .ConfigureAwait(false), but all 103 awaits committed in Pnpm.Generated.cs still omit it, including this new SbomAsync wrapper. Consequently the shipped library does not receive the fix and can capture a caller's synchronization context, potentially deadlocking callers that synchronously wait for these methods; regenerate and commit the pnpm artifacts after the generator change.

AGENTS.md reference: AGENTS.md:L33-L35

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@thomhurst

Copy link
Copy Markdown
Owner Author

Documentation validation completed successfully: Node 24.14.1, yarn install --frozen-lockfile, and yarn build (302.92 seconds). All 331 documents were processed. The generated pnpm documentation is included in this result.

The final await-template generation run 34767616658 is queued. Node build/test execution remains deferred to CI after the local memory guard; no local retry will be made.

@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-help scraper rewrite (update at 3996816)

Picking up from the prior blocking review at 6fd7a87: that one flagged the missing Params/PnpmAuditAuditLevel regeneration. Since then the generated commit from #4861 was incorporated and rebased onto main, and the audit/stage Params API and SBOM enum are now present in the committed generated output — that issue looks resolved.

The parser/generator logic itself (CliScraperBase.cs, PnpmCliScraper.cs) continues to look sound: the clap option-block state machine, possible-values trailer handling, and enum extraction are well covered by the new fixture and unit tests.

Remaining findings:

1. Generated Pnpm.Generated.cs/IPnpm.Generated.cs are stale relative to the generator shipped in this same commit (blocking, self-disclosed as in-progress)

GeneratorUtils.cs (lines 868, 872) now appends .ConfigureAwait(false) to return await _command.ExecuteCommandLineToolAsync(...) in the service template, and ServiceAwaitGenerationTests.cs asserts it. But at the current head, src/ModularPipelines.Node/Services/Pnpm.Generated.cs has zero ConfigureAwait occurrences — every one of the 100+ generated methods still does a bare await. Re-running the generator against this same commit would produce a diff, which fails the repo's --verify-no-changes regeneration check and leaves the shipped Pnpm service capturing SynchronizationContext unnecessarily, exactly what the template change was meant to fix.

Per the PR's own latest update, the final regeneration run for this template fix (https://github.com/thomhurst/ModularPipelines/actions/runs/34767616658) is still queued/running, so this is a known, called-out gap rather than an oversight — flagging it here since it's a real inconsistency in the code as currently committed, and per CLAUDE.md the committed generated files should never be hand-patched to paper over it; only the pending regeneration should close it.

2. TryReadClapTrailer silently drops non-"possible values" bracketed description text (non-blocking, but a real gap in shared parsing logic)

In ReadClapOptionBlock (CliScraperBase.cs), any block line whose trimmed text starts with [ is routed into TryReadClapTrailer (line ~1414) instead of prose. That method buffers it in pendingTrailer:

  • If the line doesn't end in ], it returns true without ever adding the buffered text to prose, and nothing later flushes a leftover pendingTrailer — it's silently dropped on block exit (~line 1447).
  • If it does close with ], the accumulated text is only kept when it matches ^\[(?<name>[a-z ]+):\s*(?<value>.*)\]$ and names "possible values" (line 1469-1472); any other bracketed aside (e.g. [EXPERIMENTAL], [BETA]) is matched, discarded, and never reaches prose.

This is shared logic in CliScraperBase, so any current or future clap-based scraper (pnpm or otherwise) whose option description begins with a bracketed aside that isn't a possible-values trailer would have that description text vanish from the generated XML doc comments with no test or build failure to catch it. Doesn't block this PR's pnpm-specific goal since no current fixture hits this path, but worth a follow-up: either flush unmatched pendingTrailer content back into prose when it isn't a recognized trailer, or restrict the [-routing check to text that actually matches a known trailer shape before diverting it away from prose.

@thomhurst

Copy link
Copy Markdown
Owner Author

Final Linux generation is incorporated in 13dbeb1. All 103 wrappers now use ConfigureAwait(false), and Assert-GeneratedOptionsFreshness passes against HEAD. The final CI generation built the Node solution with zero errors. No Markdown or public API changed in this final generation, so the prior successful documentation build still covers the generated docs. Local Node validation is still deferred after the previously recorded 2 GB guard; no expensive local retry was run. Node test execution and current-head CI/review remain required before merge. The generated child #4861 is retained until its active review finishes, then can be closed as incorporated.

@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-help scraper rewrite (update at 13dbeb14)

Picking up from the prior blocking review at 3996816: that one flagged (1) stale Pnpm.Generated.cs/IPnpm.Generated.cs missing ConfigureAwait(false), and (2) TryReadClapTrailer silently dropping non-"possible values" bracketed text.

  • Finding (1) is resolved. All 103 generated methods in src/ModularPipelines.Node/Services/Pnpm.Generated.cs now use .ConfigureAwait(false), matching the GeneratorUtils.cs template change and the new ServiceAwaitGenerationTests.cs.
  • Finding (2) is still open (non-blocking, as previously noted): TryReadClapTrailer in CliScraperBase.cs still discards any [...] block line that isn't a [possible values: ...] trailer — no fallback flushes unmatched bracketed text (e.g. [EXPERIMENTAL]) back into prose. Worth a follow-up since it's shared scraper logic, but out of scope for this PR's stated goal.

New blocking finding — the generator source does not compile:

tools/ModularPipelines.OptionsGenerator/src/ModularPipelines.OptionsGenerator/Scrapers/Cli/CliScraperBase.cs:21 and :1034, and Generators/GeneratorUtils.cs:423, all initialize a HashSet<string> with a comparer using this pattern:

private readonly HashSet<string> _knownCommandGroups = [with(StringComparer.OrdinalIgnoreCase)];
private static readonly HashSet<string> DefaultSkipSubcommands =
[
    with(StringComparer.OrdinalIgnoreCase),
    "help", "completion", "version", "__complete", "__completeNoDesc"
];

with(...) is not a function, local, or extension anywhere in the codebase, and C# collection expressions have no syntax for passing a constructor argument (comparer) alongside the element list — there's no proposed or shipped with(...) element form, even under <LangVersion>preview</LangVersion> on net10.0. As written this is a plain compile error (with isn't a resolvable name, and even if it were, a StringComparer isn't a valid string element for these HashSet<string> literals). This looks like an automated "modernize to collection expression" pass that mishandled the constructor-argument case — it should have left these three declarations as new(comparer) { ... } (which correctly encodes the comparer) or used .ToHashSet(comparer) instead of a bracketed literal.

This directly contradicts the PR's and the latest comment's claims of "Generator Release compilation has zero warnings/errors" and "1,365 passed" — none of the generator or scraper tests (including the well-constructed new pnpm clap-parsing tests in PnpmCliScraperTests.cs) could actually have run against this code, since the assembly containing CliScraperBase/GeneratorUtils fails to build. Given --verify-no-changes/CI gating on this project, this needs a real (re-)build verification before merge, not just a description update.

Suggested fix: revert these three declarations to constructor-based initialization, e.g.:

private readonly HashSet<string> _knownCommandGroups = new(StringComparer.OrdinalIgnoreCase);

and

private static readonly HashSet<string> DefaultSkipSubcommands = new(StringComparer.OrdinalIgnoreCase)
{
    "help", "completion", "version", "__complete", "__completeNoDesc"
};

then rebuild tools/ModularPipelines.OptionsGenerator/ModularPipelines.OptionsGenerator.slnx and rerun the generator suite to confirm a clean, verified build before claiming test/build results in future updates.

Everything else in this rewrite — the clap option-block state machine (ReadClapOptionBlock/TryReadClapTrailer/SplitPossibleValuesTrailer), ApplyUsageRequiredOptions, the pnpm scraper's move to a coverage-policy-driven exclusion list for audit signatures/stage *, the SBOM enum typing, and the regenerated docs/options/service files — looks sound and is backed by solid new fixture/unit test coverage. The only thing blocking is the compile error above.

thomhurst and others added 2 commits September 14, 2026 07:24
Co-authored-by: thomhurst <9139608+thomhurst@users.noreply.github.com>
@thomhurst

Copy link
Copy Markdown
Owner Author

Addressed finding 1 in review 5659826846 with c907087. GetOptionDescription now bases its fallback on whether an enum actually exists. One-value and 21-value lists retain their choices in aligned and block layouts, and individual value documentation survives the non-enum fallback. All five regressions failed before this fix.

Finding 2 does not reproduce with clap's block layout. ReadClapOptionBlock assigns descriptionColumn only after rejecting indentation <= switchColumn; the column cannot fall back to or below the switch column. Subsequent prose at that column remains inside the block even when '-x ...' or '--example ...' satisfies the declaration regex. Two new short-only block tests exercise both forms, preserve the complete description, and retain the following real short/long declarations. Both tests pass on the preceding implementation as well as the current head. A declaration-shaped line at the actual declaration column is a declaration under this layout; adding a regex-only boundary would misclassify legitimate wrapped prose. No boundary change is needed for the reported case.

All 130 focused generator tests pass. The Release generator solution build has zero warnings/errors, scoped severity-info formatting passes, and all 61 API baselines validate. #4949 incorporated the previous successful 103-command regeneration; the new source change is now being regenerated in https://github.com/thomhurst/ModularPipelines/actions/runs/34813687920. Current output, provenance, and subsequent CI/review remain merge gates.

@thomhurst
thomhurst deployed to Pull Requests September 14, 2026 06:33 — with GitHub Actions Active

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c907087459

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-help scraper (PR #4713)

I re-reviewed the full diff at head c907087 against the shared clap-parsing helpers (CliScraperBase.cs) and the pnpm scraper rewrite (PnpmCliScraper.cs), plus the generator/doc-template changes and the new fixture-driven test suite. This PR has already been through several rounds of automated and human review; I focused on (a) verifying the fixes claimed in the most recent round, and (b) an independent pass for anything new.

Finding 1 from the previous round (possible-values dropped for out-of-range enum candidates) is fixed and tested. CreateOption now passes enumDefinition is not null into GetOptionDescription (PnpmCliScraper.cs:341), so the fallback that re-appends [possible values: ...] is driven by whether an enum actually got created, not by whether the value is optional. TryCreateOptionEnum's 2–20 member gate (CliScraperBase.cs) can no longer silently swallow the choices for a 1-value or 21-value list. This is directly covered by the new Non_Enum_Clap_Values_Preserve_Choices_In_Descriptions test (1 and 21 values, both aligned and block layouts) and Non_Enum_Clap_Value_Preserves_Individual_Documentation.

Finding 2 (short-only switches widening what ReadClapOptionBlock might misclassify) checks out as a non-issue. ReadClapOptionBlock never re-applies PnpmOptionPattern to lines it consumes — it only compares indentation against switchColumn/descriptionColumn, and descriptionColumn is pinned to the first content line's indentation, which is required to be > switchColumn to enter the block at all. So a wrapped continuation line that happens to look like -x ... or --example ... but sits at the block's established description column stays prose; the outer loop only re-tests the broadened regex once indentation has genuinely dropped back to a sibling declaration's column. The new Short_Only_Clap_Block_Keeps_Option_Shaped_Wrapped_Prose test exercises exactly this scenario for both short- and long-form-looking continuations and passes.

Everything else I checked:

  • ApplyUsageRequiredOptions correctly promotes options like --sbom-format to required from the usage synopsis rather than prose-guessing, and the generated PnpmSbomOptions.Generated.cs reflects it as a non-nullable constructor parameter.
  • ChildCommandSynopsisPattern + the CliCommandCoveragePolicy exclusions on PnpmCliScraper correctly distinguish "this usage line is a literal child command" from "this is the parent's own passthrough [PARAMS]... operand" for audit/stage, and are backed by the shared, pre-existing CommandCoverageGuard infra rather than a one-off mechanism.
  • GeneratorUtils.UsesGeneratedEnums is a clean extraction reused by both OptionsClassGenerator and MarkdownDocumentationGenerator — no duplicated enum-namespace-detection logic.
  • The regenerated surface is consistent with the fix: previously only a handful of pnpm commands were discovered (root-help parsing relied on prose section headers pnpm 12 no longer prints); the Commands:-section-based ExtractSubcommands now finds the full command tree, which is why the diff adds ~100 new *Options/*.Generated.cs files and a full Enums/ directory that didn't exist before. docs/docs/mp-packages/cli/pnpm.md and the exclusions table are consistent with the generated output.
  • Test coverage is thorough and fixture-driven (full pnpm install --help, audit, and stage fixtures covering aligned vs. block clap layouts, repeatable-value prose, optional [=<X>]/[<X>] attachment, possible-value collisions, and the boolean-flag/enum interaction).

Pre-existing, already-tracked, non-blocking items (unchanged from earlier rounds, not something this PR needs to fix): the enum+optional-value combination still falls through to CliOptionValue? rather than the enum type in the (currently unreached) case where an optional-value option also has enumerable choices; and CargoCliScraper hasn't been migrated to reuse the new shared clap helpers despite its doc comment noting a similar format — tracked in #4712.

I was not able to independently execute dotnet build/test against the PR head in this sandbox (running code from pr-head/ is blocked here), so I relied on static review plus the extensive test/build validation already documented in the PR description and prior review rounds.

No new blocking findings.

Co-authored-by: thomhurst <9139608+thomhurst@users.noreply.github.com>
@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-style help parsing (#4713)

Reviewed at head d95b43e394801c0332c0d5bfe28b9cdef1a9f44f. Per commit history, the only change since the last automated CLEAR review (at c907087459304dc4d57745588e8b9da78da6b3be) is d95b43e3 — "chore: Update pnpm CLI options (#4952)". This matches the repo's established authoritative-regeneration pattern (fix generator/scraper logic, then regenerate, per CLAUDE.md), consistent with the ~7 prior identical-pattern regeneration commits on this PR that earlier review rounds already verified as touching only src/ModularPipelines.Node/Options/** and docs. I could not fetch this commit's isolated diff directly (this sandbox's network access blocks git fetch/gh api compare against the remote), so I instead re-read the current pr-head checkout's generator/scraper source directly rather than relying on the diff.

Independent re-verification of the core logic (CliScraperBase.cs, PnpmCliScraper.cs, GeneratorUtils.cs, OptionsClassGenerator.cs, MarkdownDocumentationGenerator.cs):

  • GeneratorUtils.UsesGeneratedEnums(tool, command) is genuinely shared (not duplicated) between OptionsClassGenerator.GenerateUsings (called once per command) and the newly-added MarkdownDocumentationGenerator.AppendExample (called exactly once per tool, for the single selected example command) — confirming the prior round's "clean extraction" assessment still holds. I checked whether the new doc call site meaningfully compounds the pre-existing tool.AllEnums O(n) recompute already paid per-command by OptionsClassGenerator; since AppendExample fires only once per tool (not once per command), it adds a single extra linear scan per tool, not a second O(n²) pass — not worth changing.
  • ReadClapOptionBlock's listingValues flag is only reset to false on a blank line (CliScraperBase.cs:1466), not after TryReadClapTrailer consumes a bracketed trailer mid-block. In principle, a [default: ...]/[aliases: ...] trailer sandwiched between Possible values: entries with no blank line would leave listingValues stuck true, so a following non-matching line would be misfolded into the previous enum value's description instead of treated as prose. I could not find a real clap layout (in this repo's fixtures or general clap conventions) that produces a trailer inside a possible-values list rather than after it with a blank-line separator — every existing case, including Clap_Possible_Values_List_Documents_Each_Enum_Member, puts [default: ...] after a blank line following the list. This looks like a latent edge case rather than a reachable bug against real CLI output, so I'm not flagging it as blocking, but it's worth a defensive one-line reset (listingValues = false after a consumed trailer) if the shared helper is later reused for a CLI whose --help interleaves trailers mid-list.

Everything else matches what the long review history on this PR already established as clean: shared clap-parsing state machine, possible-value enum extraction with the 2–20 member gate, ApplyUsageRequiredOptions, child-command coverage exclusions, and the extensive fixture-driven test suite (pnpm install/audit/stage, aligned vs. block layouts, wrapped documentation, optional/repeatable values). The ~345 regenerated files under src/ModularPipelines.Node/Options/**, Enums/**, and docs/docs/mp-packages/cli/pnpm.md are expected authoritative tool output per CLAUDE.md, not hand-edited.

I was not able to run dotnet build/test against pr-head in this sandbox, so as with prior rounds I relied on static review plus the extensive validation already documented in this PR's history (1,419+ generator tests, clean Release build, formatting checks).

No blocking findings.

@thomhurst
thomhurst deployed to Pull Requests September 14, 2026 07:01 — with GitHub Actions Active

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5c9b4220fe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/ModularPipelines.Node/Generated/Pnpm.Generation.json Outdated
Co-authored-by: thomhurst <9139608+thomhurst@users.noreply.github.com>
@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-style help parsing (#4713)

Reviewed at head 6f4f70bc856dd8b62741d088a4e33a3e82d76792. Per commit history, two commits landed since the last automated CLEAR review (at d95b43e394801c0332c0d5bfe28b9cdef1a9f44f):

  1. 5c9b4220fe — "fix(generator): recognize shortened repeatability wording (PnpmCliScraper cannot parse pnpm 12 clap-style help (sbom positional operands, audit AuditLevel) #4691)"
  2. 6f4f70bc85 — "chore: Update pnpm CLI options ([Automated] Update pnpm CLI Options #4954)" (regeneration, current head)

Reviewed the new logic change directly (not just trusted the description): RepeatableValueRegex in CliScraperBase.cs gained two new alternatives — repeat\s+to\s+add\s+more and repeat\s+or\s+comma-separate\s+for\s+multiple — to recognize pnpm 12's shortened repeatability phrasing ("Repeat to add more", "Repeat or comma-separate for multiple values") that the existing longer-form patterns ((?:can|may|must|should)\s+be\s+..., etc.) did not match. This is shared, generic logic in the base scraper (not a pnpm-specific patch), consistent with this repo's "fix the generic logic" constraint.

  • Confirmed the regex is well-guarded against false positives: RepeatableOptionAdapterTests.cs includes both the new positive cases ("Repeat or comma-separate for multiple", multi-line wrapped variant) and a negative case ("Repeat the operation for multiple retries." -> false) that specifically exercises the "repeat" + operational-count-phrase collision the OperationalCountPhrasePattern negative lookahead already guards against elsewhere in this regex.
  • Confirmed the regeneration is consistent with the fix: PnpmInstallOptions.Generated.cs now correctly types --filter, --workspace-packages, --cpu, --os, --libc, etc. as IEnumerable<string>? with the "Repeat to add more" / "Repeat or comma-separate for multiple values" prose retained in the XML doc comment (previously these likely fell back to string? since the old regex did not recognize this phrasing), and the same pattern is consistent across the other regenerated Pnpm*Options.Generated.cs files that use this wording.
  • PnpmCliScraperTests.cs's Prose_Can_Declare_Repeatable_Clap_Options test covers the same declaration/description pairs directly against the pnpm scraper, not just the shared regex in isolation.

I was not able to run dotnet build/test against pr-head in this sandbox (git/gh api commands into that checkout required approval that was not grantable here), so as with several prior rounds on this PR I relied on static review, but this increment is narrow (a two-alternative regex addition plus its matching regeneration), directly tested, and does not touch any of the previously-contested areas (secret masking, ConfigureAwait, enum gating, Params passthrough, coverage exclusions), all of which remain unchanged from the last CLEAR head.

No new or unresolved correctness issues found. Consistent with the prior CLEAR verdict.

@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-style help parsing (#4713)

Reviewed at head 7a5bc1eb04a8b19a89d78bc8f77ca29b7e7afdcc. Per commit history, the only change since the last automated CLEAR review (at 6f4f70bc856dd8b62741d088a4e33a3e82d76792) is 7a5bc1eb04 — "test: allow result-timeout cleanup under parallel CI load (#4691)", a test-only commit unrelated to the pnpm scraper logic.

Reviewed the change directly in test/ModularPipelines.Distributed.UnitTests/Master/DistributedModuleExecutorTests.cs, Missing_Result_Times_Out_And_Completes_Pipeline:

  • [Timeout(5_000)][Timeout(30_000)], matching the 30-second harness-guard convention already used by sibling tests in this file (e.g. Failed_Module_Cancels_Pipeline_For_Remaining_Modules and others use the same convention). The previous 5-second guard was tight for a test that itself waits out a 1-second ModuleResultTimeout plus scheduler/coordinator overhead under parallel CI load, so it's a reasonable, targeted fix rather than a blanket loosening.
  • The call now goes through the full ExecuteAsync(modules, estimatedDurations, context, cancellationToken) overload — executor.ExecuteAsync([module], new Dictionary<Type, TimeSpan>(), new ExecutionBackendContext(resultRegistry), testCancellation).WaitAsync(testCancellation) — instead of the 3-arg convenience overload wrapped only in .WaitAsync(testCancellation). I confirmed this overload and the ExecutionBackendContext(IModuleResultRegistry) constructor are the same ones already used by DistributedModuleExecutor.ExecuteAsync internally and by the identical pattern in ModuleExecutor.cs/WorkerModuleExecutor.cs, so this isn't introducing a new/parallel code path — it's propagating testCancellation directly into the executor's own token rather than relying solely on the external WaitAsync wrapper to abandon the call, which better reflects real cancellation semantics under test-harness timeout.
  • The other assertions (TimeoutException, ModuleStatus.TimedOut, ResultWaitTokens[...].IsCancellationRequested, MarkModuleCompleted verification) are unchanged from the previously-reviewed, passing version.

This PR has been through many review rounds (pnpm clap-parsing rewrite, shared CliScraperBase helpers, enum/possible-values handling, repeatability regex, ConfigureAwait template fix, and several regeneration cycles), all previously resolved to CLEAR as of 6f4f70bc85. This increment doesn't touch any of that surface — it's isolated to test harness timing/cancellation plumbing for an unrelated distributed-executor test.

No new or unresolved correctness issues found. Consistent with the prior CLEAR verdict.

@thomhurst

Copy link
Copy Markdown
Owner Author

Pushed 4551be2 for the latest Linux failure in run 34824200007, job 103913733448. The previous missing-result test passes; the only distributed failure is now Cancellation_Observer_Retries_After_Transient_Failure at its outer five-second guard (5.048 seconds; suite duration 20.595 seconds).

The observer test now uses the existing 30-second harness convention and passes test cancellation through the public execution-backend overload. This also lets a harness timeout cancel the worker's infinite dequeue mock and background tasks instead of only abandoning the outer wait. The one-millisecond retry interval, transient first failure, exactly two observer attempts, and empty result assertion remain unchanged. No production retry logic or deadlines changed, and no CI rerun was requested.

All 198 distributed tests pass locally (1.818 seconds). The Release Tests solution build passes with zero errors and 181 warnings; scoped formatting and diff checks pass. Current pnpm source/output freshness passes at the new head; generator and Node code are unchanged from the previously validated generation. Existing resource limits remain unchanged. The new CI/review cycle must pass before resolving remaining threads or merging.

@github-actions

Copy link
Copy Markdown
Contributor

Review: pnpm 12 clap-style help parsing (#4713)

Reviewed at head 4551be22d09709d5cfa07620e5276cb5dbe55c4f. Per commit history and the PR's own latest update, the only change since the last automated CLEAR review (at 6f4f70bc856dd8b62741d088a4e33a3e82d76792) is two test-only harness-timeout commits — 7a5bc1eb04 and this head, 4551be22d0 — neither touching scraper/generator logic.

Independently verified the new commit's diff directly (test/ModularPipelines.Distributed.UnitTests/Worker/WorkerModuleExecutorTests.cs, Cancellation_Observer_Retries_After_Transient_Failure):

  • [Timeout(5_000)][Timeout(30_000)], matching the convention already applied to Missing_Result_Times_Out_And_Completes_Pipeline in the sibling file and to other tests in this suite.
  • The call now goes through the full ExecuteAsync(modules, estimatedDurations, backendContext, cancellationToken) overload — executor.ExecuteAsync([], new Dictionary<Type, TimeSpan>(), new ExecutionBackendContext(resultRegistry), testCancellation).WaitAsync(testCancellation) — instead of the 3-arg convenience call wrapped only in .WaitAsync. This lets testCancellation reach the worker's mocked infinite dequeue loop directly rather than only abandoning the outer await, which is a real fix for the flake (a harness timeout can now actually stop the background work instead of leaving it running past the outer wait).
  • The retry setup, the transient-failure-then-success sequencing, and await Assert.That(attempts).IsEqualTo(2) / await Assert.That(result).IsEmpty() are unchanged — only the timeout and the call shape moved.

This is a narrow, well-targeted fix consistent with the same pattern already cleared for the missing-result test, and it matches what the PR description claims for this commit.

Core scraper/generator logic (CliScraperBase.cs's ReadClapOptionBlock/TryReadClapTrailer/SplitPossibleValuesTrailer/ApplyUsageRequiredOptions/TryCreateOptionEnum, PnpmCliScraper.cs's rewritten ParseOptions/CreateOption/ExtractSubcommands, and the shared GeneratorUtils.UsesGeneratedEnums extraction used by both OptionsClassGenerator and MarkdownDocumentationGenerator) is unchanged since the last CLEAR round and I re-traced it directly rather than taking that on faith: the column-tracking state machine in ReadClapOptionBlock, the required-vs-optional/multi-value regex in PnpmOptionPattern, the 2–20 member enum gate, and the pnpm stage/audit synopsis-collapsing all still read as internally consistent and are backed by the fixture-driven PnpmCliScraperTests.cs/CliScraperTraversalTests.cs suites. docs/docs/mp-packages/cli/pnpm.md matches the current generated command set (103 commands, the 7 stage/audit signatures exclusions with reasons, and the PnpmAuditAuditLevel.High example).

This PR has been through an unusually long and thorough review cycle (compile-error false alarm, a bracketed-trailer-dropping gap, a reintroduced secret-masking regression, staged regeneration of Params/ConfigureAwait(false)/enum types, a boolean-flag enum leak, possible-values-dropped-for-out-of-range-enums) — every one of those was independently re-verified as resolved in earlier rounds and nothing in this final commit reopens any of them. I have no new findings.

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.

PnpmCliScraper cannot parse pnpm 12 clap-style help (sbom positional operands, audit AuditLevel)

1 participant