From aebcc6ea0cdc629c5d2df31c0ff85f8b3d8ed6cd Mon Sep 17 00:00:00 2001 From: Evgen Byelozorov Date: Sat, 18 Jul 2026 17:11:51 +0200 Subject: [PATCH] fix(store): surface FlushFileBuffers failure in journal SYNC mode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In RAY_JOURNAL_SYNC mode ray_journal_write_bytes checks fsync's return on POSIX and fails the write with RAY_ERR_IO, but the Windows branch ignored FlushFileBuffers' return. A failed flush there was silently swallowed, so SYNC mode reported success while the data may not have reached disk — dropping the durability guarantee the mode exists to provide. Check FlushFileBuffers (0 = failure) and return RAY_ERR_IO, mirroring the POSIX path. Windows-only branch (not built on the Linux/macOS CI matrix), so it is verified by inspection against the adjacent fsync check; the failure path is not unit-testable, like the existing POSIX one. --- src/store/journal.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/store/journal.c b/src/store/journal.c index f7f82aa29..53ea0ad97 100644 --- a/src/store/journal.c +++ b/src/store/journal.c @@ -173,7 +173,11 @@ ray_err_t ray_journal_write_bytes(const ray_ipc_header_t* hdr, #ifndef RAY_OS_WINDOWS if (fsync(fileno(g_journal.fp)) != 0) return RAY_ERR_IO; #else - FlushFileBuffers((HANDLE)_get_osfhandle(_fileno(g_journal.fp))); + /* FlushFileBuffers returns 0 (FALSE) on failure — surface it as an I/O + * error like the fsync path above, so SYNC mode's durability guarantee + * isn't silently dropped on Windows. */ + if (!FlushFileBuffers((HANDLE)_get_osfhandle(_fileno(g_journal.fp)))) + return RAY_ERR_IO; #endif } return RAY_OK;