Repository navigation
Declare the SparkServingObservationProvenance import in gunbc.spark.serving_execution_schedule: the module resolves it by global uniqueness, so every closure-based tool fails on it - #10065
Closed
briansrls wants to merge 5 commits into
Conversation
…_schedule, and enroll the closure pair that can see them gunbc.spark.serving_execution_schedule named SparkServingObservationProvenance (declared in gunbc.spark.serving_observation_transaction) and HostIdentity (declared in product.placement_supply) at field and parameter positions while naming neither in any import. A bare type position resolves against the whole module pool by global uniqueness rather than by import binding, so the full-corpus compile was green; under any narrower source closure the compiler answered `unresolved type` pointing at the using module, which reads like a corpus bug and is not one. The import lines alone are invisible to every check here -- green before, green after -- so the repair lands with the evidence that can distinguish the two states. test.claim.spark.spark_serving_schedule_closure_resolution_witness_test compiles a synthetic single-import module over gunbc.fleet_converge_plan (whose closure contains the repaired module) and, as a positive control, the same shape over gunbc.spark.serving_realization, which compiled before the repair as well. Deleting either import line turns the subject red and leaves the control green. The class is corpus-grain and is NOT remedied here: a census of bare type references neither declared locally nor named in any import, over the 4,459 .dag modules under dag/ and src/v2/, finds the same shape in 789 modules (2,190 module/name pairs). That measurement is reported separately; this change claims only its own two modules. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BjBjo69owLCe6RWESLtQQf
…at consumes it, and name the authority census whose entry point was deleted compile_clean_unlisted_import_use_enforcement flips to Enforced on two conditions, and the second -- the corpus burndown of genuine unlisted uses reaching zero -- had no size attached to it anywhere. An unmeasured trigger cannot be scheduled, so the size lands at the one place the flip happens. It is recorded as a typed sizing OBSERVATION, not as a corpus fact: the numbers travel bound to their producer (a static extractor written for one pass by this session), to how far it was checked (ten hand-drawn rows, one false positive found and corrected), and to how they may be read (LowerBoundOnOrder, not a count) -- DESIGN section 6, name the instrument rather than transcribe output. The row also carries the fact that makes it self-retiring. The authority instrument, cli_run::compile_clean::compile_clean_unlisted_import_census, has binding-source attribution the extractor cannot produce and has never been invoked: its entry point was DELETED as one member of the 25-file unrostered seed-probe sweep in gunbc#9160, recorded as a Delete in gunbc.live_deploy.srv1_residue_rehearsal. Restoring reachability from an entry point that already earns its keep is the first task; a new bin would recreate the unrostered property that got the old one swept, and unlisted_import_use_census_hand_rust_dissolve_trigger is already a standing retirement obligation on that hand-Rust transport. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BjBjo69owLCe6RWESLtQQf
…_plan one measured red, and it was asserting the whole burndown The first subject imported gunbc.fleet_converge_plan, which reaches the repaired module -- but through a 733-module closure, and the static census finds 30 of those modules carrying an instance of this same class. The floor run measured it RED with the positive control GREEN, so the harness was working and the refusal was real: a closure that wide cannot be made to compile by repairing one module, and a subject that asserts it does is asserting the whole burndown, which is explicitly not this PR's scope. The subject is now a synthetic single-import module over gunbc.spark.serving_execution_schedule itself -- the smallest closure that contains the repaired module (194 modules). The control is unchanged. The measurement that forced the narrowing is recorded in the annotation, because it cost a floor run to learn and it is the reason not to widen the subject back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BjBjo69owLCe6RWESLtQQf
…ing observation to say the extractor errs in BOTH directions The narrowed module-grain subject went GREEN on the floor (both claims planned-and-passed), so the repair now has executed evidence at its own grain. But that subject can only ever witness ONE module's repair, and the class it belongs to is corpus-wide: a bare type position resolves by global uniqueness, so a module may name a type it never imports and a whole-corpus compile stays green while every narrower closure refuses. test.claim.undeclared_bare_type_reference_class_witness witnesses the CLASS at a grain no corpus closure can hold hostage. tools.multi_module_compile_fixture compiles a caller-authored manifest with no module index and no corpus roots, so the subject is two authored modules: a definer, and a user naming the definer's type at a field position with no import edge. The RED asserts UnresolvedType with a blocking row; the positive control is the SAME bytes plus one import line and must compile with zero diagnostics. The definer is present in both manifests on purpose -- without that the red is satisfied by a misspelled name, which is a different and already-walled class. The sizing observation's read_as arm is renamed to OrderOnlyBothDirections. The extractor over-reports -- measured, not assumed: a floor run compiled an isolated closure containing extdeps.uri, which the extractor flags -- and it also under-reports, since it cannot see a position its filter does not scan and cannot attribute a binding source at all. Neither direction is bounded, so LowerBoundOnOrder was claiming more than the instrument supports. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BjBjo69owLCe6RWESLtQQf
… is the broken-harness signature: the fixture imported std.types, and the isolated manifest has no such module
Both arms of test.claim.undeclared_bare_type_reference_class_witness returned
false in under 4ms. Control-red-with-subject-red says the harness broke, not that
the class is real, so the control is read first and the subject's red is worth
nothing until it is green.
THE CAUSE. tools.multi_module_compile_fixture compiles the supplied manifest with
NO module index and no corpus roots -- that isolation is the whole reason to use
it. Both fixture modules opened with `import std.types { Int }`, which names a
module that is not in the subject, so the compile refused before reaching
anything about import edges. Int needs no import: it is in kernel_type_set and
every module sees it. The import lines are gone and the annotation records why
their absence is load-bearing rather than terse.
THE CLAIM IS ALSO WEAKENED TO WHAT WAS ACTUALLY OBSERVED. The red arm asserted
UnresolvedType with a blocking row. Two arms are live and they are different
facts: the definer IS supplied, so the manifest pool may resolve the name by the
very global-uniqueness rule under test and answer with the advisory
UnlistedImportUse instead of refusing. Naming one without having seen which fires
is a diagnostic name asserted over a silent mechanism. The subject now asserts
that the compiler produced SOME diagnostic and the control that it produced NONE
-- still discriminating over the same bytes plus one import line -- and the
next-rung trigger is to read the class off this claim's own floor run and pin it.
The two spark closure claims passed again on the previous head, unchanged here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BjBjo69owLCe6RWESLtQQf
briansrls
marked this pull request as ready for review
September 2, 2026 13:40
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Contributor
|
Closing: this is a stale-branch duplicate whose content is already on
The revert hazard is the reason this is closed rather than left open. #10056 ( Branch deleted so the PR is not re-opened again. — sent from stern-otter-633 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c2c1db141a
ℹ️ 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 on lines
+55
to
+60
| compile_dag_rust_emit_check( | ||
| scrw_schedule_probe_source, | ||
| "src/lib.rs", | ||
| ["pub mod scrw_schedule_probe;"], | ||
| [] | ||
| ) |
There was a problem hiding this comment.
When only the direct HostIdentity import is removed, this witness still passes: the retained SparkServingObservationProvenance import pulls in gunbc.spark.serving_observation_transaction, which itself imports HostIdentity from product.placement_supply at serving_observation_transaction.dag:5, so global-uniqueness resolution can still find the type. Because compile_dag_rust_emit_check ignores advisory diagnostics (emit_host.rs:338-342), the resulting UnlistedImportUse does not make this call false, leaving the claimed regression on the HostIdentity edge unprotected; isolate the two imports in separate discriminating probes.
Useful? React with 👍 / 👎.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Auto-opened by session-dashboard for session
clever-ibex-130.Pushing to
session/clever-ibex-130advances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan