From f9c6f92c4b21bd8a03696e1266278c8685305595 Mon Sep 17 00:00:00 2001
From: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com>
Date: Tue, 14 Jul 2026 16:31:51 +0530
Subject: [PATCH] docs(state): fix _enforce_macos_synchronous_full docstring

synchronous=FULL issues plain fsync(), not F_FULLFSYNC. The
F_FULLFSYNC barrier comes from checkpoint_fullfsync=1, set by the
separate _apply_macos_checkpoint_barrier(). The original docstring
conflated the two PRAGMAs.
---
 hermes_state.py | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hermes_state.py b/hermes_state.py
index a8c529acecfd..79e95ffa66e4 100644
--- a/hermes_state.py
+++ b/hermes_state.py
@@ -366,8 +366,10 @@ def _enforce_macos_synchronous_full(conn: sqlite3.Connection) -> None:
     DB with half-written btree pages → ``btreeInitPage error 11``.
 
     WAL mode's durability guarantee assumes the OS honors fsync barriers;
-    macOS does not unless we explicitly set ``synchronous=FULL`` (which
-    issues ``fsync()`` *and* ``F_FULLFSYNC`` via checkpoint_fullfsync=1).
+    macOS does not unless we explicitly set ``synchronous=FULL``, which issues
+    a real ``fsync()`` on every transaction commit.  The ``F_FULLFSYNC``
+    barrier at checkpoint boundaries is handled separately by
+    :func:`_apply_macos_checkpoint_barrier`.
 
     This function is called after any successful WAL activation (either
     from ``apply_wal_with_fallback()`` setting a fresh WAL or when probing