[M10 planning] Reconcile cancellation and responsive-analysis contracts

[Teakowa]

Parent: #27

Depends on: #72, #73, #74

Goal

Reconcile M10's formal issue contracts with the evidence-backed decision to keep synchronous bounded recomputation and defer true in-flight cancellation until project scale or measured latency justifies it.

Context

Current implementation and performance evidence support deterministic full recomputation at low interactive latency, but #64/#67/#68/#27 still formally require cancellation while the latest gate comment claims cancellation was deferred under "revised criteria". The acceptance contract itself was never revised, so the project currently has contradictory planning state.

This issue is primarily a planning/contract correction. It must not be used as justification to introduce speculative asynchronous cancellation infrastructure.

Scope

• Reassess current language-service/LSP latency and memory evidence after [M10 correctness] Make diagnostics source-aware and dependency-reactive #72–[M10 correctness] Harden LSP URI, UTF-16, and document lifecycle boundaries #74 land.
• Decide explicitly whether true in-flight request cancellation remains required for M10.
• Preferred outcome, if current measurements remain bounded: defer true cancellation and make stale/current-state guarantees the M10 requirement.
• Update [M10] Add incremental parsing, dependency invalidation, and reanalysis #64, [M10] Implement LSP server as a thin protocol adapter #67, [M10] Validate LSP client compatibility, responsiveness, and workspace behavior #68, and [M10] Language services and LSP #27 so their Goal/Scope/Acceptance Criteria accurately reflect the chosen contract.
• Preserve requirements that:
  • stale/out-of-order document state cannot overwrite current state;
  • obsolete semantic results cannot be surfaced as current;
  • interactive operations remain within a declared responsiveness budget for the representative project scale.
• Record a measurable trigger for reconsidering true cancellation/incremental analysis when project size or latency changes materially.
• Keep any deferred capability explicit in [M10] Validate language-service milestone and reassess post-M10 roadmap #69's final gate evidence.

Non-goals

• Implementing async cancellation merely to satisfy historical wording.
• Building diff-based incremental parsing/analysis without a measured need.
• Weakening stale-result correctness requirements.
• Rewriting M10 history to pretend cancellation was previously implemented.

Acceptance criteria

• [M10] Add incremental parsing, dependency invalidation, and reanalysis #64, [M10] Implement LSP server as a thin protocol adapter #67, [M10] Validate LSP client compatibility, responsiveness, and workspace behavior #68, and [M10] Language services and LSP #27 no longer contradict the implementation/final gate on whether true cancellation is required.
• If cancellation is deferred, the revised contracts explicitly distinguish stale-result suppression from in-flight request cancellation.
• The decision cites current measured language-service/LSP latency and resource evidence.
• A concrete future re-evaluation trigger is documented rather than leaving the deferral indefinite and untestable.
• No new async/incremental architecture is introduced unless new evidence from [M10 correctness] Make diagnostics source-aware and dependency-reactive #72–[M10 correctness] Harden LSP URI, UTF-16, and document lifecycle boundaries #74 demonstrates that bounded synchronous recomputation is no longer adequate.
• Historical comments remain historical evidence; current issue bodies become the authoritative acceptance contract.

Planning notes

This issue should be implemented only after the correctness work in #72–#74 is audited. It is deliberately last among implementation/planning fixes so acceptance criteria are revised from the resulting current reality, not to make incomplete work easier to close.

[Teakowa]

Decision (implementing #75)

True in-flight request cancellation is deferred and is not an M10 requirement. The M10 responsiveness contract is stale/current-state correctness over bounded synchronous deterministic full recomputation.

Evidence (current, measured after #72–#74)

• wright-language/tests/perf.rs over the heaviest corpus fixture (real-world/overpy-cake), 20 iterations (target/language-service-perf.json): analyze ≈1.03 ms, diagnostics ≈0.94 ms, hover ≈0.91 ms mean; peak RSS ≈7.3 MB.
• The LSP round-trip bound test (lsp_round_trips_are_bounded) executes 20 hover requests well under its 10 s bound; the full 13-test protocol suite runs in ~0.3 s including process spawn.
• Correctness guarantees are enforced and tested: stale/out-of-order client versions cannot overwrite newer state (DocumentStore::change + LSP stale-version harness); results are version-tagged; every query re-reads current document state; didClose retires diagnostics ([M10 correctness] Make diagnostics source-aware and dependency-reactive #72); rename validates the edited project before returning ([M10 correctness] Implement project-wide semantic rename #73).

Contract distinction

Stale-result suppression ≠ in-flight request cancellation. The former is required and implemented; the latter is deferred. Revised acceptance criteria in #27, #64, #67, #68 now reflect this distinction, so the issues no longer contradict the implementation or the final gate.

Re-evaluation trigger (measured, testable)

Re-open the true-cancellation or incremental-analysis decision when any of the following holds on the current machine baseline:

• committed perf harness mean for analyze or diagnostics exceeds the 200 ms regression bound; or
• peak RSS on the perf workload exceeds 1 GB; or
• a representative project-scale measurement (a multi-file corpus of at least 20 source files, or the declared representative project) shows any single interactive request exceeding 100 ms.

Documented in docs/language-services.md (Responsiveness contract) and enforced by the existing perf regression test.

[Teakowa]

Closing as implemented: true in-flight cancellation is deferred; the authoritative M10 contract (issue bodies #27/#64/#67/#68 and docs/language-services.md) distinguishes stale-result suppression from in-flight cancellation and records a measured re-evaluation trigger. Decision comment above is the authoritative record.