⚠️ 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.
Source
AI security-scan Finding 36 (severity: minor). Tracked in
SUBMISSIONS.mdas F36.Affected file:
massa-event-cache/src/event_cache.rsSummary
massa-event-cache/src/event_cache.rshandlesEventFilter.is_finalinconsistently between in-memory queued events and the persistent final-events cache. The confirmed issue is that queries usingis_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 aboutis_final = Some(false)returning finalized events on the user-facing path is not supported.Recommendation
Handle
EventFilter.is_finalconsistently across both the in-memory queue and the persistedfinal_events_cachepath. Ensure that queries withis_final = Some(true)remain valid after events are flushed, rather than being dropped becausefrom_event_filter()does not translate that field andEventCache::get_filtered_sc_output_events()rejects empty filter sets. At a minimum, finalized-event queries should either mapis_finalinto the persistent filtering logic or treatis_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.mdPart D.