{"record":{"id":"532bc504e8657b9f","repo":"nats-io/nats-server","slug":"resetting-wal-state","errorCode":null,"errorMessage":"Resetting WAL state","messagePattern":"Resetting WAL state","errorType":"console","errorClass":null,"httpStatus":null,"severity":"error","filePath":"server/raft.go","lineNumber":4326,"sourceCode":"}\n\n// Lock should be held.\nfunc (n *raft) cancelCatchupSignal() {\n\tif n.catchup == nil || !n.catchup.signal {\n\t\treturn\n\t}\n\t// Send nil entry to signal the upper layers we are done catching up.\n\tn.apply.push(nil)\n}\n\n// Truncate our WAL and reset.\n// Lock should be held.\nfunc (n *raft) truncateWAL(term, index uint64) {\n\tn.debug(\"Truncating and repairing WAL to Term %d Index %d\", term, index)\n\n\tif term == 0 && index == 0 {\n\t\tif n.commit > 0 {\n\t\t\tn.warn(\"Resetting WAL state\")\n\t\t} else {\n\t\t\tn.debug(\"Clearing WAL state (no commits)\")\n\t\t}\n\t}\n\tif index < n.commit {\n\t\tassert.Unreachable(\"WAL truncate lost commits\", map[string]any{\n\t\t\t\"n.accName\": n.accName,\n\t\t\t\"n.group\":   n.group,\n\t\t\t\"n.id\":      n.id,\n\t\t\t\"term\":      term,\n\t\t\t\"index\":     index,\n\t\t\t\"commit\":    n.commit,\n\t\t\t\"applied\":   n.applied,\n\t\t})\n\t}\n\n\tdefer func() {\n\t\t// Check to see if we invalidated any snapshots that might have held state","sourceCodeStart":4308,"sourceCodeEnd":4344,"githubUrl":"https://github.com/nats-io/nats-server/blob/3a66a489d262bf89b71a71c955c94920394532f3/server/raft.go#L4308-L4344","documentation":"truncateWAL was asked to reset to term 0/index 0 while the node had commits (commit > 0) — i.e. the entire WAL state is being discarded rather than merely cleared when empty. Logged at warn because it means committed history on this node is being thrown away in favor of re-following a leader.","triggerScenarios":"Thrown at server/raft.go:4326 when the library encounters an invalid state.","commonSituations":"See trigger scenarios.","solutions":["Expected during reset/conflict recovery flows; the node re-syncs from the leader","Ensure at least one healthy peer retains the data before resets","Investigate if resets happen outside deliberate recovery operations"],"exampleFix":null,"handlingStrategy":"fallback","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":[],"tags":[],"backgroundTag":null,"analyzedSha":"3a66a489d262bf89b71a71c955c94920394532f3","analyzedAt":"2026-09-02T04:41:54.247Z","contentChangedAt":null,"schemaVersion":2},"datasetVersion":"2026-09-08T15:18:49.778Z"}