Skip to content

Decide load_related membership against final state#6548

Open
incrypto32 wants to merge 2 commits intomasterfrom
krishna/fix-load-related-membership
Open

Decide load_related membership against final state#6548
incrypto32 wants to merge 2 commits intomasterfrom
krishna/fix-load-related-membership

Conversation

@incrypto32
Copy link
Copy Markdown
Member

EntityCache::load_related decided derived field membership against intermediate
cache layers (self.updates and self.handler_updates separately), so same-block
changes to an entity's parent reference could leave it in the wrong derived
collection or omit it from one it had moved into.

Rewrite load_related to:

  • Build a candidate set from the store baseline plus any in-block writes whose
    key is compatible with the query (entity_type + causality_region).
  • Resolve each candidate's final state by layering store → updates →
    handler_updates the same way EntityCache::get() does.
  • Apply query.matches exactly once against the final state.

Closes three previously-distinct failure modes: entities wrongly retained after
moving out of a collection, wrongly retained after a cross-handler revert, and
wrongly omitted after being moved in across handlers.

Scenarios covered by the new tests

  • Single-handler reassignment removes entity from old parent's collection
  • Cross-handler reassign-then-revert leaves intermediate parent's collection unchanged
  • Cross-handler touch-then-reassign adds entity to new parent's collection
  • Removal via self.updates drops entity from collection
  • Removal via self.handler_updates drops entity from collection
  • Fresh in-handler creation appears in new parent's collection

All six tests are in store/test-store/tests/graph/entity_cache.rs.

EntityCache::load_related decided derived field membership against
intermediate cache layers, so same-block changes to an entity's parent
reference could leave it in the wrong derived collection (or omit it
from one it had moved into). Rewrite load_related to build a candidate
set from the store baseline plus in-block writes, resolve each
candidate's final state by layering store -> updates -> handler_updates
the same way get() does, and apply query.matches exactly once against
the final state.
…changes

Cover six scenarios where an entity's parent reference or presence
changes within a block: a single-handler reassignment that should
remove the entity from the old parent's derived collection, a
cross-handler reassign-then-revert that should leave the intermediate
parent's collection unchanged, a cross-handler touch-then-reassign
that should add the entity to the new parent's collection, a removal
landing in updates and a removal landing in handler_updates that both
drop the entity from its collection, and a fresh in-handler creation
that should appear in the new parent's collection.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant