Skip to content

[F36] Flushed event-cache queries ignore finality-only filters #5082

Description

@damip

⚠️ Warning — This finding was routed to an issue rather than a PR because it changes a JSON-RPC / gRPC interface or its observable behavior (accepted inputs, returned results, error-vs-silent-drop, or transport/security posture). Per maintainer guidance this is treated as breaking, because it can break external tooling and clients; the gRPC proto types are additionally auto-generated (external massa_proto_rs) and must not be hand-edited. It needs an interface-compatibility decision, not a drop-in PR.


Source

AI security-scan Finding 36 (severity: minor). Tracked in SUBMISSIONS.md as F36.

Affected file: massa-event-cache/src/event_cache.rs

Summary

massa-event-cache/src/event_cache.rs handles EventFilter.is_final inconsistently between in-memory queued events and the persistent final-events cache. The confirmed issue is that queries using is_final = Some(true) can return matching events before the async flush, then return no persisted matches after flush because the RocksDB-backed path drops that filter. The original claim about is_final = Some(false) returning finalized events on the user-facing path is not supported.

Recommendation

Handle EventFilter.is_final consistently across both the in-memory queue and the persisted final_events_cache path. Ensure that queries with is_final = Some(true) remain valid after events are flushed, rather than being dropped because from_event_filter() does not translate that field and EventCache::get_filtered_sc_output_events() rejects empty filter sets. At a minimum, finalized-event queries should either map is_final into the persistent filtering logic or treat is_final = Some(true) as an explicit request to search finalized entries even when no other filter fields are provided. Add regression tests covering the full lifecycle of an event before and after flush to confirm identical results for equivalent final-only queries across both storage layers.

Why P0 / breaking

The fix changes API / gRPC behavior (event-query results (get_filtered_sc_output_event)). Per maintainer guidance, API/gRPC interface or observable-behavior changes are treated as breaking (they can break external tooling), so this is filed as an issue for design/versioning discussion rather than a direct PR. Note: the gRPC proto types are auto-generated and must not be hand-edited. See SUBMISSIONS.md Part D.

Metadata

Metadata

Assignees

Labels

P0Highest prioritybugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions