Nothing identifies a session whose carddav mount was withdrawn #25

New issue

Open

opened 2026-08-28 02:15:09 +00:00 by jlxq0 · 1 comment

jlxq0 commented

2026-08-28 02:15:09 +00:00

Owner

A client refused at session start withdraws the tools and never retries, so
the blast radius of an initialize refusal outlives the refusal by the whole
life of the session. v0.1.5 stops new refusals and returns nothing already
lost.

Measured 2026-08-28. lucy's config listed carddav; her running session had
no carddav tools, and ToolSearch returned a cached 429 string quoting an
image that had already been replaced. She declined to pass that string back as
a result, correctly: it would have recorded a 429 against a pod that rolled out
at 02:07:22Z and had never been asked anything by her.

A restart fixes it, with a value rather than an inference: her session was
killed at 02:12:1x and this server logged her first connect at 02:12:20.893,
inside a second, after which whoami and list_address_books both returned
real data.

The gap

Nothing identifies which sessions are in that state. From the cluster there
is no signal at all: the pod sees no request from a session that gave up, so a
withdrawn mount and a session that never had the mount produce identical
evidence, which is none. From inside the session the only trace is a cached
error string whose subject may no longer exist.

During tonight's livelock that state was reached silently by every session that
happened to start in the window, and it was found by asking three agents
individually.

Why this is filed rather than fixed

The remedy is a client behaviour: retry the mount, or surface the withdrawal so
something can act on it. This server cannot cause either. What it can do is
stop producing the condition, which v0.1.5 does, and that is already shipped.

Worth keeping open because the operational consequence is real and recurs with
any future refusal: after any incident that refuses initializes, the mounts do
not come back on their own and somebody has to restart sessions without a list
of which ones.

Adjacent, not the same: #21 is why the limit is fleet-wide, #22 is why one
connection costs two charges.

A client refused at session start withdraws the tools and never retries, so **the blast radius of an initialize refusal outlives the refusal by the whole life of the session.** `v0.1.5` stops new refusals and returns nothing already lost. Measured 2026-08-28. `lucy`'s config listed `carddav`; her running session had no carddav tools, and `ToolSearch` returned a **cached 429 string quoting an image that had already been replaced**. She declined to pass that string back as a result, correctly: it would have recorded a 429 against a pod that rolled out at 02:07:22Z and had never been asked anything by her. A restart fixes it, with a value rather than an inference: her session was killed at 02:12:1x and this server logged her first connect at **02:12:20.893**, inside a second, after which `whoami` and `list_address_books` both returned real data. ## The gap **Nothing identifies which sessions are in that state.** From the cluster there is no signal at all: the pod sees no request from a session that gave up, so a withdrawn mount and a session that never had the mount produce identical evidence, which is none. From inside the session the only trace is a cached error string whose subject may no longer exist. During tonight's livelock that state was reached silently by every session that happened to start in the window, and it was found by asking three agents individually. ## Why this is filed rather than fixed The remedy is a client behaviour: retry the mount, or surface the withdrawal so something can act on it. **This server cannot cause either.** What it can do is stop producing the condition, which `v0.1.5` does, and that is already shipped. Worth keeping open because the operational consequence is real and recurs with any future refusal: after any incident that refuses initializes, the mounts do not come back on their own and somebody has to restart sessions without a list of which ones. Adjacent, not the same: #21 is why the limit is fleet-wide, #22 is why one connection costs two charges.

jlxq0 commented

2026-08-28 02:18:13 +00:00

Author

Owner

This is not a carddav property and it is being handled above this repository.
Recorded here because the routing otherwise lives only in a peer message, which
does not survive the session that sent it.

Any MCP server that errors at initialize leaves the client silently toolless
in the same way: config lists the mount, the running session has no tools, and
ToolSearch returns a cached error that may quote an image no longer running.
There are eight mounts across this fleet, and whether any session holds what its
config claims has been checked for carddav and for nothing else.

Alan has taken it to mantis, which can ask the directors directly. Nothing
about the general case needs a change in this repository.

What stays open here is the carddav-shaped half: after any future incident
that refuses initializes on this server, the mounts do not return on their own,
and there is no signal from the pod identifying which sessions gave up. The
remedy is known and cheap — restart the session, measured at 02:12:20.893 after
a kill at 02:12:1x — so the only unanswered question is which sessions, and
that is answerable by asking rather than by building anything.

Close this if the fleet-level work supersedes it.

**This is not a carddav property and it is being handled above this repository.** Recorded here because the routing otherwise lives only in a peer message, which does not survive the session that sent it. Any MCP server that errors at `initialize` leaves the client silently toolless in the same way: config lists the mount, the running session has no tools, and `ToolSearch` returns a cached error that may quote an image no longer running. There are eight mounts across this fleet, and whether any session holds what its config claims has been checked for `carddav` and for nothing else. Alan has taken it to `mantis`, which can ask the directors directly. Nothing about the general case needs a change in this repository. **What stays open here** is the carddav-shaped half: after any future incident that refuses initializes on this server, the mounts do not return on their own, and there is no signal from the pod identifying which sessions gave up. The remedy is known and cheap — restart the session, measured at 02:12:20.893 after a kill at 02:12:1x — so the only unanswered question is *which sessions*, and that is answerable by asking rather than by building anything. Close this if the fleet-level work supersedes it.

No labels

waiting-on-julian

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jlxq0/carddav-mcp#25

No description provided.

Rows
Columns