Skip to content

chore(master): release 2.0.0 - #2

Closed
github-actions[bot] wants to merge 1 commit into
masterfrom
release-please--branches--master--components--slothlet
Closed

github-actions[bot] wants to merge 1 commit into
masterfrom
release-please--branches--master--components--slothlet

Conversation

@github-actions

Copy link
Copy Markdown

🤖 I have created a release beep boop

2.0.0 (2025-08-23)

⚠ BREAKING CHANGES

  • workflows: remove deprecated release.yml and add publish & release-please workflows

Miscellaneous Chores

  • workflows: remove deprecated release.yml and add publish & release-please workflows (05a581c)

This PR was generated with Release Please. See documentation.

@Shinrai Shinrai closed this Sep 2, 2025
@Shinrai
Shinrai deleted the release-please--branches--master--components--slothlet branch September 2, 2025 01:48
Shinrai added a commit that referenced this pull request Sep 13, 2026
…indings

Follow-up to the reactive self-heal redesign — the adversarial review of #362
surfaced further real, related defects in the same mechanism. Four fixes:

- Gate #reactivelyPatchStack on ____buildDepth === 0 (findings #3/#5/#7/#8). The
  reactive patch exists only for the quiet case (a late mutation with no build,
  hence no terminal rebuildStacks(), coming). Firing during a build/add/reload was
  redundant (a flood per leaf on initial load — perf), stored the write raw because
  UnifiedWrapper's setTrap only wraps+userAssigned-tags at buildDepth 0 (so it
  differed from a rebuildStacks()-installed stack and a later reload's child-adoption
  dropped it), could race the framework's own not-yet-landed assignment for a
  candidate the build might still reject, and during a reload could target the old
  tree. Checked at execution time so a build that started after the setImmediate was
  queued is caught.

- addModule()/addModules() now call rebuildStacks() after mounting (finding #1).
  These compose a component onto the live tree like api.slothlet.api.add() but never
  rebuilt stacks, so a routine matching a leaf of a module mounted this way never got
  its stacked callable — and the reactive patch can't cover it (it's a build, now
  gated; and a mount-relative name can't match until the endpoint registers during
  that same build). Both the single and multi mount paths get the call. Target is
  this.slothlet.api (the base tree addApiComponent mounts onto and boundApi forwards
  to), matching runModeRoutines.

- Post-await re-validation in #reactivelyPatchStack (findings #2/#4/#6). After the
  #resolveContainer await, re-check ____buildDepth (a build may have started),
  slothlet.api identity (a reload may have swapped the tree), and the target
  wrapper's ____slothletInternal.invalid flag (a concurrent removal may have
  invalidated it — a write would land via the set trap with no throw but read back
  undefined). Recompute the winner's contributor group from current raw and re-confirm
  the install threshold (TOCTOU) so a concurrent removal can't leave a zero/one-
  contributor no-op stack replacing a real function. The waiting-proxy write-absorption
  case has no clean public brand to detect, but only arises mid-build/removal, which
  these guards + the top-of-method gate cover; documented in-code rather than adding a
  fragile detector.

Tests: a new modules/routine-stack-on-mount suite pins that addModule()/addModules()
install the stack and it invokes the mounted contributor (fails without the mount-path
rebuildStacks); a new routines case pins the build-depth gate no-ops during a build and
heals once it clears. Findings #2/#6 (invalidated-wrapper / waiting-proxy) are internal
race states without a deterministic public-API trigger and are covered by the guards
rather than a flaky test.

Refs #362
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.

1 participant