Value exceeding AofPageSize is not written to AOF but still cached

[rdavisunr]

Describe the bug

When attempting to set a value larger than the configured AofPageSize with EnableAOF set to true, the Set operation throws an exception: Tsavorite.core.TsavoriteException: Entry does not fit on page

After the exception is thrown, the client connection is closed and the value is not written to the AOF.

However, despite the rejected AOF write, subsequent GET operations for the key return the value successfully, resulting in a state where the in‑memory cache and the AOF are inconsistent.

Steps to reproduce the bug

1. Start Garnet v1.1.6 with the following configuration:

{
    "EnableAOF": true,
    "Recover": true
}

2. Set a value that exceeds the default AofPageSize of 4MB.
3. Observe that the Set fails with: Tsavorite.core.TsavoriteException: Entry does not fit on page
4. Reconnect client and attempt to retrieve the key of the value that exceeded AofPageSize

Result
The entry is retrieved successfully.
The entry is not present in the AOF.

Expected behavior

AOF and memory cache are consistent when an entry exceeds AofPageSize

Screenshots

No response

Release version

v1.1.6

IDE

No response

OS version

Windows Server 2025

Additional context

Noticed after testing the fix for #1749 (the sample program from that issue can be used to reproduce this issue).

[badrishc]

The invariant you need (on v1) is that AofPageSize should be larger than twice the KV's PageSize (--page). I would set AofPageSize to be twice PageSize, for example. Then, you will never run into situation where entry exceeds AOF page size.

[rdavisunr]

Is the current behavior where the inconsistency can occur intended?

So, if the SET operation cannot write the KV to the AOF due to exceeding AofPageSize, should the entry still be placed in the memory cache (when the KV < PageSize)?

IMO, having the SET partially succeed (in memory) while failing durability seems problematic, since the client receives an exception and the connection is severed, but the data is still retrievable afterward.

The default configuration makes this scenario possible since the default PageSize is 32MB while AofPageSize defaults to 4MB. So, there's a 28MB window where a value can be cached but not persisted to AOF.

Thanks, I appreciate your feedback.

[badrishc]

Agreed. We need to add an assert to prevent users from starting Garnet with aof page size that is incompatible with log page size. (And, adjust the defaults.)