app: close only the components Init reached

[cheggaaa]

Problem

app.Close walks every registered component in reverse. After a failed Start, everything past the failing component never had Init called, so its fields are nil — closing it dereferences nil and takes the whole process down.

A space whose ACL can't be built (a data dir carried across networks: acceptor <K> is not the network key → can't init service 'common.acl.syncacl') hits this on every load attempt:

space.Init -> app.Start          # Init fails at syncacl, closeServices closes [0, i]
space.Close -> app.Close         # closes ALL components, incl. [i+1, end] — never Init'd

• linux/amd64: instant SIGSEGV in headsync.(*headSync).Close (h.syncer nil). Guard that one and it moves to objecttreebuilder.(*treeBuilder).Close.
• darwin/arm64: app.Close never returns; the StopDeadline watchdog fires panic("app.Close timeout") 60s later.

Either way one unloadable space kills the process, and the caller's retry re-arms it every few seconds.

Measured on main, three components with the middle one failing:

	Init fails	Run fails
before	close=2	close=2
failing	close=2	close=2
after	init=0 close=1 ← nil deref	close=1

Three defects: components closed without Init, components closed twice, and no mutual exclusion between Start and Close.

Fix

A dedicated lifecycleMu makes Start and Close mutually exclusive and guards four fields:

• started / closed — Start runs at most once (ErrAppAlreadyStarted); Start on a closed app returns ErrAppClosed; Close is idempotent.
• initialized — the Init high-water mark, advanced only after Init returns, so a Close never sees a component that is still initialising.
• closedUpTo — how far Start's own error path already closed. Close covers exactly [closedUpTo, initialized).

mu cannot serve here: a component's Init calls MustComponent, which takes mu.RLock, so Start can never hold mu's write lock. That is also why atomics alone were not enough — see below.

Net effect on component-visible behaviour: no component sees a Close it did not see before. The Init'd-but-never-Run tail after a Run failure is still closed by Close, exactly as today; it is simply no longer closed twice, and never closed early.

Also in the touched function, all three pre-existing and all three load-bearing for this bug's diagnosis:

• every Start return now stops the watchdog — a failed Start leaked a goroutine and a timer, and that goroutine ranged stopStat's map while a concurrent Close wrote it (concurrent map read and map write)
• the start warning reports startStat, not stopStat
• currentComponentStarting is assigned, so components start in progress finally names the component it is waiting on instead of ""

Why not atomics

The first version of this PR used three CAS'd atomics. Review found two holes that no amount of atomics closes, both reproduced as tests before rework:

1. the high-water mark was stored before Init ran, so a concurrent Close closed a mid-Init component — the original nil deref, via the concurrency the guards claimed to support;
2. a Close landing before Start consumed the single cleanup token; Start then Init'd everything and nothing could ever close it.

Both are "Start and Close must not interleave", which is a mutual-exclusion property, not a set of independent flags.

Tests

app/app_test.go (folded into the package's existing tests and harness), green under -race; the behavioural ones fail on main (TestCloseWaitsForInFlightStart panics there with the original nil deref):

• TestStartInitFailureSkipsUninitialized
• TestStartRunFailureClosesEveryInitialized
• TestCloseWaitsForInFlightStart — Close blocks on a component parked in Init
• TestStartAfterCloseIsRejected
• TestCloseWithoutStartClosesNothing — the case the initialized bound protects
• TestConcurrentCloseRunsOnce / TestConcurrentStartRunsOnce — 200 rounds each, asserting the invariant (Init'd ⇒ closed exactly once, not Init'd ⇒ never closed) rather than just an upper bound

go test ./app/... -race and go test ./commonspace/... (21/21) green.

End-to-end

Reproduced by pointing a populated data dir at a nodeconf with a different networkId, then booting.

	before	after
unloadable space present	dies (SIGSEGV / app.Close timeout)	alive at t+95s, health 200, goroutines flat at 114, 0 panics, 0 leaked closes
shutdown, same state	wedged 60s then panic	1.05s
correct nodeconf	—	space active, writes 201, no regression

Out of scope

Left alone deliberately: startStat / stopStat / currentComponentStopping are still written under mu.RLock() (pre-existing), and StartStat()/StopStat() take mu.Lock() while Start/Close hold mu.RLock() and components re-enter it via MustComponent — a stats read concurrent with Start can deadlock. Both predate this change and want their own PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KipFb7V7Ys4AU7CszpHRiZ

[github-actions]

New Coverage	60.2% of statements
Patch Coverage	91.1% of changed statements (41/45)

---

^{Coverage provided by https://github.com/seriousben/go-patch-cover-action}