P2 Moving WriteSecretFiles before manifestOK.complete(nil) puts synchronous filesystem I/O on the critical path for tailnet init, with no context or timeout (Edge Case Analyst P2, Go Architect Obs)

manifestOK gates createOrUpdateNetwork (line 1442), which in turn gates coordination, DERP subscription, and the stats loop (1186-1206). Before this PR, writes happened after manifestOK.complete, so a hung disk only affected file-based secrets. Now a hung or very slow filesystem — NFS/FUSE home mount, misconfigured overlay, disk full with sync writes — blocks the whole chain indefinitely. WriteSecretFiles calls fs.MkdirAll and afero.WriteFile without a context; per-secret errors are logged and skipped, but a syscall that never returns is not "an error".

Go Architect adds: the function takes ctx context.Context but never checks it. If the agent's stopCtx is cancelled mid-write (graceful shutdown racing with a slow filesystem), the loop keeps running. A select { case <-ctx.Done(): return; default: } at the top of each iteration would make the function respect cancellation without adding meaningful complexity.

The ordering fix is correct — the alternative (SSH sessions racing missing secret files) is worse. Two refinements worth considering: (a) bounded timeout / ctx check inside the loop so a hung FS can't block network init forever, or (b) detach the write into a goroutine that only the startup-script path waits on, preserving the guarantee the fix established without putting writes on the critical path. Common case is fine; the tail-latency case is the new blast radius.

I revisited this. I reconsidered doing the file I/O before signalling manifestOK.complete. I don't think it makes much sense to block networking init for the secret file I/O considering some secret files may be large cert chains. So I moved the file I/O back to immediately after manifestOK.complete is signalled.

There will be a theoretical race where an SSH session that connects and reads a secret file before writes finish would see stale or missing content, but in practice SSH requires network init + coordination before any connection arrives, which should take far longer than file writes.

I have documented the assumption above. If the race proves to be a real issue, we can synchronize things better.

I believe that this join opens up an issue around secrets overwriting each other. File-path uniqueness is enforced on the raw stored string, but the agent normalizes before writing (~/ expansion plus filepath.Clean). So two accepted secrets such as ~/.aws/credentials and /home/coder/.aws/credentials collapse to the same on-disk path and one silently overwrites the other.

Good callout. This is a bit challenging because we don't know the workspace home dir before it starts (not easily anyway). I added logging when this happens + test in this PR. It's something we'll need to document for the feature as well.

We could even warn about this in the UI if two paths look like potential conflicts after resolution, but we can cross that bridge when we get there.

This is unfortunate. Ideally there would be some way of surfacing this to the user more visibly in the UI.

Agreed. We are planning surface these conflicts alongside what secrets were injected and where. Something like this:

I'm planning to tackle this in a subsequent PR.

We'll probably want to do another pass of any place we log the manifest.
Would it make sense to to mark this with debug_redact?

Unfortunately debug_redact isn't supported in Go yet 😢

Rather than manually stripping out the secrets on every agent.Manifest.Load() call, I decided to strip them off as soon as the agent receives the manifest and to store the secrets separately from the manifest received by the agent. I think this ended up being a much better approach to prevent future accidental leakage.