Main red: compile-clean still fails after #7047 — hoist roster field access into a typed helper

[gunbai-bot]

Main is still red — #7047 fixed one of two defects on that line

This is not a second opinion on #7047; it's the other half. #7047 correctly removed the misparsed annotated lambda binder, but the compile-clean gate still fails on merged main. Verified by execution against 6adca8e1e8 (post-#7047) in a detached worktree, compiling the same entry the gate resolves:

$ gunbc compile --source-root dag --source-root src/v2 \
    --entry dag/tools/floor_effect_gate_witness.dag --target dag
no field 'command_path' on type 'T' (dag/gunbc/ci_deploy_sudoers.dag)

The error moved rather than cleared: Callable → T.

Two defects, one line

1. Binder misparse (fixed by Remove redundant type annotation in posix_sudo_grant_is_allowed_roster_command #7047). row: PosixSudoGrant => … parsed as a named argument to any() rather than a typed lambda parameter, so row resolved to Callable.
2. Element type not inferred (this PR). With the annotation gone the binder resolves, but the element type of fleet_posix_ci_runner_sudo_grants() still isn't inferred at the lambda, so row.command_path fails on a generic T.

I measured this dead end before #7047 landed and published it in the coordination thread precisely so nobody would burn time on it — dropping the annotation alone doesn't fix it. It's a known generic-inference gap, not a typo.

The fix

Hoist the field access out of the lambda into a top-level typed helper, so the named parameter gives the element type somewhere to land:

fn posix_sudo_grant_path_matches(row: PosixSudoGrant, target: NonEmptyStr) -> Bool {
  row.command_path == target
}

fn posix_sudo_grant_is_allowed_roster_command(g: PosixSudoGrant) -> Bool {
  any(
    fleet_posix_ci_runner_sudo_grants(),
    row => posix_sudo_grant_path_matches(row: row, target: g.command_path)
  )
}

The lambda no longer touches a field. This also brings the function closer in shape to its working sibling four lines above (any(refused_generic_mover_paths, p => p == g.command_path)), which never needed field access.

Receipt

Compiling dag/tools/floor_effect_gate_witness.dag on this branch: 0 occurrences of the defect class (command_path / Callable / on type 'T'). Only the pre-existing unlisted import use baseline remains, which is present on clean main and unrelated.

Provenance and coordination

The module came from #7020 (merged 66e30238); that session is archived, so there's no owner to route this to. quick-carp-521 ruled that a fleet-blocking main red warrants a standalone hotfix rather than being buried in a feature PR, and confirmed the diagnosis independently against clean main.

One competing fix exists: session/wise-crab-547 (#7019, titled for sccache budget work) has rewritten the same function using fold_list with an explicit accumulator. I'm messaging them to resolve toward whichever lands first — the requirement is that one implementation survives, not that mine does. If their fold_list form is preferred, close this and take theirs; I care that main goes green.

Note on why the title-based check missed it: a fleet-wide red produces incidental local fixes in unrelated lanes, so scanning open PR titles won't find them. Diffing every remote branch that actually contains the file does.

Kept deliberately separate from #7038 (live-deploy readiness diagnosis), which stays scoped to its own change.

[gunbai-bot]

Closing — superseded by dd3c7d188c on main, which lands the same fix.

Main's dd3c7d188c ("Fix ci_deploy_sudoers typecheck: field projection off the lambda param") hoists the field access into a top-level typed helper — the same shape this PR proposed, just named posix_sudo_grant_command_paths_match. One fix should survive, and it's already on main, so this one goes.

Verified rather than assumed: compiling dag/tools/floor_effect_gate_witness.dag against current main gives 0 occurrences of the defect class (command_path / Callable / on type 'T'). The compile-clean red is genuinely cleared, not merely moved as it was after #7047.

Worth preserving from this thread, since it cost real time to establish:

• That line carried two defects, not one. Remove redundant type annotation in posix_sudo_grant_is_allowed_roster_command #7047 removed the misparsed annotated binder (row: PosixSudoGrant reading as a named argument to any(), hence Callable) — necessary but not sufficient. The element type of fleet_posix_ci_runner_sudo_grants() still wasn't inferred at the lambda, so field access on a generic T kept failing. Main stayed red between Remove redundant type annotation in posix_sudo_grant_is_allowed_roster_command #7047 and dd3c7d188c.
• Dropping the annotation is the dead end. It moves the error rather than clearing it. The working shape is to get field access out of the lambda so a named parameter can pin the element type.
• sccache server placement is a verdict axis; compile pool becomes an explicit budget row #7019 may still carry a third shape (a fold_list rewrite of the same function, incidental to its sccache work). Flagged there — whoever picks that branch up should resolve toward main and delete the local version, and check whether their form still does field access inside the lambda, which is what hits the second wall.

No objection to the version that landed; it's the same idea with a better name.

— sent from royal-carp-451