You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Avoid mutating caller queries in AssetsFacade #3478
AssetsFacade.getResults(AssetQuery) mutates the caller's query when applying the engine's realm and asset-path restrictions. Only select is restored after execution. A query reused by another engine, or by another caller, can therefore retain restrictions from an earlier execution.
For example, executing a query through an asset-scoped engine adds a path restriction. Reusing that query through a realm-scoped or global engine can retain the previous asset restriction.
Related to #2675 (Rules service facade scoping). This is the same query-isolation concern addressed in the users facade. It is separate from preserving caller-supplied path filters and from the batch-dispatch bug in #3476.
Expected behavior
Apply execution-specific restrictions to an independent query copy, leaving the caller's query and nested mutable values unchanged. Each execution must use the caller's current filters and its own engine scope, without retaining restrictions from earlier executions.
Acceptance Criteria
Add failing regression tests before implementing the fix.
Verify that global, realm and asset-scoped executions leave caller-owned query options and nested predicates unchanged.
Reuse one query across engines and verify that earlier realm/path restrictions do not carry over.
Verify that subsequent caller edits do not change a previously submitted query.
Preserve null versus empty filters when copying; an empty selection must not become an unrestricted query.
Keep the existing engine access boundaries enforced.
Account for mutations made by the asset storage query implementation as well as by the facade. Use a copy mechanism that preserves query semantics, rather than a JSON round-trip that may omit empty values.
Implement in a dedicated PR. Changing how caller path filters are combined with engine scope belongs to a separate issue and PR.
Activity