mirror of
https://github.com/Monkopedia/rouse-context.git
synced 2026-10-19 10:33:18 +00:00
8d57d715ab
* Fix #394: ColdStartEndToEndTest uses cmd activity stop-app Three primitives were tried, only one worked: - `am force-stop` (original): puts app into stopped state which blocks FCM delivery until manual user relaunch. Relay times out waiting for wake. Not reachable from any real user scenario. - `am kill`: refuses to kill foreground-service holders (TunnelForegroundService qualifies whenever the tunnel is connecting/connected), so it's a no-op in the common test scenario. - `cmd activity stop-app`: kills the process including the fg service, but leaves the app in the normal non-stopped state so FCM still wakes it. Closest simulation of OOM kill / swipe-from-Recents. Also batches the pidof death-poll into a single SSH-to-remote-host shell invocation so the 10s deadline isn't eaten by per-call SSH round-trip overhead (~200ms each, ~13 polls max inside the budget before). Verified against the Pixel 6 Pro: Cold-start-via-FCM latency: 3297ms (budget 20000ms) Warm-start latency: 238ms (budget 3000ms) * Fix #394 (follow-up): Drop post-kill buffer before pidof check TunnelForegroundService is START_STICKY, so Android will auto-restart the process a second or two after `stop-app` kills it. The 2s post-death buffer was long enough to catch the restarted process, then the test's final pidof assertion failed with "Process still running after stop-app". Immediate hit-the-MCP-endpoint after waitForProcessDeath returns: the request either hits a still-dead device (triggering the intended FCM cold-start path) or — if Android's auto-restart beat us to it — tests the same cold-connect path via whichever process now holds the tunnel. Either is a valid exercise of the cold-connect code. The prior setup turned a genuinely working flow into a deterministic test failure. * Fix #394 (follow-up 2): Drop pidof death check + bump latency budget to 30s Two more findings from reproducing the failure under the full loop: 1. `cmd activity stop-app` kills the process but Android's WorkManager SystemJobService reschedules pending jobs, which forces a process restart within ~1s. Asserting "process is dead" is therefore a flake-by-design. This matches production: a real OOM-killed device would also bounce back up via WorkManager immediately. What matters is end-to-end latency regardless of which process serves the request, so the pidof-death assertion is removed. 2. Cold-start latency is higher than the old 20s budget when the tunnel hasn't yet fully established on a fresh-onboarded device (observed ~23s end-to-end in that state). Subsequent kill/restart cycles drop back to ~3s. The 20s budget was set against the warm-return case; a fresh-onboard cold-start can exceed it on real hardware. Bump to 30s to match the first-time-ever budget and keep the test useful. If/when first-cold latency becomes an optimization target, tightening the budget is a visible regression gate. |
||
|---|---|---|
| .. | ||
| src/test/kotlin/com/rousecontext/e2e | ||
| build.gradle.kts | ||