record: warn while dropping, not just at close - #3718
Conversation
The protocol only restated Transport's subscribe signature to avoid an import; ModuleCoordinator.transports already hands back Transport[Any].
A full writer queue silently discarded messages until the run ended, so a lossy recording only announced itself after the data was already gone. Warn at most once every 10s while it is happening.
Greptile SummaryThis change makes recorder queue loss visible while a run is active and retains the close-time total. Focused execution found two P2 observability issues: simultaneous transport callbacks can produce duplicate warnings within one ten-second interval, and the first warning is suppressed when the first drop occurs during the first ten seconds of monotonic uptime. Confidence Score: 4/5Not merge-safe without addressing the two warning-observability issues. There are two independent verified P2 findings and no P0 or P1 findings; the required score for P2-only findings is 4. Files Needing Attention: dimos/memory/tap.py needs synchronization for the warning throttle and initialization that permits the first drop warning.
What T-Rex did
Reviews (1): Last reviewed commit: "record: warn while dropping, not just at..." | Re-trigger Greptile |
❌ 2 Tests Failed:
View the top 1 failed test(s) by shortest run time
View the full list of 1 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
Transport callbacks run on their own threads, so the unsynchronized check-and-set let concurrent drops emit several warnings inside one interval. Seeding the timestamp with 0.0 also compared against process uptime, swallowing the first warning during the first ten seconds of a run.
|
|
||
| logger = setup_logger() | ||
|
|
||
| DROP_WARNING_INTERVAL_S = 10.0 |
There was a problem hiding this comment.
no global vars that are not in global config has been repo convention
Warn >=10s while when writer queue is dropping messages