microsoft/garnet · error · Exception

Failed syncing because replica requested truncated AOF addre

Error message

Failed syncing because replica requested truncated AOF address

What it means

Thrown by GarnetAppendOnlyFile.DataLossCheck when a replica requests to sync from an AOF address that is below (lesser than) the primary's current AOF begin address — meaning the requested data has already been truncated. The throw only occurs when possibleAofDataLoss is false (the operator has not opted into unsafe attach); when true, a warning is logged instead and the attach proceeds with potential data loss.

Source

Thrown at libs/server/AOF/GarnetAppendOnlyFile.cs:253

        /// <summary>
        /// Perform a data loss check at recovery
        /// </summary>
        /// <param name="possibleAofDataLoss"></param>
        /// <param name="syncFromAofAddress"></param>
        /// <param name="logger"></param>
        /// <exception cref="Exception"></exception>
        public void DataLossCheck(bool possibleAofDataLoss, AofAddress syncFromAofAddress, ILogger logger = null)
        {
            var beginAddress = Log.BeginAddress;
            var anyLesser = syncFromAofAddress.AnyLesser(beginAddress);

            if (anyLesser)
            {
                if (!possibleAofDataLoss)
                {
                    logger?.LogError("syncFromAofAddress: {syncFromAofAddress} < beginAofAddress: {storeWrapper.appendOnlyFile.BeginAddress}", syncFromAofAddress, beginAddress);
                    throw new Exception("Failed syncing because replica requested truncated AOF address");
                }
                else
                {
                    logger?.LogWarning("AOF truncated, unsafe attach: syncFromAofAddress: {syncFromAofAddress} < beginAofAddress: {storeWrapper.appendOnlyFile.BeginAddress}", syncFromAofAddress, beginAddress);
                }
            }
        }
    }
}

View on GitHub (pinned to 951b0fc683)

Solutions

Re-bootstrap the replica from a fresh full checkpoint so its replication offset is within the primary's current AOF range.
Increase AOF size/retention so truncation does not overtake replica lag.
If accepting data loss is intentional, pass possibleAofDataLoss=true (e.g. via the unsafe-attach server option) — but understand data will be missing.
Monitor replica lag and alert before it exceeds AOF retention.

Defensive patterns

Strategy: validation

Validate before calling

// Before attaching a replica, check that its replication offset is within the primary's AOF range
// (operator-level: compare replica's syncFromAofAddress against the primary's begin address).
// If not, re-bootstrap the replica from a full checkpoint.
// If data loss is acceptable, pass possibleAofDataLoss=true (unsafe-attach option).

Try / catch

try { aof.DataLossCheck(possibleAofDataLoss: false, syncFromAofAddress, logger); }
catch (Exception ex) when (ex.Message.Contains("truncated AOF address"))
{
    logger.LogError("Replica requested truncated AOF; re-bootstrap from full checkpoint or enable unsafe attach.");
    throw;
}

Prevention

Increase AOF retention so truncation does not overtake replica lag.
Re-bootstrap stale replicas from a full checkpoint rather than incremental AOF sync.
Monitor replica lag and AOF begin-address movement.
Only enable unsafe attach (possibleAofDataLoss=true) with explicit acknowledgement of data loss.

When it happens

Trigger: A replica requests syncFromAofAddress that points to truncated AOF data. DataLossCheck is called with possibleAofDataLoss=false (the default/safe mode). The replica's requested start address is behind Log.BeginAddress on any sublog.

Common situations: Replica was offline long enough for the primary to truncate the AOF past the replica's replication offset; a replica attaching to a new primary after failover where histories don't overlap; aggressive AOF truncation with short retention.

Related errors

AI-assisted analysis of microsoft/garnet@951b0fc683 (2026-08-13). Data as JSON: /api/errors/9899ca0622d8c377. Report an issue: GitHub.