updateRelationsBatch previously pre-sorted ops remove->modify->add, which
changed the final state whenever one tuple was touched by mixed kinds:
[add, remove] left the tuple present, [modify, add, modify] ended with
the middle value. Now ops apply strictly in the given order via the
dedup-aware _addRelationInternal (in-place last-write-wins) with upfront
validation, post-batch PLTC edge updates, and per-relation arbiter-level
cache invalidation.
batch-order-parity.test.js pins the contract with an in-order mirror
(modify-of-missing is a silent no-op).
Engine fixes:
- RelationUpdates.updateRelationsBatch: invalidate arbiter-level caches
(rule result cache, ChainRule caches, direct-check cache) per affected
relation — batch updates bypassed Arbiter.addRelation and served stale
decisions after batch modify/swap with warm caches
- updateRelationsBatchTransactional rollback: new Map(Set) crashed with
'Iterator value is not an entry object' — fixed to new Set
- RelationalComparatorRule: value extraction (direct-list and cached
direct paths) now gates on valueManager._isValueExpired — TTL-expired
values no longer feed comparator decisions
Campaigns:
- value-freshness-parity.test.js: batch modify/swap/tx rollback freshness
with comparator mirror (batch MODIFY of a missing relation is a silent
no-op — pinned)
- ttl-expiry-parity.test.js: injected-clock TTL expiry through the
comparator path (exact parity with caching off; bounded staleness with
caching on), faithful changed_last_at mirror semantics
John Dvorak