Repository navigation
fix(media): harden cache publication, webcam reconnect and queue peaks - #481
Merged
Merged
Conversation
Exoridus
marked this pull request as ready for review
October 24, 2026 23:15
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the four follow-up findings from the final v0.11 review.
Changes
Media cache publication no longer needs a rollback. Both publish paths (direct and streamed) used to rename the entry into place, then evict to budget, and on failure delete the just-published file. If that delete failed (for example because a scanner or another process opened the new file),
Publish()reported failure while the entry stayed indexed and readable. Eviction now runs before the rename, sized for the incoming entry and crediting the entry it replaces. A rejected publication never becomes visible. Replacing an entry in a full cache evicts nothing.Webcam reconnect delay is interruptible. Both 500 ms reconnect waits now wait on the stop token, so
Stop()no longer waits out a pending delay.Failed source events no longer replace a pending read result. Per the Media Foundation documentation,
IMFSourceReaderCallback::OnEventonly forwards MEBuffering*, MEConnect*, MEExtendedType and MESource*Changed. Fatal reader errors arrive throughOnReadSamplewithMF_SOURCE_READERF_ERROR. The callback kept the failed-event-to-reconnect behaviour as a fallback, but stored it in the same single slot as read results, so a failed event could overwrite a sample that had not been consumed yet. It now has its own slot and is delivered after the pending read result. Each reader loss logswebcam.reader_lostwith HRESULT, flags and whether it came from a read or an event, so the physical unplug test can show which path real devices use.Mux queue peaks are exact.
peakDepthandpeakRetainedByteswere maxima of values sampled at the mux consumer cadence and could miss short spikes.MuxQueuenow tracks both high-water marks under its own lock on every push and resets them per recording. The aggregator publishes those values.Verification
cargo exo-dev test --filter "engine\.test_mux_queue|engine\.test_pipeline_diagnostics|engine\.test_media_caches|webcam\.|observability\.observability_tests|quick_media_cache\.", 10/10 passed.Limits