Repository navigation
Bound sink execution per instance and preserve recovery evidence - #2548
Conversation
Sink #2226 independent review, round 2Verdict: accepted at a71830a. F1-F3 are fixed and independently verified. No new finding. Independent shipping risk: low. This is scoped candidate acceptance and risk evidence, not publication or landing authorization. Reviewer Verification used clean detached The valid incremental scope is all eight changed files from a7eadd6: runtime, driver, diagnostic history, driver state types, their three regression suites and CONFIGURATION prose (196 additions, 15 deletions). I inspected their surrounding lifecycle/status/selection interactions and the final explanatory wording. Round 1 whole-candidate inspection and its unaffected proofs carry forward. LLP 0471 instance ownership, manual work, daemon work and diagnostic history, LLP 0453 warning rules, and the prior LLP 0472 plan govern these fixes. The new conservative selector resolves the existing warning-preservation constraint; the documentation describes that behavior without changing accepted design intent. Numbered finding ledger
No finding is silently dropped, deferred or rejected. Original steward supplied committed fixes; the reviewer made none. Independent execution
The actual CLI pipe and owned PTY await both destinations, display three acknowledged rows per destination and preserve explicit partial truth/exit 0. Same-process contention maintains peak one under 5,000 fires and gives truthful refusal/stop receipts. A running disposable daemon continues local exports, sweeps, source probes and heartbeat during a real loopback central stall, writes no unacknowledged central cursor, and aborts the transport before a held source shutdown is released. Restart preserves warning until full recovery. After 131 observed real fixture failures, 100 diagnostic records remain while cache payload, cursor, other destination, unknown-file and telemetry sentinels remain intact. Shared auth cancellation preserves live consumers and prevents cancelled identity publication. The full suite independently executes the new richer regressions plus actual loopback header/body/upload/auth/retry cancellation, controlled elapsed deadlines, stable retry IDs/bytes, mid-partition watermark failure, privacy/hold and cleanup containment contracts, reference and hygiene gates. Round 1's three hermetic smokes and central retainer proof remain valid evidence for unchanged paths, clearly identified as prior-head checks. Read GUARDIAN-ACCEPTANCE-FINAL.md and the owner correction checkpoint; guardian independently accepted all six final-SHA journeys. Their claims are supplemental to the execution above. CPU and memoryNo additional CPU or memory concern requiring repair found in the changed and affected paths. Boot adds one streaming metadata pass per live sink, with a maximum 4 KiB read per recognized file and one numeric boundary per instance. It adds startup I/O proportional to old directory size, without retaining inventories or introducing a per-tick/per-completion rescan. Large legacy histories can therefore delay boot; no universal startup latency bound is claimed. The requesting-driver slot stores one reusable function, not a function or Promise per timer fire. Shared state, manual receipts, stop/drain and replacement ownership remain finite. History selection holds 100 scalar records, transiently 101; the added actionable lookup is bounded by that cap. My repeated-failure probe used 5,000 old records, 1,000 preserved unknown entries and 500 subsequent failures: exactly two directory passes, 5,500 metadata reads of at most 4,096 bytes, about 779 ms initial work and 189 ms subsequent work. Subsequent live heap samples were about 4.5-4.7 MB under a 32 MiB V8 limit. RSS was higher, around 90 MB; V8 heap limit is not a process-memory limit. This is synthetic local filesystem evidence. Central Error/upload-buffer lifetime code is unchanged by this delta. The round 1 18-iteration WeakRef/small-heap proof remains applicable, with zero failed Errors/buffers alive during the next partition wait; native transport settlement is separately executed above. Initial boot/status/cleanup remain O(directory size), discovery scales with current partitions, filesystem refusal can exceed the on-disk cap, and disabled maintenance adds no retry timer. Separate CLI processes do not share the gate. An uncooperative generic plugin can retain its one operation and keep shutdown pending. No hidden new uptime-growing collection or busy loop was found. Historical failures and limitsPreserve No installed service, production Cloud receiver, owner enrollment or real user data was exercised. CLI row fixtures are synthetic. The 330-second native deadline is tested with controlled time, not a wall-clock soak. No GitHub CI, current remote target, branch-policy eligibility or landing was verified by this local review. Independent shipping assessmentLow risk at this exact head against the named target. Affected users are daemon/manual sink users, especially installations with slow central transport, multiple destinations or old failure history. Potential unintended impact would be missed export scheduling, misleading recovery, cancelled shared credentials, premature cursor progress or overbroad diagnostic cleanup. The executed specific safety proofs above demonstrate finite scheduling with fresh requesting ownership, preserved live auth consumers, no cursor for the stalled unacknowledged upload, preserved cache/cursor/privacy contracts and cleanup confined to recognized diagnostic evidence while retaining actionable warnings. Behavioral changes are limited to execution ownership, cancellation, completion diagnostics and bounded history; there is no configuration/schema migration, enrollment or public plugin contract change. Reverting product code restores prior scheduling/diagnostic behavior without migrating user state. Pruned old diagnostic records cannot be restored by rollback: this is an intentional accepted history bound, not reversible evidence deletion. The actionable-warning and sentinel/containment proofs are therefore essential to the low unintended-impact assessment; a green suite alone would not suffice. Export payload and retry progress are outside that deletion policy and remain independently protected. Acceptance is now supported with every finding closed by verified fix. The responsible owner retains publication, current-head CI/policy/delegation checks and any landing decision. This report grants none of those authorities. Return evidence to the live existing parent and preserve the review checkouts/ref until released under FLOW. Default two-round budget is exhausted; any new repair requiring another round must return to owner triage. |
|
The first GitHub CI run failed on Node24 in A controlled30ms delay on the second first-sync filesystem read reproduces the same assertion at this exact head. The isolated natural run passes. A test-only correction03996bf5adf6b9222d7471295afee448caf3b610 uses a bounded monotonic five-second deadline and five-millisecond yield, retaining every scheduling assertion. Its controlled probe,12 scheduling tests, typecheck and committed full suite pass (7829passed,4skipped,0failed). Production files are unchanged. That correction awaits serial integration and an explicitly authorized incremental independent review. This PR remains a draft at the original accepted head until new-head review and CI gates pass. The original failed run remains evidence; there is no merge-queue request. |
Sink #2226 independent review, round 3Accepted at Reviewer: Owner transition 2601 expressly grants one extra incremental round beyond two, for this demonstrated CI synchronization defect; steward acknowledgment 2603 is retained in review-r3-parent-transitions.json. This is round 3 of the authorized total 3, not a reviewer extension. Started 2026-10-08T00:09:44.228Z; checkpoint 2026-10-08T01:09:44.228Z. Completed before checkpoint. Scope and exactnessUsed a new clean detached Verified prior reviewed head and target ancestry, integration tree equality with correction Inspected every helper use and its surrounding assertions: 22 synchronous predicates checking call counts or discovery admission, across shared gates, coalescing, sequential manual destinations, hold/cron rechecks, drain, discovery stop, registry replacement and requesting-driver ownership. They do not return Promises or block synchronously. The longer wait permits asynchronous filesystem preflight to settle; it does not relax expected counts, peak concurrency, progress ownership, stop behavior, fresh discovery or zero-Promise firestorm assertions. Remaining immediate turns still serve the original specific observation points. LLP 0471 instance-ownership/manual-work and prior LLP coverage remain applicable; no design change or new LLP is needed. Findings carried forward
The CI-reported helper synchronization defect is corrected and independently reproduced before/after. No additional finding, deferral or unresolved blocker was found in this delta. No historical finding is dropped. Executed checksCommands below ran in clean final head unless explicitly marked prior head.
For the last proof, The injected delay affects only the second No broad repeat was warranted for a byte-verified test-only delta. The author's committed full suite (7,829 pass/four skip), prior independent full suite and six running journeys are historical evidence, not newly executed final-head tests. Owner integration and author correction logs remain separately attributable. Original source-refresh timing failure and controlled base/candidate reproduction, and the earlier comparator gate failure, remain distinct historical records in review-round-1/2. CPU, memory and shipping riskNo new CPU or memory concern. The test helper has one deadline, one predicate and at most one pending timer per invocation. It yields between polls and retains no growing collection or detached timeout. The failure probe used about 58 ms total CPU over five seconds. The monotonic deadline avoids wall-clock adjustment; as with any timer, a frozen event loop can delay the assertion, so this is not a process-wide hard timeout. All actual predicates are cheap and synchronous. Production CPU/memory behavior is byte-identical to the explicit round 2 assessment. Low shipping risk at this exact final head and target. The delta changes only test synchronization and can be reverted by reverting one test helper; it changes no user behavior, persisted state, access, credentials, payload handling or export progress. Its focused executable safety proof is the same delayed-I/O scenario failing before/passing after while semantic assertions remain identical, plus verified finite failure behavior and all scheduling checks. For the complete candidate, the affected sink users and unintended-impact analysis from round 2 remain applicable by identical product bytes. Its independently executed six disposable CLI/PTY/daemon/loopback journeys prove stalled transport leaves cache/cursors intact, unrelated work proceeds, live auth consumers survive cancellation, cleanup preserves unrelated sentinels and actionable warnings, and recovery is truthful. These are reused historical proofs at a718, not new executions at 5765858. Intentional old diagnostic pruning remains irreversible; the warning/payload/cursor containment proofs remain essential to low unintended-impact risk. Product rollback still requires no schema/config migration. Read GITHUB.md shipping policy and retained previous assessment. Local acceptance does not establish fresh GitHub matrix success, installed-service health, production receiver behavior or landing eligibility. The assignment reports PR2548 draft with old a718 CI failure; no fresh external read or public mutation was performed here. The responsible owner must push/verify the exact candidate under its authority and satisfy current CI, delegation, policy and queue requirements before any landing. This report grants no publication or landing authority. Return to the existing live steward-owned parent, verified blocked on this review child. Preserve all review worktrees and evidence. The one extra round is now consumed; further repair/review requires owner triage. |
Slow or stalled exports currently admit overlapping work and can delay independent destinations and daemon bookkeeping. This repair gives each sink instance one active run and one coalesced follow-up, keeps sequential manual sync truthful, and cancels central transport across its complete 330-second chunk deadline.
Successful full completion records recovery time, including recovery after restart. Diagnostic history is capped at 100 recognized records per instance while protecting the newly published record and latest actionable failure. Cleanup preserves cache payloads, cursors, unknown files, symlinks and other destinations. No configuration or schema migration is required.
Fixes #2226
Change-Set: sink-instance-bound-2226
Final accepted head: 5765858 against master 9e53cf4. Round 3 independently accepted the test-only CI wait correction with 27 focused tests, typecheck, failing-before/passing-after filesystem-delay proof and a finite failure-bound proof. Product bytes match the round-2 accepted head; the following product checks remain attributable to that prior head:
The historical source-details boot-snapshot timing failure remains recorded and reproduced on the unchanged base; this repair does not change that test boundary. Installed services and production Cloud behavior were not exercised. The deadline proof uses controlled time. Separate CLI processes do not share execution state, and an uncooperative third-party plugin can keep shutdown pending. PR #1034 destination-history work remains deferred and outside this repair.
The first GitHub CI run exposed a new test helper that counted immediate turns before asynchronous filesystem preflight settled. The test-only correction preserves every scheduling assertion and waits with a bounded elapsed deadline. Original failed CI remains visible; fresh final-head CI is required before readiness or landing.