nats-io/nats-server · error

WriteFullState took %v (%d bytes)

Error message

WriteFullState took %v (%d bytes)

What it means

A performance watchdog, not an error: constructing the full stream state buffer for WriteFullState took over 1 minute (size in bytes included). Only construction time is measured since the file write happens without locks; a slow build signals a very large stream.

Source

Thrown at server/filestore.go:12370

	statesEqual := trackingStatesEqual(&fs.state, &mstate)
	// Release lock.
	fs.mu.RUnlock()

	// Check consistency here.
	if !statesEqual {
		fs.warn("Stream state encountered internal inconsistency on write")
		// Rebuild our fs state from the mb state.
		fs.rebuildState(nil)
		return errCorruptState
	}

	if cap(buf) > sz {
		fs.debug("WriteFullState reallocated from %d to %d", sz, cap(buf))
	}

	// Only warn about construction time since file write not holding any locks.
	if took := time.Since(start); took > time.Minute {
		fs.warn("WriteFullState took %v (%d bytes)", took.Round(time.Millisecond), len(buf))
	}

	// Write our update index.db
	// Protect with dios.
	fs.dios.acquire()
	err := os.WriteFile(fn, buf, defaultFilePerms)
	// if file system is not writable isPermissionError is set to true
	fs.dios.release()
	if err != nil {
		return err
	}

	// Update dirty if successful.
	fs.mu.Lock()
	fs.dirty -= priorDirty
	fs.mu.Unlock()

	// Attempt to write other index files, an error in one should not prevent the other from being written.

View on GitHub (pinned to 3a66a489d2)

Solutions

1. Reduce stream scale (limits, retention) if state writes block operations repeatedly
2. Profile the server during state writes to find the hotspot
3. Treat as informational on very large deployments

When it happens

Trigger: Thrown at server/filestore.go:12370 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of nats-io/nats-server@3a66a489d2 (2026-09-02). Data as JSON: /api/errors/92ae58d4815d8bd8. Report an issue: GitHub.