Verification against Element stalls (user report): stale request timestamp + peer device-data race

thecrealm commented

2026-08-07 08:09:04 +02:00

Owner

Reported while running the #47 demo against Element: the SAS dialog sat at 'Preparing the emoji comparison…' forever. Two root causes found by driving Element Web's verification UI via selenium (new ElementVerificationEndToEndTest):

Our m.key.verification.request carried timestamp: 0 (stub) — receivers drop requests >10 min stale, so Element silently ignored katrix-initiated requests. Fixed: the machine's clock stamps the request.
Element's rust crypto silently drops verification traffic from a device it has not resolved yet (console: 'Could not retrieve the device data for the incoming verification request, ignoring it'). A verification started immediately after a fresh katrix login races Element's device-list catch-up in EITHER direction — that's the 'Preparing…' hang. No retry exists on either side; waiting a few seconds after login before verifying avoids it.

Also fixed en route: VerificationHandle.otherDeviceId now gets fixed by ready/start for wildcard requests (was permanently null). The e2e drives Element's toast → Start Verification → emoji compare → They match, asserts the same seven emoji on both sides and mutual Done + device trust. Follow-up for the race: a re-request affordance (SDK or demo UX) — tracked separately.

Reported while running the #47 demo against Element: the SAS dialog sat at 'Preparing the emoji comparison…' forever. Two root causes found by driving Element Web's verification UI via selenium (new ElementVerificationEndToEndTest): 1. Our m.key.verification.request carried `timestamp: 0` (stub) — receivers drop requests >10 min stale, so Element silently ignored katrix-initiated requests. Fixed: the machine's clock stamps the request. 2. Element's rust crypto silently drops verification traffic from a device it has not resolved yet (console: 'Could not retrieve the device data for the incoming verification request, ignoring it'). A verification started immediately after a fresh katrix login races Element's device-list catch-up in EITHER direction — that's the 'Preparing…' hang. No retry exists on either side; waiting a few seconds after login before verifying avoids it. Also fixed en route: VerificationHandle.otherDeviceId now gets fixed by ready/start for wildcard requests (was permanently null). The e2e drives Element's toast → Start Verification → emoji compare → They match, asserts the same seven emoji on both sides and mutual Done + device trust. Follow-up for the race: a re-request affordance (SDK or demo UX) — tracked separately.

thecrealm added the

M3

now

labels

2026-08-07 08:09:04 +02:00

thecrealm referenced this issue

2026-08-07 08:09:05 +02:00

Verification request retry: mitigate the peer device-data race (#58 follow-up) #59

thecrealm referenced this issue from a commit

2026-08-07 08:11:04 +02:00

SAS against Element: real request timestamp, device fixed on ready, driven-UI e2e

thecrealm closed this issue