AOF Replay replays 0 bytes despite a correctly populated AOF

[Greg Slasor FIS (slasorg)]

Describe the Issue

With EnableAOF=true and Recover=true, AOF replay consistently replays 0 bytes despite a populated AOF file present

Steps to Reproduce

Garnet server config is as follows (starting from a small C# console app) :

    var garnetServerOptions = new GarnetServerOptions
    {
        EndPoints = [new IPEndPoint(IPAddress.Any, 6379)],
        CheckpointDir = "./Garnet/",
        EnableAOF = true,
        AofSizeLimit = "500m",
        EnableFastCommit = false,
        QuietMode = true,
        Recover = true,
        CommitFrequencyMs = 1000
    };

    var garnetServer = new GarnetServer(garnetServerOptions);
    garnetServer.Start();

After writing to db0 using Stackexchange.Redis 2.8.31 the value is visible via a RESP client and the db0 AOF file is created (and its contents correct):

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         2/13/2026   4:39 PM                log-commits
-a----         2/13/2026   4:39 PM         114176 aof.log.0

However restarting the Garnet server does not restore db0 (it is empty).

Starting the server with logging on (using an equivalent garnet.conf in this case as the POCO doesn't expose a log path) we consistently log replaying 0 records for db0 AOF :

[000.2026-02-13 20:43:32.8743] (Information) <MultiDatabaseManager> Begin AOF recovery for DB ID: 0
[000.2026-02-13 20:43:32.8747] (Information) <MultiDatabaseManager> Begin AOF replay for DB ID: 0
[000.2026-02-13 20:43:32.8770] (Information) <MultiDatabaseManager> Completed full AOF sublog replay of 0 records (DB ID: 0)
[000.2026-02-13 20:43:32.8778] (Debug) <Session> [] [02ADE75B] Disposing RespServerSession Id=0
[000.2026-02-13 20:43:32.8851] (Information) <MultiDatabaseManager> AOF Recovery in 0.010791499999999999 secs
[000.2026-02-13 20:43:32.8852] (Information) <MultiDatabaseManager> Total number of replayed records 0 bytes
[000.2026-02-13 20:43:32.8853] (Information) <MultiDatabaseManager> Throughput 0.00 records/sec
[000.2026-02-13 20:43:32.8853] (Information) <MultiDatabaseManager> AOF Recovery size 48
[000.2026-02-13 20:43:32.8854] (Information) <MultiDatabaseManager> AOF Recovery throughput 0.00 GiB/secs

Expected Behaviour

The value previously written to db0 is restored successfully on server restart

Actual Behaviour

AOF replay consistently replays 0 records/0 bytes

Environment

Garnet 1.0.84
Stackexchange.Redis 2.8.31
Windows 11 23H2
.NET 10 (10.0.102)

Questions

I suspect this is due to AOF sizing and configuration? I have read similar issues where the AOF doesn't recover due to records exceeding the page size, but in this case the AOF file (which is a single record) is ~112KB and so I would not expect this to be sizing related?

[Badrish Chandramouli (badrishc)]

You need to ensure the AOF is actually committed before you stop/restart:

• Enable periodic commits by setting a non-zero CommitFrequencyMs and give the server enough time to hit at least one commit interval after your writes (e.g., don’t immediately terminate the process right after SET).
• Or manually force an AOF commit right after your writes via the RESP command COMMITAOF (send it from your client before shutdown),

There is no need to set the EnableFastCommit to false.

Once an AOF commit has happened, restart should replay the entries and DB0 should come back.

[Greg Slasor FIS (slasorg)]

Hi Badrish Chandramouli (@badrishc) ,

Thanks for the response.

I've tried a few things here however the behaviour persists (pun intended)

1. Set EnableFastCommit to true and dropped CommitFrequencyMs down to 100. With this I again see aof.log.0 created and a commit.1.0 in log-commits. Running info persistence in this state returns

127.0.0.1:6379> info persistence
# Persistence_DB_0
CommittedBeginAddress:64
CommittedUntilAddress:92260
FlushedUntilAddress:92260
BeginAddress:64
TailAddress:92260
SafeAofAddress:-1

And so it seems we have an AOF entry persisted. However restarting the server again does not restore the value from db0. Running info persistence again after restart returns

# Persistence_DB_0
CommittedBeginAddress:64
CommittedUntilAddress:64
FlushedUntilAddress:64
BeginAddress:64
TailAddress:64
SafeAofAddress:-1

2. I tried forcing an AOF commit via COMMITAOF, that also seemed to correctly create a commit

127.0.0.1:6379> info persistence
# Persistence_DB_0
CommittedBeginAddress:64
CommittedUntilAddress:130056
FlushedUntilAddress:130056
BeginAddress:64
TailAddress:130056
SafeAofAddress:-1

But again no value is restored on server restart and running info persistence gives the same as with the auto commit after restart.

Anything else worth a try here? Is there logging I can enable that would help to debug? I can retry with the latest build as well though the version I'm currently running is not far off.

Thanks!

[Greg Slasor FIS (slasorg)]

You need to ensure the AOF is actually committed before you stop/restart:

• Enable periodic commits by setting a non-zero CommitFrequencyMs and give the server enough time to hit at least one commit interval after your writes (e.g., don’t immediately terminate the process right after SET).
• Or manually force an AOF commit right after your writes via the RESP command COMMITAOF (send it from your client before shutdown),

There is no need to set the EnableFastCommit to false.

Once an AOF commit has happened, restart should replay the entries and DB0 should come back.

Hi Badrish Chandramouli (@badrishc) ,

Just back to add more details. I had a chance to fiddle with this again - I was curious if the nature of the data I was saving was somehow interfering with AOF recovery, so I did a quick test manually writing Test/Test to db1 and then running COMMITAOF.

This succeeded and again that simple data is visible in the db1 AOF but it is not restored after server restart.