chore(compose): one compose file, and a pinned project name - #441
Open
hugolytics wants to merge 1 commit into
Open
chore(compose): one compose file, and a pinned project name#441hugolytics wants to merge 1 commit into
hugolytics wants to merge 1 commit into
Conversation
Today the calendar MCP server crash-looped for three hours on a zero-byte `tokens.json`, while a perfectly good token file sat in a second volume that nothing mounted. The cause was not the token file. It was that this repo had two compose files defining the same three services. Compose derives its project name from the directory the file sits in, and the project name prefixes every volume. So `infra/docker-compose.yml` created `infra_calendar-mcp-tokens` and the root file created `admonish-1_calendar-mcp-tokens`. Same service, same declared volume name, two different volumes -- and which one held the live credentials depended on which file someone last ran. They had also drifted apart: the infra copy pinned google-calendar-mcp v1.4.8 and mounted `/home/node/...`, while root pins v2.3.1 and mounts `/home/nodejs/...` (that image runs as a different user). Starting the stack from the wrong file would have mounted the tokens where the server does not look for them. - Delete `infra/docker-compose.yml` and `infra/docker-compose-2.yml`. Every service in them -- calendar-mcp, neo4j, graphiti-mcp -- is already in the root file, on newer pins. `AGENTS.md` had called the second one legacy since before this; the first was never declared anywhere. - Pin `name: admonish-1` in the root file, so the project name no longer depends on where it is invoked from. This is the line that actually prevents a recurrence; deleting the duplicate only removes today's instance. - Point `scripts/README.md` at the one remaining stack, and update the `AGENTS.md` rule that named a file this commit deletes. `infra/dsh` stays -- it is the live harness profile, not compose. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Today the calendar MCP server crash-looped for three hours on a zero-byte
tokens.json, while a perfectly good token file sat in a second volume thatnothing mounted.
The token file was the symptom. The cause is that this repo had two compose
files defining the same three services.
Compose derives its project name from the directory the file sits in, and the
project name prefixes every volume:
infra/docker-compose.ymlinfrainfra_calendar-mcp-tokensdocker-compose.ymladmonish-1admonish-1_calendar-mcp-tokensSame service, same declared volume name, two different volumes — and which one
held the live credentials depended on which file someone last ran.
They had also drifted. The infra copy pinned google-calendar-mcp v1.4.8 and
mounted
/home/node/...; root pins v2.3.1 and mounts/home/nodejs/...,because that image runs as a different user. Starting the stack from the infra
file would have put the tokens where the server does not look for them.
What changed
infra/docker-compose.ymlandinfra/docker-compose-2.yml. Everyservice in them —
calendar-mcp,neo4j,graphiti-mcp— already exists inthe root file on newer pins.
AGENTS.mdhad called the second one legacy fora while; the first was never declared canonical anywhere.
name: admonish-1in the root file. This is the line thatprevents a recurrence — deleting the duplicate only removes today's instance,
whereas pinning the name makes the volume set independent of where compose is
invoked from.
scripts/README.mdat the one remaining stack, and rewrote theAGENTS.mdrule that named a file this PR deletes.infra/dshis untouched — it is the live harness profile, not compose.Verification
docker compose configresolves toname: admonish-1, calendar-mcp at v2.3.1mounting
/home/nodejs/.config/google-calendar-mcp.The running container was migrated onto the canonical project and confirmed
healthy afterwards: it mounts
admonish-1_calendar-mcp-tokens, logsValid tokens found for account(s): normal, and answers with all 12 tools.Related: #435, which stops a calendar outage from permanently breaking the
planner. This PR stops the outage from happening this way again.
🤖 Generated with Claude Code