Observation
During the local v1.2.0 test drive of main commit ab15900, screen restoration remained correct but was intermittently slow. The installed screen and lifecycle services stayed active with zero restarts.
From the screen-service journal beginning 2026-08-24 07:48 EEST:
- 25 screen-restore requests
- 17 completed through direct unblank
- 8 entered the bounded fallback path and still completed successfully
- every restore retired the ownership marker; no failed final outcome was observed
Fallback timings in milliseconds:
- 6228, 6289, 6336, 6372, 6414, 8075
- 9303, 9415
Six cases began with native registration transport failure because the webOS connection closed before registration response request_0 arrived. Two cases began with an interrupted websocket handshake; independent verification found Screen Off, input selection was acknowledged without making the screen visible, and the adapter-neutral recovery unblank plus input retry completed successfully.
Two screen-blank operations also saw an interrupted handshake while querying input and successfully used the existing power-off fallback.
User impact
The visible reaction can take roughly 6 to 9 seconds instead of being immediate. Correctness and recovery are intact, so this is explicitly not considered release-blocking for v1.2.0.
Investigation goals
- determine why native websocket setup or stored-token registration is intermittently interrupted
- distinguish TV-side connection behavior from client session-lifecycle behavior
- reduce avoidable setup and fallback delay while preserving bounded execution
- retain adapter-owned postcondition verification and the no-ambiguous-write-replay rule
- use the existing failure-context snapshots to compare behavior before and after any change
Environment
- platform: lg_webos
- tested TV behavior model: webOSTV 23 / firmware 23.25.55
- build: 1.2.0-dev at ab15900
- observation window began: 2026-08-24 07:48 EEST
Observation
During the local v1.2.0 test drive of main commit ab15900, screen restoration remained correct but was intermittently slow. The installed screen and lifecycle services stayed active with zero restarts.
From the screen-service journal beginning 2026-08-24 07:48 EEST:
Fallback timings in milliseconds:
Six cases began with native registration transport failure because the webOS connection closed before registration response request_0 arrived. Two cases began with an interrupted websocket handshake; independent verification found Screen Off, input selection was acknowledged without making the screen visible, and the adapter-neutral recovery unblank plus input retry completed successfully.
Two screen-blank operations also saw an interrupted handshake while querying input and successfully used the existing power-off fallback.
User impact
The visible reaction can take roughly 6 to 9 seconds instead of being immediate. Correctness and recovery are intact, so this is explicitly not considered release-blocking for v1.2.0.
Investigation goals
Environment