First seen on master build 3088 (amd64 / test-ui-desktop, stage 1 step 27). The identical commit passed as 3087 on its branch, and builds 3066–3087 show no other occurrence of this step failing, so it is intermittent rather than a regression from that change.
Failure
✘ 52 [desktop] › 97-deactivate.spec.ts:25:1 › deactivate via settings then re-activate (28.1s)
Error: Timed out 10000ms waiting for expect(locator).toBeVisible()
Locator: getByRole('heading', { name: 'Applications' })
Expected: visible
Received: <element(s) not found>
Call log:
- waiting for getByRole('heading', { name: 'Applications' })
- waiting for "https://auth.buster-amd64.redirect/api/oidc/authorization?client_id=syncloud&code_challenge=…&consent_id=69c75a27-e240-4a0e-9333-e…" navigation to finish...
61 | await page.locator('#password-textfield').fill(devicePassword)
62 | await page.locator('#sign-in-button').click()
> 63 | await expect(page.getByRole('heading', { name: 'Applications' })).toBeVisible()
51 passed, 1 failed, 1 did not run (maxFailures: 1 stops the run).
Mechanism
web/e2e/specs/97-deactivate.spec.ts:63 asserts the post-login heading with the default 10s expect timeout, immediately after #sign-in-button. At that moment the browser is mid-flight through Authelia's OIDC authorization redirect chain.
The consent_id in the URL is not itself the problem — config/authelia/config.yml:818 sets consent_mode: 'implicit', so Authelia still mints a consent session and auto-grants it. The likely cause is simply that this navigation is slower than 10s here: the test has just re-activated the device, which regenerates Authelia's config and restarts it along with the backend and LDAP, so the first OIDC round-trip races those services warming up. This is the last and heaviest spec in the suite, which fits it being the one to trip.
Suggested fix
Don't race a fixed expect timeout against the redirect chain — wait for the navigation/loading state to settle before asserting the heading, in line with how the rest of the suite gates on the loading mask rather than asserting immediately after a click. Raising the timeout on this one assertion would mask it rather than fix it.
Note
The device journal and the Playwright trace/screenshots for this run are in the build artifacts under 3088-amd64/playwright/desktop/, but ci.syncloud.org:8081 was not reachable from outside the CI LAN when this was written, so the diagnosis above is from the step log only and the trace has not been read. Anyone on the LAN should confirm against journalctl.log and trace.zip before acting on it.
First seen on master build 3088 (
amd64 / test-ui-desktop, stage 1 step 27). The identical commit passed as 3087 on its branch, and builds 3066–3087 show no other occurrence of this step failing, so it is intermittent rather than a regression from that change.Failure
51 passed, 1 failed, 1 did not run (
maxFailures: 1stops the run).Mechanism
web/e2e/specs/97-deactivate.spec.ts:63asserts the post-login heading with the default 10s expect timeout, immediately after#sign-in-button. At that moment the browser is mid-flight through Authelia's OIDC authorization redirect chain.The
consent_idin the URL is not itself the problem —config/authelia/config.yml:818setsconsent_mode: 'implicit', so Authelia still mints a consent session and auto-grants it. The likely cause is simply that this navigation is slower than 10s here: the test has just re-activated the device, which regenerates Authelia's config and restarts it along with the backend and LDAP, so the first OIDC round-trip races those services warming up. This is the last and heaviest spec in the suite, which fits it being the one to trip.Suggested fix
Don't race a fixed expect timeout against the redirect chain — wait for the navigation/loading state to settle before asserting the heading, in line with how the rest of the suite gates on the loading mask rather than asserting immediately after a click. Raising the timeout on this one assertion would mask it rather than fix it.
Note
The device journal and the Playwright trace/screenshots for this run are in the build artifacts under
3088-amd64/playwright/desktop/, butci.syncloud.org:8081was not reachable from outside the CI LAN when this was written, so the diagnosis above is from the step log only and the trace has not been read. Anyone on the LAN should confirm againstjournalctl.logandtrace.zipbefore acting on it.