fix(daemon): a superseded daemon overwrites the shared daemon-shutdown.json
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- cli
Research direction
Locate writeDaemonShutdownReport and clearDaemonShutdownReport, then trace readRegisteredDaemonOwnership and the shared state paths they use. Confirm how ownership records are interpreted and update both sites so a daemon proceeds only when ownership is match; done means a superseded daemon cannot overwrite or clear the successor's shutdown report.
Written by the indexing model from the issue text.
Description
Problem
writeDaemonShutdownReport and clearDaemonShutdownReport write and delete daemon-shutdown.json in the shared state dir without checking who owns it, unlike the daemon.json and daemon.lock paths, which now prove ownership first (#3087).
A daemon that has been superseded still runs its own shutdown, so it can:
- overwrite the successor's shutdown report with its own, or
- clear a report the successor still needs.
Both hide why a shutdown happened from whoever is debugging the daemon that is actually serving clients.
Why it is separate from #3087
The issue's completion conditions cover daemon.json only. The fence needs the same reasoning applied to a second shared file, and that file has its own readers whose expectations have to be checked, so it does not belong in the #3087 diff.
Direction
Reuse readRegisteredDaemonOwnership at both sites and decline the write when the record is not match. Note that this file is written by the daemon leaving, so the check is "am I still the serving daemon", not "does this file name me".
Refs #3087, #3102
- Dominant language
- TypeScript
- Stars
- 4.8k
- Forks
- 315
- Avg merge
- 11h 17m
- Merged PRs (30d)
- 536
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from callstack/agent-device
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
callstack/agent-device#1869 ·
Maintainers usually reply within 1 day
-
needs-triage refactor
Difficulty 5/5 Over a week Newbie friendliness 25/100
callstack/agent-device#3116 · 4 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
callstack/agent-device#3106 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
callstack/agent-device#3105 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 38/100
callstack/agent-device#3077 ·
Maintainers usually reply within 1 day
All issues in callstack/agent-device
Similar issues
-
check:failed streams:add
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
iptv-org/iptv#53974 · 1 comment ·
Maintainers usually reply within 1 day
-
type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
interledger/rafiki#3986 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Doist/todoist-cli#576 ·
Maintainers usually reply within 1 day
-
feature
Difficulty 1/5 Under an hour Newbie friendliness 72/100
vercel-labs/skills#2370 ·
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day