Element verification e2e: try dropping the 15s device-list warmup in favor of the D37 re-request #72
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
ElementVerificationEndToEndTest sleeps 15s before requesting verification so Element's device-list catch-up wins the #58 race. With D37 (one-shot re-request, #59) the SDK now mitigates that race itself — the sleep may be removable, making the e2e exercise the mitigation in its real racy scenario. CI experiment: remove the delay, keep reRequestAfter at the 10s default, watch a few runs for toast-mid-click interactions (the reason the e2e currently pins reRequestAfter = 60s). Revert if flaky.
Experiment live as of
bd4cbef: warmup removed, default 10s reRequestAfter. The first CI run to contain it is the run forbd4cbef— verdict needs the Element verification e2e green across a few consecutive runs with no m.user cancels mid-toast. Baseline for comparison: run 192 (2a934cf) was green with the warmup + 60s window.Run 1 verdict: green. Run 194 (
bd4cbef) — engine jvmTest incl. the Element verification e2e passed with no warmup and the default 10s re-request; no DIAG output, no mid-toast cancel. Two-ish more green runs on future pushes and this can close.Local data point alongside the #68 push (
5c20643): a full-suite local run flaked at ElementVerificationEndToEndTest.sasVerificationWithEstablishedOlmSessions — done() timeout at 120s, i.e. Element's done never arrived after successful emoji confirm. NOT the experiment leg: the katrix-initiated test (the onebd4cbefchanged) passed in that same run (59.9s incl. any re-request), and all three tests pass in isolation (2m35s, twice). Looks like colima load contention, same family as #73. No m.user cancel observed, so it doesn't count against the experiment — but worth remembering if CI shows the same shape. The5c20643CI run is verdict run 2.Run 2 verdict: green. Run 200 (
3cc8767, includes the #68/#42 trees) — phase-2 engine jvmTest passed in 6m53s with no DIAG output and no mid-toast cancel; the experiment leg ran with no warmup and the default 10s re-request. (Runs 196/197 were auto-cancelled by a follow-up push; run 198 died in phase 1 on the unrelated #74 SQLITE_BUSY flake before the verification e2e ran, so it carries no verdict data.) One more green run and this closes.Run 3 verdict: green — experiment concludes, warmup stays removed. Run 202 (
3cc8767, manual dispatch added for exactly this purpose): phase-2 engine jvmTest incl. the Element verification e2e passed (BUILD SUCCESSFUL in 7m9s), zero DIAG output, zero m.user cancels in the full job log. Three consecutive green runs (194, 200, 202) with no warmup and the default 10s reRequestAfter: the D37 one-shot re-request heals the #58 device-list race on its own, and the e2e now exercises that mitigation in its real racy scenario.bd4cbefstands; nothing to revert.