Levandor

FKITDEV-8931 — silent socket re-auth instead of page reload (MKB DÁP)

7 min read

vuer_css-only fix for MKB: backgrounding the mobile browser drops the socket, and the old code answered a reconnect with window.location.reload(). DÁP (Digitális Állampolgárság) login requires backgrounding — you must switch to the DÁP app — so the reload fired on every DÁP login and destroyed it. The fix re-authenticates the existing socket silently instead, but only for socketLabel default.layout, and only if the socket comes back before a randomized 10–60s countdown expires — see The fix does not stop the reload for longer outages.

For Agents

  • Ticket: YouTrack FKITDEV-8931 — “MKB - prodvideobankdap.mbhbank.hu SNAT teszt”. Owner vencelvarga, approved by chrismakaay.
  • Scope: vuer_css only — there is no vuer_oss side.
  • PR #3153 (fix/FKITDEV-8931-websocket-reconnect-fix @ d53612780207) — open against devel, approved, 7/7 green, mergeable.
  • The one fact that changes how you test it: the silent re-auth fires only for default.layout. kiosk.layout and videochat still hard-reload — by design, not a regression. See Scope — only default.layout.
  • The fix is narrower than the ticket implies. It cancels a pre-existing reload countdown; it does not remove it. Outlast a randomized 10–60s window and the page still reloads — The fix does not stop the reload for longer outages. Open question for vencelvarga.
  • Do not test against a 30s boundary. connectionStateRecovery never engages on this deployment (socket.recovered === false on every reconnect). See Reconnect timing — measured, not read off config.
  • Currently deployed on fk-dev; deploy mechanics in fk-dev-partner-branch-deploy-runbook.

Browser-verified 2026-08-18 — the short-drop case works

On mbh-services under default.layout, a ~1.4s drop reconnected with no reload: an in-memory marker survived, a sessionStorage load counter stayed at 1, the console logged socket disconnected then [socket] re-authenticated after reconnect, and both snackbars stayed hidden. That is the ticket’s core claim, confirmed.

The same test round corrected three things this note previously asserted from config — the 30s boundary, transports, and reconnectionAttempts — and surfaced a limitation the ticket does not cover. Details in Reconnect timing — measured, not read off config and The fix does not stop the reload for longer outages.

Symptom

  • Mobile browser is backgrounded → the socket drops.
  • On foreground, the client called window.location.reload().
  • DÁP login mandates backgrounding (the user has to switch to the DÁP app to authenticate), so the reload was not an edge case — it fired on the normal happy path and broke the login every time.

Branches

BranchHeadRole
fix/FKITDEV-8931-websocket-reconnect-fixd53612780207PR #3153 against devel — approved, 7/7 green, mergeable
fix/FKITDEV-8931-socket-test3f32334ae (created 2026-08-18)customization/mkb-instant + one commit; byte-identical patch to the above. The deploy/test branch.
fix/FKITDEV-8931-websocket-auth-reconnect—abandoned first attempt

The patch — 2 files, +38 / −4

client/features/auth.js gains

SILENT_REAUTH_LABELS = ['default.layout']

A matching label calls auth(socketLabel) and logs [socket] re-authenticated after reconnect, falling back to the reload only if re-auth fails. Every other label keeps the hard reload unchanged.

client/ui/regions/snackbar-container/snackbar-container.js captures the 2s disconnect timer as this.disconnectTimeout and adds a connection.on('connect') handler → onConnectionRestored(), which clears disconnectTimeout and reloadCountdownInterval, then hides both disconnect snackbars.

Scope — only default.layout

Testing on a kiosk page shows a reload that looks like a failed fix, and is out of scope

The silent re-auth is gated on socketLabel:

LayoutsocketLabelBehaviour
default.layout.ui.js:22'default.layout'silent re-auth ✅
kiosk.layout.ui.js:43'kiosk.layout'still hard-reloads
videochatits own labelstill hard-reloads

customization/mkb-instant is heavily kiosk-based, so the obvious pages to click on are exactly the ones the fix does not cover.

Correct test target: https://css-fk-dev.taild4189d.ts.net/ lands on mbh-services (“MBH Bank - Szolgáltatások oldal”), which extends default.layout and is the non-kiosk DÁP path.

Reconnect timing — measured, not read off config

