-
Notifications
You must be signed in to change notification settings - Fork 70
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
[31.2-rc.1] Partial good success with stalled AOs but recovery flow shattered (w.i.p.) #771
Comments
Second take with 3.31.2-rc.1 (development mode), same situation: in comparison https://clipchamp.com/watch/wF7rNH96H43 a) [bad] multiple 'meta reloaded' events ==>> recovery impossible, manual entry of old AOs neede |
Suggestions what's desired for UX a bit later, apologies. |
fixed on 31.2 |
Highlight on how 2-rc.1 handles the stalled AOs.
Video from the previous 3.31.1 (Electron build) to show the full cycle: https://clipchamp.com/watch/oIQixSaErLN
observe
a) [fixed already] AOs stopped at 'meta realoaded' remain in view and the AO counter also indicates wrongly
b) [now bridged] AOs cannot be stopped because they are not running (red warning label pop-up), logged
c) [confusing but not wrong] info modal shows before closing app to warn about cancelling AOs deemed alive
d) [no comment] the orphaned atomics are still valid-active after restart (down time shorter than DMS threshold of 1 minute)
e) [nice + successful] HF attempts a respawn of the AOs. In process, the leftover atomics are wiped away first and then the AOs come alive placing them again.
==>> recovery completed.
The text was updated successfully, but these errors were encountered: