Release v19.82.2

Summary

Unique-value claims and closed-stream closures no longer silently drift away from the event log when the write after an append fails. Each event sequence now keeps a watermark of how far its constraint indexes are confirmed, and the kernel repairs them from the log when they fall behind.

Added

• Event sequences report how far their constraint indexes lag behind the log as a metric, alongside metrics for repairs and unknown append outcomes. (#4895)

Changed

• An append whose stored outcome the kernel cannot confirm now fails with the AppendOutcomeUnknown error instead of reporting success or a plain failure. The events may or may not be stored, so do not retry blindly. Read the event source's events and append again only if none carries the attempt's correlation id. See Appending events. (#4895)
• While a unique or closing constraint index that governs an append still needs repair, the append fails with the ConstraintIndexUnavailable error and nothing is stored. Retry it unchanged after a short delay. (#4895)
• A constraint reindex no longer requires appends to stop. The rebuild hands its progress back to the event sequence, which restores claims and closures written while it ran. (#4895)

Fixed

• Unique constraints and closing constraints stay consistent with the event log when updating their index fails after an append, or when the kernel stops in between. Each event sequence persists how far its constraint indexes are confirmed in MongoDB, SQL and in-memory storage. Before validating an append, it repairs any gap from the log, and it catches older indexes up in the background without blocking live appends. (#4895)
• Constraint index repairs write only the claims that actually differ, report a budget expiry or a failing constraint in their results, and recover from transient storage failures instead of leaving the index partly updated. (#4895)