mirror of
https://github.com/d4rken-org/capod.git
synced 2026-09-14 18:26:11 -04:00
darken
39a6c3c89f
A capture that shows no scan results cannot currently answer whether the scan was filtered. The configuration is decided once when the scan starts, which is usually long before the recording that is meant to diagnose it, so the line is re-emitted when a recording begins while the scan is already running. The re-emission drops against the value captured at the first emission instead of drop(1): launchIn subscribes asynchronously, so a StateFlow replays whatever is current at subscription time. A recording started in that gap would be swallowed as if it were the initial value, which is exactly the case the line exists for. filterPolicy is a parameter rather than something derived from the filter set, because the unfiltered mode is implemented as a single match-all filter. A count-based summary would report it as a filtered scan, inverting the answer. "Requested" and not "filtering"/"batching": adapter capability plus our own setting is what we asked the platform for, not proof that the controller offloaded anything.