fix: a reveal and the access-log writer no longer wait for each other (release/0.1 port of #45)

Conversation 0 Commits 1 Files Changed 5

+318 -13

1 Commits

Author	SHA1	Message	Date
james.maesandClaude Fable 5.2	c2fde973a5	fix: a reveal and the access-log writer no longer wait for each other maven / build (push) Successful in 2m0s Details build / maven (push) Successful in 2m0s Details A reveal, and the start, end and expiry of a break-glass session, hold the runtime's monitor from their first check to their last write. Asking for a classification (SecuredDataRuntime.classificationRows, and activeRetentionRules) took the same monitor, and every thread asks: core asks for every field it decides on and for every filter criterion of every query, including the queries made inside this QBit's own writes. So a thread that asked while holding another lock of this QBit could not be answered during a reveal, and if the reveal needed that lock next, both waited for ever. The access-log writer is such a thread. It holds the anomaly counters while it inserts a row; the insert counts earlier rows and writes an audit, both queries with criteria. A reveal inserts its own access-log row. reveal: runtime's monitor, then the anomaly counters writer: the anomaly counters, then the runtime's monitor Seen in a host on PostgreSQL: a person read a record with a masked field and revealed it at once; the writer's tick drained the read's log rows at the same moment. The request and the writer deadlocked (thread dump: the request in SystemWrites.insertOne under RevealService.reveal, the writer in SecuredDataRuntime.classificationRows under AuditAction.fetchIdFromName under its own insert), and every later request blocked in classificationRows. The same order existed between a reveal and the resolver's monitor, and the key source's. - The rule rows have a lock of their own (ruleLock), held only while they are answered or read. A read is a query made as the system and takes none of the QBit's other locks, so nothing that holds ruleLock waits for one. - The runtime's monitor is left to what it was for: one reveal or break-glass change at a time. Tests (SecuredDataLockOrderTest, on H2 in PostgreSQL mode with the audit tables): a thread is parked inside a reveal, and inside the start of a break-glass session, holding the runtime's monitor; the access-log writer must drain its queue and another thread must be told a classification and the active retention rules meanwhile, and then the parked operation must finish. Both tests fail without the fix (neither thread finishes). Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-14 03:40:00 -06:00

Author

SHA1

Message

Date

james.maesandClaude Fable 5.2

c2fde973a5

fix: a reveal and the access-log writer no longer wait for each other

maven / build (push) Successful in 2m0s

Details

build / maven (push) Successful in 2m0s

Details

A reveal, and the start, end and expiry of a break-glass session, hold the
runtime's monitor from their first check to their last write. Asking for a
classification (SecuredDataRuntime.classificationRows, and
activeRetentionRules) took the same monitor, and every thread asks: core
asks for every field it decides on and for every filter criterion of every
query, including the queries made inside this QBit's own writes.

So a thread that asked while holding another lock of this QBit could not be
answered during a reveal, and if the reveal needed that lock next, both
waited for ever. The access-log writer is such a thread. It holds the
anomaly counters while it inserts a row; the insert counts earlier rows and
writes an audit, both queries with criteria. A reveal inserts its own
access-log row.

    reveal:  runtime's monitor, then the anomaly counters
    writer:  the anomaly counters, then the runtime's monitor

Seen in a host on PostgreSQL: a person read a record with a masked field and
revealed it at once; the writer's tick drained the read's log rows at the
same moment. The request and the writer deadlocked (thread dump: the request
in SystemWrites.insertOne under RevealService.reveal, the writer in
SecuredDataRuntime.classificationRows under AuditAction.fetchIdFromName
under its own insert), and every later request blocked in
classificationRows. The same order existed between a reveal and the
resolver's monitor, and the key source's.

- The rule rows have a lock of their own (ruleLock), held only while they
  are answered or read. A read is a query made as the system and takes none
  of the QBit's other locks, so nothing that holds ruleLock waits for one.
- The runtime's monitor is left to what it was for: one reveal or
  break-glass change at a time.

Tests (SecuredDataLockOrderTest, on H2 in PostgreSQL mode with the audit
tables): a thread is parked inside a reveal, and inside the start of a
break-glass session, holding the runtime's monitor; the access-log writer
must drain its queue and another thread must be told a classification and
the active retention rules meanwhile, and then the parked operation must
finish. Both tests fail without the fix (neither thread finishes).

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

2026-11-14 03:40:00 -06:00

fix: a reveal and the access-log writer no longer wait for each other (release/0.1 port of #45) #46