// Login state machine — consumes LoginEvent (one per inbound m.notice from // the bridge bot) and emits a typed UI state. The widget renders forms and // the status pill from this state, never from raw reply strings. // // Multi-reply collapse is implemented here: when the bot emits two notices // for a single transition (2fa instructions + password re-prompt; invalid // code + code re-prompt; wrong password + password re-prompt), the second // notice arrives as `awaiting_password` / `awaiting_code` and the reducer // recognises it as a no-op against the state already set by the first. // // State-gating policy: prompt events (`awaiting_*`) and step-error events // (`twofa_required`, `invalid_code`, `wrong_password`, `submit_failed`, // `invalid_value`) are valid only from a *plausible previous state*. // Without these gates, late prompt-events can resurrect cancelled or // completed flows — e.g. user submits phone, clicks Cancel, bot's pipeline // already started a Telegram API call and emits `Please enter your Code…` // AFTER the cancel reply lands. The reducer here ignores that late prompt // because we're already `disconnected`. import type { LoginEvent, ListedLogin } from './bridge-protocol/types'; export type LoginErrorFlag = | { kind: 'invalid_code' } | { kind: 'wrong_password' } | { kind: 'submit_failed'; reason?: string } | { kind: 'invalid_value'; reason?: string } | { kind: 'prepare_failed'; reason?: string } | { kind: 'start_failed'; reason?: string } | { kind: 'login_in_progress' } | { kind: 'max_logins'; limit?: number } | { kind: 'unknown_command' }; // A live form is open and waiting for user input. M12.5's hydrate path // can ONLY ever produce one of these — every other final state falls // through to live `list-logins` reconciliation. export type PendingFormState = | { kind: 'awaiting_phone'; lastError?: LoginErrorFlag } | { kind: 'awaiting_code'; lastError?: LoginErrorFlag } | { kind: 'awaiting_password'; lastError?: LoginErrorFlag }; export type LoginState = // Pre-handshake / pre-list-logins. Status pill: --faint. | { kind: 'unknown' } // list-logins came back empty, OR logout completed. Status pill: --rose // (disconnected = needs action). | { kind: 'disconnected'; lastError?: LoginErrorFlag } // After "Войти по номеру" — waiting for `Please enter your Phone number`. // After phone submit — waiting for code prompt OR error reply. // After code submit (when the bot decided 2fa is needed) — waiting for // password submission. lastError carries `wrong_password` after a failed // password retry. Status pill: --amber for all three. | PendingFormState // logout in flight — waiting for `Logged out`. Status pill: --amber. | { kind: 'logging_out'; loginId: string } // Live session. login carries the parsed handle/numericId from // `Successfully logged in as ()`, plus the loginId we need // for `!tg logout `. Status pill: --green. | { kind: 'connected'; handle: string; numericId?: string; loginId?: string; }; // Outbound user actions the App dispatches. Form-submit actions clear any // pending lastError; structural transitions (start_login, request_logout, // cancel_pending) optimistically advance state — the App rolls them back // on send-failure where the bot would otherwise leave us stuck. export type LoginAction = | { kind: 'event'; event: LoginEvent } | { kind: 'start_login' } // user clicked "Войти по номеру" | { kind: 'submit_phone' } // user clicked submit on phone form | { kind: 'submit_code' } // user clicked submit on code form | { kind: 'submit_password' } // user clicked submit on 2fa form | { kind: 'request_logout'; loginId: string } // user clicked "Выйти" | { kind: 'cancel_pending' } // user clicked "Отмена" | { kind: 'hydrate'; state: PendingFormState }; // M12.5 timeline-resume seed export const initialLoginState: LoginState = { kind: 'unknown' }; const pickConnected = (logins: ListedLogin[]): LoginState => { if (logins.length === 0) return { kind: 'disconnected' }; // M12 ships single-account UI (max_logins=1 in the operator's bridge // config). If a future deployment runs with multiple logins, we still // surface the first one — multi-account UI is a follow-up phase. The // loginId here is what the widget will pass to `!tg logout `. const [first] = logins; return { kind: 'connected', handle: first.name, loginId: first.id, }; }; // Whether a `awaiting_code` prompt is plausible from the current state. // Plausible: just submitted phone (still in awaiting_phone), or the bot // is re-prompting after invalid_code (we're already in awaiting_code). const acceptsCodePrompt = (s: LoginState): boolean => s.kind === 'awaiting_phone' || s.kind === 'awaiting_code'; // Whether a `awaiting_password` re-prompt is plausible. The TRANSITION to // password (from awaiting_code) is driven by `twofa_required`, not by the // re-prompt itself; the re-prompt only confirms we're still waiting. const acceptsPasswordReprompt = (s: LoginState): boolean => s.kind === 'awaiting_password'; // Whether `twofa_required` is plausible. It can only follow a code submit. const acceptsTwofa = (s: LoginState): boolean => s.kind === 'awaiting_code'; // Whether step-scoped errors (invalid_code, wrong_password, invalid_value, // submit_failed) should land on a form. Form-scoped errors are dropped // when no form is open. Shared by the live reducer and the hydrate path — // the predicate body and the resulting type are identical. const isFormState = (s: LoginState): s is PendingFormState => s.kind === 'awaiting_phone' || s.kind === 'awaiting_code' || s.kind === 'awaiting_password'; export const loginReducer = (state: LoginState, action: LoginAction): LoginState => { if (action.kind === 'hydrate') { // M12.5: hydrate is a one-shot mount-time seed. It races against live // events that may arrive between `on('ready')` firing and our async // readTimeline resolving — bridgev2 / cinny's BotWidgetEmbed can push // a new bot reply via send_event during that window. If a live event // has already moved us off `unknown`, the live truth wins; the cached // timeline snapshot is by definition older than what the live event // just told us. Without this gate, a stale `awaiting_code` from the // pre-reload session could overwrite a legitimate `connected` that // arrived during the await. if (state.kind !== 'unknown') return state; return action.state; } if (action.kind === 'start_login') { return { kind: 'awaiting_phone' }; } if (action.kind === 'submit_phone') { // Stay on the phone form until the bot confirms with `awaiting_code`. // Optimistic transition to awaiting_code would mis-surface a phone-side // error (e.g. `submit_failed: PHONE_NUMBER_BANNED`) on the code form. if (state.kind === 'awaiting_phone') { return { kind: 'awaiting_phone', lastError: undefined }; } return state; } if (action.kind === 'submit_code') { if (state.kind === 'awaiting_code') { return { kind: 'awaiting_code', lastError: undefined }; } return state; } if (action.kind === 'submit_password') { if (state.kind === 'awaiting_password') { return { kind: 'awaiting_password', lastError: undefined }; } return state; } if (action.kind === 'request_logout') { return { kind: 'logging_out', loginId: action.loginId }; } if (action.kind === 'cancel_pending') { // Optimistic: drop straight back to disconnected. The bot's reply will // be `Login cancelled.` (cancel_ok) or `No ongoing command.` // (cancel_no_op) — either way the user has signalled they want out. return { kind: 'disconnected' }; } const event = action.event; switch (event.kind) { case 'logins_listed': // list-logins is the source of truth — accept from any state. return pickConnected(event.logins); case 'not_logged_in': // Same gating idea as the prompt events: a late-arriving // `You're not logged in` from a list-logins fired before the user // started a fresh login flow would otherwise wipe an active form. // Accept only from states where flipping to disconnected is correct. if ( state.kind === 'unknown' || state.kind === 'disconnected' || state.kind === 'logging_out' ) { return { kind: 'disconnected' }; } return state; case 'awaiting_phone': // Bot's "Please enter your Phone number". Only meaningful when we // initiated phone-login (state already awaiting_phone). From any // other state — including the late-arriving prompt after a cancel // — drop it on the floor. return state.kind === 'awaiting_phone' ? state : state; case 'awaiting_code': // Plausible after submitting phone, or as a re-prompt within the // code form. Late arrival after cancel/connected/logging_out is // ignored to avoid resurrecting dead flows. if (!acceptsCodePrompt(state)) return state; if (state.kind === 'awaiting_phone') return { kind: 'awaiting_code' }; return state; case 'awaiting_password': // Pure re-prompt arm. The TRANSITION to awaiting_password is driven // by `twofa_required` (or `wrong_password`), not by this event. // Ignored when we're not already on the password form. if (!acceptsPasswordReprompt(state)) return state; return state; case 'twofa_required': // First of the two-reply 2fa transition. Only valid after a code // submit. Ignored from disconnected/connected/etc. if (!acceptsTwofa(state)) return state; return { kind: 'awaiting_password' }; case 'invalid_code': if (state.kind !== 'awaiting_code') return state; return { kind: 'awaiting_code', lastError: { kind: 'invalid_code' } }; case 'wrong_password': if (state.kind !== 'awaiting_password') return state; return { kind: 'awaiting_password', lastError: { kind: 'wrong_password' } }; case 'login_success': // Always honour — even if state somehow drifted, the bridge says we're in. return { kind: 'connected', handle: event.handle, numericId: event.numericId, // loginId is unknown until the post-success list-logins fires // (App.tsx). Until then, logout is gated. }; case 'logout_ok': // Late `Logged out` from a previous session can arrive while the user // is mid-new-flow (e.g. they cancelled, started login again, and the // old logout's reply finally lands). Only honour from logging_out; // other states keep their flow. if (state.kind !== 'logging_out') return state; return { kind: 'disconnected' }; case 'cancel_ok': case 'cancel_no_op': // The App's `cancel_pending` action ALWAYS optimistically lands us // in `disconnected` before the bot's confirmation arrives. So a // legitimate cancel-reply naturally finds state === 'disconnected' // — accepting it then is a safe idempotent no-op transition. // // From ANY other state (awaiting_*, connected, logging_out, // unknown), the cancel reply is stale: the user has either started // a new flow (state already moved on) or never cancelled in this // widget session at all. Letting it through would clobber an // active flow — exactly the race the reviewer flagged: cancel + // immediate re-login = late cancel_ok kicking awaiting_phone // back to disconnected. // // (Out-of-band manual `!tg cancel` typed in chat-fallback while // the widget shows an active form would also be ignored. That's // accepted scope: we don't run a causality/epoch system, and the // chat-fallback flow is an escape hatch, not a primary surface.) if (state.kind !== 'disconnected') return state; return { kind: 'disconnected' }; case 'login_in_progress': // Surfaces when the user clicked Войти по номеру but the bridge // already has a stale flow open. Form-level warning if a form is // open; otherwise dropped so we don't manufacture a disconnected // banner from nothing. if (isFormState(state)) { return { ...state, lastError: { kind: 'login_in_progress' } }; } return state; case 'max_logins': // Should not fire for max_logins=1 operators when our UI hides // login while connected. If it does fire, the user is in a race; // surface the error on disconnected so they can logout first. return { kind: 'disconnected', lastError: { kind: 'max_logins', limit: event.limit } }; case 'login_not_found': // Logout target id was wrong. Treat as disconnected — bridge clearly // doesn't know that login id any more. return { kind: 'disconnected' }; case 'invalid_value': // Bridge rejected our submitted phone/code/password (e.g. malformed // phone). Keep the form open with an error; if no form is open, // ignore so we don't pollute disconnected state. if (!isFormState(state)) return state; return { ...state, lastError: { kind: 'invalid_value', reason: event.reason } }; case 'submit_failed': // Telegram-side error (FloodWait, banned, etc.) leaked through // bridgev2's commands layer. Hold the current form open so the user // can retry; surface the verbatim Go error tail in the warning. if (!isFormState(state)) return state; return { ...state, lastError: { kind: 'submit_failed', reason: event.reason } }; case 'prepare_failed': return { kind: 'disconnected', lastError: { kind: 'prepare_failed', reason: event.reason } }; case 'start_failed': return { kind: 'disconnected', lastError: { kind: 'start_failed', reason: event.reason } }; case 'flow_required': case 'flow_invalid': // We always send `login phone` so this shouldn't happen. If it does, // the operator-config / bridge mismatch is loud enough to fail // visibly on the disconnected screen. return { kind: 'disconnected', lastError: { kind: 'start_failed', reason: 'flow' } }; case 'unknown_command': // Shouldn't happen — we only send commands the bridge knows. If it // does, the operator-config / bridge image is mismatched; surface it // loudly on the disconnected screen so the misconfig is visible. return { kind: 'disconnected', lastError: { kind: 'unknown_command' } }; case 'unknown': return state; default: { // Exhaustiveness check — if a new LoginEvent kind is added without a // case, TypeScript will flag this as a compile error. const exhaustive: never = event; return exhaustive; } } }; // --- M12.5 hydrate-from-timeline ----------------------------------------- // // Why a separate reducer: the live `loginReducer` above intentionally rejects // "out-of-thin-air" prompt events to defend against late-arriving replies // from cancelled flows resurrecting forms. Those gates are correct for live // traffic but useless for hydrate — from `unknown` they would drop every // awaiting_* prompt and we'd render nothing. // // The hydrate reducer is permissive: it walks bot replies in chronological // order and lets each one freely transition the state. We trust the timeline // because (a) the sender is filtered to bootstrap.botMxid by the caller and // (b) the events are durable bridge writes, not arbitrary user input. // // Hard scope: hydrate only ever returns one of awaiting_phone / awaiting_code // / awaiting_password (with optional lastError) or null. Terminal-ish final // states (login_success, logout_ok, cancel_*, not_logged_in, max_logins, // login_not_found, prepare_failed, start_failed, flow_*, unknown_command) // always fall back to null so App.tsx fires `list-logins` for authoritative // reconciliation. // UX freshness guard, NOT bridge truth. Bridgev2's CommandState has no // explicit TTL — it lives in User.CommandState until submit/cancel/restart // clears it, so a "stale" prompt could in fact still be active at the bridge. // This window is the UX-side judgement call: a 10-min-old code prompt is // worth resurfacing (Telegram's own SMS code TTL ~5 min, plus margin), a // day-old one is not. Tuned for code/password forms; phone is cheap enough // that the same window applies. const HYDRATE_FRESHNESS_MS = 10 * 60 * 1000; export type HydrateInput = { ev: LoginEvent; // origin_server_ts of the underlying m.notice. Used for the freshness // check on the LAST significant pending prompt only. ts: number; }; type HydrateAccumulator = { state: LoginState; // Timestamp of the most recent event that contributed to a non-unknown, // non-terminal pending state. Drives the freshness gate. pendingTs: number | null; // Once a terminal event lands, we stop honouring later pending prompts in // the same scan — terminal collapses the chain and any subsequent pending // prompt is a fresh flow that the live `list-logins` will reconcile. terminated: boolean; }; // Apply one event with permissive rules. Unlike the live reducer, every // transition is allowed from any predecessor — we're rebuilding past truth, // not protecting against late races. const stepHydrate = (acc: HydrateAccumulator, input: HydrateInput): HydrateAccumulator => { const { ev, ts } = input; // After a terminal event (cancel_ok / logout_ok / login_success / …) we // normally stop tracking — anything that follows is by definition a fresh // flow that the live `list-logins` will reconcile. EXCEPT for one case: // if `awaiting_phone` shows up, that IS the bridgev2 signature of `!tg // login phone` being re-issued. The user cancelled (or finished) and is // now logging in again; the chain should resume tracking from the new // start. Without this re-entry, sequences like // [awaiting_code, cancel_ok, awaiting_phone, awaiting_code] // (cancel-then-restart, mid-code) would return null and regress the very // M12.5 bug we set out to fix. if (acc.terminated && ev.kind !== 'awaiting_phone') { return acc; } switch (ev.kind) { case 'awaiting_phone': return { state: { kind: 'awaiting_phone' }, pendingTs: ts, terminated: false }; case 'awaiting_code': return { state: { kind: 'awaiting_code' }, pendingTs: ts, terminated: false }; case 'awaiting_password': return { state: { kind: 'awaiting_password' }, pendingTs: ts, terminated: false }; case 'twofa_required': return { state: { kind: 'awaiting_password' }, pendingTs: ts, terminated: false }; case 'invalid_code': return { state: { kind: 'awaiting_code', lastError: { kind: 'invalid_code' } }, pendingTs: ts, terminated: false, }; case 'wrong_password': return { state: { kind: 'awaiting_password', lastError: { kind: 'wrong_password' } }, pendingTs: ts, terminated: false, }; case 'invalid_value': // Form-scoped soft error: only surface if we're already on a form. if (!isFormState(acc.state)) return acc; return { state: { ...acc.state, lastError: { kind: 'invalid_value', reason: ev.reason } }, pendingTs: ts, terminated: false, }; case 'submit_failed': if (!isFormState(acc.state)) return acc; return { state: { ...acc.state, lastError: { kind: 'submit_failed', reason: ev.reason } }, pendingTs: ts, terminated: false, }; // Terminal events — collapse the chain. The state at this point is // whatever-the-bot-confirmed-last; we don't care which, the caller // returns null and lets `list-logins` reconcile. case 'login_success': case 'logout_ok': case 'cancel_ok': case 'cancel_no_op': case 'not_logged_in': case 'max_logins': case 'login_not_found': case 'prepare_failed': case 'start_failed': case 'flow_required': case 'flow_invalid': case 'unknown_command': return { state: acc.state, pendingTs: null, terminated: true }; case 'logins_listed': // A list-logins reply landed in history. Empty list means user wasn't // logged in at that point; non-empty means they were. Both are // terminal-ish for hydrate purposes — fall through to live // reconciliation rather than guess at validity from cached snapshot. return { state: acc.state, pendingTs: null, terminated: true }; case 'login_in_progress': case 'unknown': // Soft no-op for hydrate. login_in_progress is a live-flow warning // that doesn't reflect persistent state; unknown is a wording-drift // catch-all — neither should advance hydrate state. return acc; default: { const exhaustive: never = ev; return exhaustive; } } }; export const hydrateFromTimeline = ( inputs: ReadonlyArray, now: number = Date.now() ): PendingFormState | null => { const acc = inputs.reduce(stepHydrate, { state: { kind: 'unknown' }, pendingTs: null, terminated: false, }); if (acc.terminated) return null; if (!isFormState(acc.state)) return null; if (acc.pendingTs === null) return null; if (now - acc.pendingTs > HYDRATE_FRESHNESS_MS) return null; return acc.state; }; // --- DEV sanity assertions ------------------------------------------------ // Mirrors the dialect-side runSanityChecks pattern — failure throws, dev // overlay surfaces it on reload, production builds tree-shake the branch. if (import.meta.env.DEV) { runHydrateSanity(); } function runHydrateSanity(): void { const t0 = 1_700_000_000_000; const recent = (offset: number) => t0 + offset; const now = t0 + 60 * 1000; // 1 minute after t0 const cases: Array<{ name: string; inputs: HydrateInput[]; expected: LoginState | null; nowOverride?: number; }> = [ { name: 'empty timeline → null', inputs: [], expected: null, }, { name: 'lone phone prompt → awaiting_phone', inputs: [{ ev: { kind: 'awaiting_phone' }, ts: recent(0) }], expected: { kind: 'awaiting_phone' }, }, { name: 'phone → code → awaiting_code', inputs: [ { ev: { kind: 'awaiting_phone' }, ts: recent(0) }, { ev: { kind: 'awaiting_code' }, ts: recent(1000) }, ], expected: { kind: 'awaiting_code' }, }, { name: '2fa pair → awaiting_password', inputs: [ { ev: { kind: 'awaiting_phone' }, ts: recent(0) }, { ev: { kind: 'awaiting_code' }, ts: recent(1000) }, { ev: { kind: 'twofa_required' }, ts: recent(2000) }, { ev: { kind: 'awaiting_password' }, ts: recent(2100) }, ], expected: { kind: 'awaiting_password' }, }, { name: 'invalid_code retry → awaiting_code with error', inputs: [ { ev: { kind: 'awaiting_code' }, ts: recent(0) }, { ev: { kind: 'invalid_code' }, ts: recent(1000) }, { ev: { kind: 'awaiting_code' }, ts: recent(1100) }, ], expected: { kind: 'awaiting_code' }, // re-prompt clears the error — same as live reducer }, { name: 'invalid_code as final event → awaiting_code with error', inputs: [ { ev: { kind: 'awaiting_code' }, ts: recent(0) }, { ev: { kind: 'invalid_code' }, ts: recent(1000) }, ], expected: { kind: 'awaiting_code', lastError: { kind: 'invalid_code' } }, }, { name: 'wrong_password as final event → awaiting_password with error', inputs: [ { ev: { kind: 'awaiting_password' }, ts: recent(0) }, { ev: { kind: 'wrong_password' }, ts: recent(1000) }, ], expected: { kind: 'awaiting_password', lastError: { kind: 'wrong_password' } }, }, { name: 'login_success after pending → null (let list-logins reconcile)', inputs: [ { ev: { kind: 'awaiting_password' }, ts: recent(0) }, { ev: { kind: 'login_success', handle: '@x', numericId: '1' }, ts: recent(1000), }, ], expected: null, }, { name: 'cancel_ok after pending → null', inputs: [ { ev: { kind: 'awaiting_phone' }, ts: recent(0) }, { ev: { kind: 'cancel_ok' }, ts: recent(1000) }, ], expected: null, }, { name: 'not_logged_in alone → null', inputs: [{ ev: { kind: 'not_logged_in' }, ts: recent(0) }], expected: null, }, { name: 'awaiting_phone after terminal → restart chain (resume tracking)', inputs: [ { ev: { kind: 'awaiting_code' }, ts: recent(0) }, { ev: { kind: 'cancel_ok' }, ts: recent(1000) }, { ev: { kind: 'awaiting_phone' }, ts: recent(2000) }, ], expected: { kind: 'awaiting_phone' }, }, { name: 'cancel-then-restart-mid-code → awaiting_code (the reviewer-#11 regression)', inputs: [ { ev: { kind: 'awaiting_code' }, ts: recent(0) }, { ev: { kind: 'cancel_ok' }, ts: recent(1000) }, { ev: { kind: 'awaiting_phone' }, ts: recent(2000) }, { ev: { kind: 'awaiting_code' }, ts: recent(3000) }, ], expected: { kind: 'awaiting_code' }, }, { name: 'logout-then-relogin-mid-password → awaiting_password', inputs: [ { ev: { kind: 'awaiting_phone' }, ts: recent(0) }, { ev: { kind: 'awaiting_code' }, ts: recent(1000) }, { ev: { kind: 'login_success', handle: '@x', numericId: '1' }, ts: recent(2000) }, { ev: { kind: 'logout_ok' }, ts: recent(3000) }, { ev: { kind: 'awaiting_phone' }, ts: recent(4000) }, { ev: { kind: 'awaiting_code' }, ts: recent(5000) }, { ev: { kind: 'twofa_required' }, ts: recent(6000) }, { ev: { kind: 'awaiting_password' }, ts: recent(6100) }, ], expected: { kind: 'awaiting_password' }, }, { name: 'stale prompt without preceding awaiting_phone → still terminated → null', inputs: [ { ev: { kind: 'awaiting_code' }, ts: recent(0) }, { ev: { kind: 'cancel_ok' }, ts: recent(1000) }, { ev: { kind: 'awaiting_code' }, ts: recent(2000) }, ], expected: null, }, { name: 'pending too old → null (freshness guard)', inputs: [{ ev: { kind: 'awaiting_code' }, ts: t0 - 30 * 60 * 1000 }], expected: null, }, { name: 'pending just inside window → state', inputs: [{ ev: { kind: 'awaiting_code' }, ts: t0 - 9 * 60 * 1000 }], expected: { kind: 'awaiting_code' }, nowOverride: t0, }, { name: 'submit_failed on pending → keeps form with warn', inputs: [ { ev: { kind: 'awaiting_phone' }, ts: recent(0) }, { ev: { kind: 'submit_failed', reason: 'PHONE_NUMBER_BANNED' }, ts: recent(1000) }, ], expected: { kind: 'awaiting_phone', lastError: { kind: 'submit_failed', reason: 'PHONE_NUMBER_BANNED' }, }, }, { name: 'login_in_progress alone → null (soft no-op, no pending state)', inputs: [{ ev: { kind: 'login_in_progress' }, ts: recent(0) }], expected: null, }, { name: 'unknown alone → null', inputs: [{ ev: { kind: 'unknown' }, ts: recent(0) }], expected: null, }, ]; for (const c of cases) { const actual = hydrateFromTimeline(c.inputs, c.nowOverride ?? now); if (!sameLoginState(actual, c.expected)) { // eslint-disable-next-line no-console console.error('[hydrate sanity] mismatch', { case: c.name, actual, expected: c.expected }); throw new Error(`hydrate sanity failed: ${c.name}`); } } } function sameLoginState(a: LoginState | null, b: LoginState | null): boolean { if (a === null || b === null) return a === b; return JSON.stringify(a) === JSON.stringify(b); }