| Filename | Latest commit message | Latest commit date |
|---|---|---|
dcd70e2f11
Copilot review round 2, both comments upheld. **ELOCKED must not degrade.** Exhausting the retries on a held lock means the lock is *working* and something else demonstrably holds it — so running the mutation anyway entered the exact interleaving the lock exists to prevent, and entered it knowing a concurrent writer was there. `set` now fails instead. Two supporting changes: - The retry budget went from ~3.3s to ~15s so it outlasts the 10s stale window. Refusing is only defensible because a *crashed* holder resolves by takeover first; with the shorter budget, one Inspector killed mid-save would have failed every later save on the box until someone deleted the lock by hand. Pinned by a new test that stages a dead holder's lock directly (mkdir + backdated mtime) and asserts the save succeeds. - Acquire is now probe-then-wait. `proper-lockfile` drives its whole acquire through `retry`, which re-attempts on *any* error — so with a 20-retry budget a read-only `$HOME` would have spent the full 15s re-issuing an identical failing `mkdir` on every save before degrading. One retry-less probe separates "held" (worth waiting out) from "unavailable" (not). **The comment overclaimed what proper-lockfile provides, and the reviewer was right about the mechanism.** Verified against lib/lockfile.js@4.1.2: on EEXIST it stats, and if stale it rmdirs and re-mkdirs *without* checking the directory it removed is the one it found stale — so a slow waiter can still delete a fast waiter's fresh lock and both proceed. That is the same race the hand-rolled version could not close, and it is not closable without renameat2(RENAME_EXCHANGE). What the library actually adds is that the loser is *detected*: its refresh tick compares the lock's mtime against the value recorded at acquire, so a compromised holder is told rather than proceeding silently. And what is genuinely exclusive is the case that matters — mkdir is atomic and a live holder refreshes its mtime, so its lock never goes stale and two running Inspectors are serialized. The residual window opens only after a holder dies without releasing, and the optimistic verify still covers it. file-lock.ts, README.md, specification/v2_servers_file.md and AGENTS.md all carried the overclaim; all four now state the narrower, true version. Also fixes a test that was quietly asserting the opposite of its name: its holder used stale: 60_000 while the waiter used 10_000, and staleness is judged by the *waiter's* threshold — so the holder was declared stale after 10s and the save succeeded by takeover. Not done: a two-process stale-takeover race test. It would be testing the library rather than this code, and is inherently nondeterministic; the honest response to that finding was to stop claiming the race is closed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JTHVxSu8AUgHRLvo1ntZ8H Signed-off-by: cliffhall <cliff@futurescale.com> |
||
| .. | ||
| diagrams | ||
| screenshots | ||
| README.md | ||
| v1_problems.md | ||
| v2_auth.md | ||
| v2_auth_ema.md | ||
| v2_auth_hardening.md | ||
| v2_auth_mid_session.md | ||
| v2_auth_sdk_consolidation.md | ||
| v2_auth_smoke_testing.md | ||
| v2_catalog_launch_config.md | ||
| v2_cli_tui_launcher.md | ||
| v2_new_spec_impact.md | ||
| v2_scope.md | ||
| v2_screenshots.md | ||
| v2_server.md | ||
| v2_servers_file.md | ||
| v2_storage.md | ||
| v2_ux.md | ||
| v2_ux_components.md | ||
| v2_ux_features.md | ||
| v2_ux_handlers.md | ||
| v2_ux_interfaces.md | ||
| v2_ux_interfaces_phase_0_4_inventory.md | ||
| v2_ux_interfaces_plan.md | ||
| v2_ux_storybook.md | ||
| v2_web_client.md | ||
Inspector V2 Brief
Brief | V1 Problems | V2 Scope | V2 Tech Stack | V2 UX | V2 Auth | V2 New Spec Impact
Table of Contents
- Motivation and Context
- Track Protocol Conformance
- Improve Maintainability
- Provide Extensibility
- Proper Documentation
Motivation and Context
The existing Inspector is hard to maintain for a number of reasons. We decided to create a more maintainable Inspector from the ground up, that retains the deterministic boundary of operation, but exposes a plugin architecture.
Track Protocol Conformance
- Identify any gaps in V1 inspector
- Track which features are covered
- Implement to parity and fill gaps
- Provide conformance testing in CI
Improve Maintainability
- Clearer separation of concerns
- Smaller, reusable components
Provide Extensibility
- Plugin SDK / API
- Third parties cand develop/maintain their own plugins for features such as
- LLM usage
- Evals
- Multiple server connections
- Apps playground
- Testing of registry configuration
- Interface with registry
Proper Documentation
- One big README won't cut it anymore
- Published documentation in MDX should
- Render in style of spec
- Kept up to date
- Cover all features
- Discuss troubleshooting strategies
- Provide detailed contribution guidance that explains architecture and expected idioms