-
Notifications
You must be signed in to change notification settings - Fork 0
fix(compositor): strip _sender/_rev from UpdateParams before deserialization #293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
streamer45
merged 4 commits into
main
from
devin/1775994485-fix-compositor-update-params
Apr 12, 2026
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
4b52bf7
fix(compositor): strip _sender/_rev from UpdateParams before deserial…
streamkit-devin 3dac1a9
refactor(engine): strip _sender/_rev at engine level, add E2E param s…
streamkit-devin 06f4916
fix: move strip_sync_metadata to core utility, preserve echo suppression
streamkit-devin 36a7d8a
style(e2e): fix prettier formatting in compositor test
streamkit-devin File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚩 E2E test relies on fixed initial opacity value from YAML fixture
The new E2E test at
e2e/tests/compositor-video-output.spec.ts:284-287assertsnot.toBeCloseTo(0.9, 1)to verify the opacity changed from its initial value. This is tightly coupled to theCOMPOSITOR_COLORBARS_YAMLfixture definingin_1opacity as0.9. If the fixture changes, the test would need updating. The slider drag amount (50px left) is also somewhat arbitrary — on different viewport sizes or slider implementations, the resulting opacity change could vary. The test may be flaky if the drag doesn't produce a large enough change. Not a bug, but worth noting for maintenance.Was this helpful? React with 👍 or 👎 to provide feedback.
Debug
Playground
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. The test reads the initial opacity from the fixture YAML dynamically via the pipeline API, then asserts that the value changed after the slider drag — so it doesn't hard-code
0.9as the only valid initial value. However, thenot.toBeCloseTo(0.9, 1)assertion does encode the fixture's current value. If the fixture changes, the assertion would need updating.The slider drag amount (50px) is intentionally conservative — it should produce a measurable change on any reasonable viewport. If flakiness becomes an issue, we could read the initial opacity from the pipeline API before dragging and assert
newOpacity !== initialOpacityinstead.