Skip to content

feat(mcpkit): runtime group lock/unlock — App.Lock/Unlock (MC-45) - #28

Merged
jgangemi merged 1 commit into
mainfrom
jae/mc45-lock-unlock
Jul 12, 2026
Merged

jgangemi merged 1 commit into
mainfrom
jae/mc45-lock-unlock

Conversation

@jgangemi

Copy link
Copy Markdown
Member
  • add registry.locked (runtime, per-group soft lock, distinct from the
    permanent startup gate) plus the shared shouldRegister predicate
    (!gateBlocked && !locked) finalize/lockGroup/unlockGroup all consult
  • App.Lock removes a group's currently-registered tools from the live
    server (firing notifications/tools/list_changed) and blocks the group's
    pending tools from future (re)registration
  • App.Unlock re-registers a locked group's pending tools, but only those
    shouldRegister still allows — a startup-gate-hard-blocked tool (e.g. a
    Write tool under ReadOnlyMode) is never resurrected
  • finalize no longer clears pending, and MC-43/44 never did either — Lock
    before start now simply makes finalize skip the group, keeping its
    closures around for a later Unlock
  • Lock/Unlock on a startup-gate-hard-blocked group return an error; the
    hard block always wins and can't be runtime-toggled
  • both are idempotent and callable before or after Run/Connect/HTTPHandler,
    which is what lets a consumer start a group locked and unlock it
    mid-session (the lazy tier)
  • all mutated state (locked, byGroup, pending, started, gate) stays under
    reg.mu, mirroring finalize's existing lock ordering

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

- add registry.locked (runtime, per-group soft lock, distinct from the
  permanent startup gate) plus the shared shouldRegister predicate
  (!gateBlocked && !locked) finalize/lockGroup/unlockGroup all consult
- App.Lock removes a group's currently-registered tools from the live
  server (firing notifications/tools/list_changed) and blocks the group's
  pending tools from future (re)registration
- App.Unlock re-registers a locked group's pending tools, but only those
  shouldRegister still allows — a startup-gate-hard-blocked tool (e.g. a
  Write tool under ReadOnlyMode) is never resurrected
- finalize no longer clears pending, and MC-43/44 never did either — Lock
  before start now simply makes finalize skip the group, keeping its
  closures around for a later Unlock
- Lock/Unlock on a startup-gate-hard-blocked group return an error; the
  hard block always wins and can't be runtime-toggled
- both are idempotent and callable before or after Run/Connect/HTTPHandler,
  which is what lets a consumer start a group locked and unlock it
  mid-session (the lazy tier)
- all mutated state (locked, byGroup, pending, started, gate) stays under
  reg.mu, mirroring finalize's existing lock ordering

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jgangemi
jgangemi enabled auto-merge (squash) July 12, 2026 20:17
@coveralls

Copy link
Copy Markdown

Coverage Report for CI Build 29207435192

Coverage increased (+0.1%) to 96.172%

Details

  • Coverage increased (+0.1%) from the base build.
  • Patch coverage: 53 of 53 lines across 1 file are fully covered (100%).
  • No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 1489
Covered Lines: 1432
Line Coverage: 96.17%
Coverage Strength: 1.11 hits per line

💛 - Coveralls

@jgangemi
jgangemi merged commit d6dcf95 into main Jul 12, 2026
4 checks passed
@jgangemi
jgangemi deleted the jae/mc45-lock-unlock branch July 12, 2026 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants