hermes - 💡(How to fix) Fix [Bug]: get_last_init_error() reads _last_init_error without the documented lock (hermes_state.py)

Description

hermes_state._set_last_init_error() protects the shared _last_init_error variable with _last_init_error_lock, and its docstring explicitly states: "Thread-safe via _last_init_error_lock."

However, get_last_init_error() reads the same variable without acquiring the lock:

# hermes_state.py:77
def _set_last_init_error(msg: Optional[str]) -> None:
    """...Thread-safe via _last_init_error_lock..."""
    global _last_init_error
    with _last_init_error_lock:   # ← lock acquired
        _last_init_error = msg

# hermes_state.py:94
def get_last_init_error() -> Optional[str]:
    """..."""
    return _last_init_error        # ← NO lock — races with the setter

Root cause

The lock was added to the setter (presumably to protect against concurrent SessionDB() initialisations in the gateway), but the getter was not updated to match. The API contract ("thread-safe via lock") is only half-implemented.

Impact

• In CPython the assignment of a single object pointer is atomic (GIL), so this is unlikely to cause memory corruption in practice.
• On non-CPython runtimes (PyPy, GraalPy) or if the GIL is removed (--disable-gil), this is a genuine data race.
• The inconsistency misleads readers: the lock exists but isn't used symmetrically, making the locking intent unclear and fragile.
• The gateway creates a new SessionDB() per request on multiple threads; any concurrent failure during start-up could race with a /resume handler calling get_last_init_error().

Fix

Acquire _last_init_error_lock in the getter:

def get_last_init_error() -> Optional[str]:
    with _last_init_error_lock:
        return _last_init_error

One line change; the lock is already imported and initialised at module level.