Values below are the live page’s data-socketioSettings, which beat the dev.json reading. An earlier revision of this note took three of them from config and got them wrong.

SettingActual valueWhy it matters
transports["websocket","polling"]polling fallback IS available. (Earlier revision said websocket-only — wrong.)
reconnectionAttempts20(Earlier revision said 5, with a “then it gives up and the fix never runs” caveat that was therefore overstated.)
connectionStateRecovery.maxDisconnectionDuration30000Configured but inert — do not test against it. See below.
css pingInterval / pingTimeout2000 / 30000
oss pingTimeout10000

connectionStateRecovery never engages on this deployment — the 30s cliff is not the boundary

socket.recovered was false on every reconnect, including a 1.4s one, and every reconnect produced a fresh socket id. Recovery is configured but does not activate here.

Do not tell a tester to probe either side of 30s. It teaches the wrong model. The boundary that actually governs the observable behaviour is the reload countdown below.

The fix does not stop the reload for longer outages

Outlast a randomized 10–60s countdown and the page still hard-reloads — the DÁP flow still breaks

Observed 2026-08-18: with a genuine 40s server outage (supervisorctl stop vuer_css), the page hard-reloaded — 4× against a 502 — before the server came back.

The cause is pre-existing and untouched by this patch. onConnectionDisconnected() fires 2s after disconnect and starts a 1s-interval countdown that ends in window.location.reload(). The 8931 fix only cancels that countdown if connect arrives first. It never removes or extends it.

The countdown length is randomized per page load. client/ui/regions/snackbar-container/snackbar-container.twig:6 → hideDelay: 10 + random(50) ⇒ 10–60 seconds (sampled live: 19, 23, 43, 54, 56, 57). Effective tolerance is therefore ≈12–62s of continuous disconnection, different on every load.

What this means for what the ticket delivers: for the DÁP flow the fix removes the instant reload-on-return, but a user who spends longer than a random 10–60s inside the DÁP app still gets the page reloaded and the flow still breaks. Because the threshold is random, it will reproduce intermittently — precisely the profile of a bug that gets closed as “works for me”.

Open question for vencelvarga

Should the reload countdown be suppressed or extended for SILENT_REAUTH_LABELS pages, rather than merely cancelled when a reconnect happens to arrive in time? Cancelling on reconnect only covers outages shorter than the random countdown; the DÁP round-trip is not bounded by that.

Do NOT cherry-pick the FKITDEV-9199 kebab fix onto this branch

cda6c80b97 (PR #3146) is not an ancestor, and adding it here would break the branch

This branch is internally consistent under the older attribute convention: the twigs emit data-socketToken, auth.js reads it through a case-insensitive getAttribute, and the snackbar reads dataset.sockettoken.

The FKITDEV-9199 fix kebab-cases the twigs to data-socket-token and switches the readers to dataset.socketToken. Bringing over the kebab twigs without the matching readers leaves nothing able to resolve the token.

This is the same trap that made fix/FKITDEV-9194-socket-token-attribute-read a superseded branch that would re-break the bug if merged on top — see FKITDEV-9194.

Deployment verified

The bundle as served over HTTPS — not the file on disk — was confirmed to carry the change:

curl -sk https://css-fk-dev.taild4189d.ts.net/js/default/default.layout.js
# HTTP 200, 623 KB
#   SILENT_REAUTH_LABELS = ["default.layout"]
#   onConnectionRestored  ×2

Deployed 2026-08-18 alongside vuer_oss customization/mkb-instant @ c7ceaac2da against DB vuer_oss_mkb_instant. Full deploy procedure and traps: fk-dev-partner-branch-deploy-runbook.

Test method

Playwright against mbh-services; drop the socket with socketio.io.engine.close(); detect a reload with an in-memory marker plus a sessionStorage load counter (the counter distinguishes “page survived” from “page reloaded and re-ran your setup”). Longer outages were produced with supervisorctl stop vuer_css rather than a client-side close, so the server is genuinely gone.

Do not reconnect with socket.connect() after disabling reconnection — the silent re-auth will not run

Calling socket.connect() manually does not fire socket.io’s reconnect event, so auth(socketLabel) never executes. You end up connected but unauthenticated while the snackbar still clears, which looks like a pass.

This is a test artifact, not a production path — but any application code that reconnects manually would hit the same gap.

Graph View

Backlinks