Skip to content

fix(ttsc): fence source-plugin lock generations#460

Merged
samchon merged 5 commits into
masterfrom
fix/source-plugin-lock-generation
Jul 13, 2026
Merged

fix(ttsc): fence source-plugin lock generations#460
samchon merged 5 commits into
masterfrom
fix/source-plugin-lock-generation

Conversation

@samchon

@samchon samchon commented Jul 13, 2026

Copy link
Copy Markdown
Owner

Intent

Prevent stale source-plugin lock observers, delayed holder finalizers, and legacy pathname cleanup from deleting a successor generation.

Scope

  • keep legacy <key>.lock separate from persistent v2 ownership at <key>.lock.v2
  • atomically publish the complete v2 coordination root and each non-empty current generation
  • retire releases and abandoned generations to deterministic non-empty tombstones
  • revalidate legacy fences before retiring the legacy path
  • report abandonment only after successful fenced retirement
  • preserve every lock artifact during opportunistic cache GC
  • add barrier-driven multi-process regressions for stale v2 observers, old v2 finalizers, and a stale legacy observer acting on a held v2 successor
  • document the generation-fencing and legacy-migration protocol

Verification

  • three exhaustive full-change reviews completed after the final structural fix
  • pnpm --filter ttsc build
  • 18 targeted source-plugin lock, handoff, timeout, legacy, GC, and real CLI E2E tests
  • real concurrent cold-cache two-process corpus test

Closes #452

samchon added 5 commits July 14, 2026 05:23
Replace path deletion with generation-fenced directory retirement. A non-empty current generation is acquired by atomic rename, and every release or reclaim leaves a deterministic non-empty tombstone that rejects delayed finalizers and stale observers.

Constraint: Ownership fencing must work across processes and supported platforms without read-compare-delete.

Rejected: Recursive lock-path deletion | a stale observer can delete a successor generation.

Confidence: high

Scope-risk: moderate

Directive: Keep retired generation directories non-empty; they are the atomic fencing record.

Tested: Diff integrity only before the requested post-PR review sequence.

Not-tested: Targeted lock tests pending three exhaustive reviews.

Related: #452
Publish each legacy fence as a complete non-empty directory through atomic rename. A process killed while preparing its unique candidate can leave only an ignorable candidate, never a truncated canonical fence.

Constraint: Legacy observation must retain the original directory age while adding a shared generation.

Rejected: Exclusive direct file write | a crash can leave a partial canonical record.

Confidence: high

Scope-risk: narrow

Directive: Publish canonical ownership metadata only after its candidate is complete.

Tested: Review round 1 and diff integrity; runtime tests remain deferred until round 3.

Not-tested: Local build and targeted tests pending.

Related: #452
Prepare legacy fence candidates beside the observed lock so contender setup cannot advance the lock directory mtime. The winning canonical fence therefore retains the pre-observation age even when multiple processes race.

Constraint: Stale legacy classification must remain deterministic without timing hooks or process-local coordination.

Rejected: Candidate directories inside the legacy lock | their creation mutates the age being measured.

Confidence: high

Scope-risk: narrow

Directive: Do not create pre-publication artifacts inside an unfenced legacy lock.

Tested: Exhaustive review round 2 and diff integrity; v2 timeout assertions added.

Not-tested: Runtime tests remain deferred until review round 3.

Related: #452
Stage the two observer processes so the first successor remains current at a build barrier while the second acts with its stale fence. This removes scheduler luck from the core survival assertion and proves only one successor publishes.

Constraint: Multi-process regression tests must use explicit filesystem barriers, not timing assumptions or monkeypatches.

Rejected: Releasing both stale observers together | a vulnerable implementation can pass under a favorable schedule.

Confidence: high

Scope-risk: narrow

Directive: Keep observer B blocked until observer A's successor lease is externally visible.

Tested: Exhaustive review round 3 and diff integrity.

Not-tested: Runtime tests pending the required clean review round.

Related: #452
Legacy holders delete the entire historical lock path, so v2 generations now live in an orthogonal persistent coordination directory. Protocol initialization is atomically published, legacy reclaim revalidates its fence, and abandonment is reported only after successful retirement.

Constraint: Legacy holders remove the whole .lock directory by pathname

Rejected: Reuse .lock for v2 ownership | no cross-platform conditional rename can close the legacy release/reclaim TOCTOU

Confidence: high

Scope-risk: moderate

Directive: Keep legacy .lock and v2 .lock.v2 ownership namespaces disjoint

Tested: pnpm --filter ttsc build; 18 targeted source-plugin lock, handoff, GC, and CLI E2E tests

Not-tested: Full repository test suite

Related: #452
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.

fix(ttsc): fence source-plugin lock generations during reclamation

1 participant