CONTRIBUTION FIELD GUIDE 01 / BUILD LIFECYCLE

Progress that moves forward.
Cancellation that lets go.

Two focused contributions to Oliver Dressler’s Lean LSP MCP server. Explore what happens when build phases reset, requests overlap, and the last waiter leaves.

PUBLIC BRANCH SNAPSHOTS2 changes. One reliability story.Independent proposals, illustrated side by side
THE INTERACTIVE LAB

Make the edge cases happen

Synthetic events only · no server connection

REQUEST-LOCAL COUNTER

A notification is a step,
not a percentage.

Lake’s job count may repeat, grow, or restart. Each reported notification still advances the request’s counter by one.

Try repeated counts and phase resets. The bright line keeps climbing.

PROGRESS0
TOTALNone
No fixed denominator
No misleading completion %
MCP notification counterLake completed jobs
START OF REQUESTNOTIFICATION ORDER
MESSAGE PRESERVEDPROGRESS

    No notifications emitted

    This experiment illustrates the monotonic-progress branch only. A fresh request starts a fresh counter. Lake counts stay in message text; total is unspecified.

    WHY THESE CHANGES

    Two contracts worth keeping

    01

    Progress belongs to the request

    A build can pass through clean, cache, and compilation phases. Their local job counts do not form one stable measuring stick.

    The contribution increments a runner-local counter across notifications, sends no total, and retains Lake’s original counts in the message. Repeated counts and new phases no longer move the MCP progress value backward.

    Read monotonic progress change 38b7e1c
    02

    Cancellation belongs to the waiters

    A cancelled request must release its own interest. In share mode, another interested request keeps the latest build alive. With no waiters left, that build is cancelled and its cleanup is drained.

    A replacement starts only after the predecessor’s cleanup finishes. Repeated cancellation must not interrupt that drain, including when intermediate builds never started.

    Read bounded cleanup change f73dcf6
    THE SAFETY BOUNDARY

    Bounded cleanup.
    Honest limits.

    The guarantee follows the process group the runner owns.

    TERMOwned POSIX group
    up to 5s
    KILLIf cleanup times out
    up to 1s more
    • Group members are signalled even if the group leader has already exited.
    • The owned output pipe is closed during cancellation, so inherited pipe writers cannot hold cleanup open indefinitely.
    • A detached descendant in a different group or session is outside the kill guarantee.
    • On Windows, cleanup targets only the direct child.
    • The waits are bounded. Operating-system reaping may still lag after KILL; this is not a guarantee that every process is gone at six seconds.
    PROVENANCE & SCOPE

    Follow the actual code

    These are focused contributions in Alok’s public fork of Oliver Dressler’s Lean LSP MCP, an MIT-licensed server connecting AI assistants with Lean’s language server. This page does not claim authorship of the whole project.

    The two pinned branch snapshots are independent. The cancellation snapshot does not incorporate the monotonic-progress change. This site makes no claim of an upstream pull request, acceptance, or merge.

    Reading tests is not a CI result.

    The public source includes tests for progress resets, notification failures, cancellation, and pipe-holding descendants. These describe intended behavior. Local checks and review do not establish public CI status. This exhibit runs only original JavaScript simulations with invented events; it never starts processes, builds Lean code, reads files, or contacts an MCP server.