frontend: handle session transfer request failures

[Fhatu12]

Summary

• only show session-transfer creation success after a successful HTTP response with a valid transfer ID
• only reload after redeeming a transfer when the response is successful and confirms {ok: true}
• restore usable controls and show safe inline errors when create or redeem requests fail
• activate the existing welcome Playwright spec under the repository's .spec.ts convention and add regression coverage for the failure paths

Validation

• corepack pnpm --filter ep_etherpad-lite run ts-check
• corepack pnpm run build:etherpad
• corepack pnpm exec playwright test tests/frontend-new/specs/welcome.spec.ts --project=chromium --project=firefox --reporter=list — 28 passed
• corepack pnpm exec cross-env NODE_ENV=production npx mocha --import=tsx --timeout 120000 tests/backend/specs/tokenTransfer.ts — 6 passing
• corepack pnpm --filter ep_etherpad-lite run test:vitest — 49 files / 724 tests passed
• git diff --check

The repository's current lint command fails on both this candidate and its pristine base before source analysis because ESLint 10 cannot find a flat eslint.config.*; the candidate does not modify lint configuration.

Fixes #8172

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Handle session transfer request failures in the welcome UI

🐞 Bug fix 🧪 Tests ✨ Enhancement 🕐 20-40 Minutes

AI Description

• Validate HTTP status and payloads before confirming session creation or redemption.
• Restore controls and display localized, safely rendered inline errors after failures.
• Activate Playwright coverage for malformed responses, server errors, and network failures.

Diagram

graph TD
  A["Transfer Controls"] --> B["Transfer API"] --> C{"HTTP successful?"}
  C -->|Yes| D{"Payload valid?"} -->|Yes| F["Success State"]
  C -->|No| E["Inline Error"] --> G["Restore Controls"]
  D -->|No| E

Loading

High-Level Assessment

The localized response-parsing and UI-state helpers are appropriate because both operations share failure semantics within one welcome-page module. A global fetch wrapper or broader state-management abstraction would add unnecessary scope for these two request paths.

Files changed (4) +484 / -37

Enhancement (1) +2 / -0

index.htmlAdd accessible inline transfer error regions +2/-0

Add accessible inline transfer error regions

• Adds separate hidden ARIA alert regions for session creation and redemption failures so errors appear within the relevant workflow.

src/templates/index.html

Bug fix (2) +129 / -37

en.jsonAdd the session transfer fallback error message +1/-0

Add the session transfer fallback error message

• Adds the English localization string used when a transfer response lacks a safe, specific server error.

src/locales/en.json

welcome.tsValidate transfer responses and recover UI state on failure +128/-37

Validate transfer responses and recover UI state on failure

• Adds safe JSON parsing, response-contract checks, localized error handling, and retryable control restoration for create and redeem requests. Creation now requires a successful response with a non-empty ID, while redemption reloads only after a successful response containing ok=true.

src/static/js/welcome.ts

Tests (1) +353 / -0

welcome.spec.tsActivate and expand session transfer Playwright coverage +353/-0

Activate and expand session transfer Playwright coverage

• Moves the welcome tests under the repository's recognized .spec.ts convention and introduces reusable dialog helpers. Adds regression coverage for HTTP errors, invalid payloads, malformed JSON, network failures, safe text rendering, preserved redeem codes, restored controls, and confirmed success contracts.

src/tests/frontend-new/specs/welcome.spec.ts

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (1) 📜 Skill insights (0)

1. id accepts malformed values 📎 Requirement gap ≡ Correctness

Description

The create flow treats every non-empty string as a valid transfer ID, so a malformed 2xx payload
such as {id: "x"} exposes a copy-success state containing an unusable code. Created IDs are UUIDs
and the redeem flow requires 36 characters, but this validation does not enforce that format.

Code

src/static/js/welcome.ts[R86-88]

+      if (!responseData || typeof responseData !== 'object' ||
+          !('id' in responseData) || typeof transferData.id !== 'string' ||
+          transferData.id.trim() === '') {

Evidence

Compliance rule 1 requires a valid transfer ID before success is shown. The changed create-flow
check rejects only non-strings and blank strings (welcome.ts[86-89]), while the server generates
UUIDs (tokenTransfer.ts[39-39]) and the same client considers redeem codes valid based on the
expected 36-character length (welcome.ts[117-117]).

Validate create-session transfer responses before showing success
src/static/js/welcome.ts[86-89]
src/node/hooks/express/tokenTransfer.ts[39-39]
src/static/js/welcome.ts[117-117]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The create-session response accepts any non-empty string as a transfer ID, allowing malformed IDs to trigger the success and copy UI.

## Issue Context
The server creates IDs with `crypto.randomUUID()`, and the receive flow expects a 36-character transfer code. Validate the returned ID against the actual UUID format before exposing it, and add regression coverage for non-empty malformed IDs.

## Fix Focus Areas
- src/static/js/welcome.ts[86-89]
- src/tests/frontend-new/specs/welcome.spec.ts[109-126]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Stale code enables submit 🐞 Bug ≡ Correctness

Description

When redemption fails, redeemTransferCode() restores the button from the captured submitted
code, not the code currently in the editable input. If the user changes the input to an invalid
value while the request is pending, the catch block overrides the input listener and enables the
button, allowing an invalid redemption request.

Code

src/static/js/welcome.ts[141]

+    transferSessionButton.disabled = !isValidTransferCode(code);

Evidence

The click handler snapshots codeInputField.value and passes only that string into
redeemTransferCode; while the fetch is pending, the input listener independently changes the
button state from the live field value. On failure, line 141 overwrites that live state using the
old snapshot, so editing a submitted valid 36-character code to a short value before the response
arrives leaves the button enabled.

src/static/js/welcome.ts[119-145]
src/static/js/welcome.ts[182-201]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A failed redeem request re-enables the transfer button according to the originally submitted code, even when the user has since edited the input to an invalid value.

## Issue Context
The input remains editable while the fetch is pending. Its input listener correctly updates the disabled state from the current value, but the request catch block can later overwrite that state using stale data.

## Fix Focus Areas
- src/static/js/welcome.ts[119-145]
- src/static/js/welcome.ts[182-201]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Tickets: 🎫 Session transfer UI treats non-2xx responses as success

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. id accepts malformed values 📎 Requirement gap ≡ Correctness

The create flow treats every non-empty string as a valid transfer ID, so a malformed 2xx payload
such as {id: "x"} exposes a copy-success state containing an unusable code. Created IDs are UUIDs
and the redeem flow requires 36 characters, but this validation does not enforce that format.

Agent Prompt

## Issue description
The create-session response accepts any non-empty string as a transfer ID, allowing malformed IDs to trigger the success and copy UI.

## Issue Context
The server creates IDs with `crypto.randomUUID()`, and the receive flow expects a 36-character transfer code. Validate the returned ID against the actual UUID format before exposing it, and add regression coverage for non-empty malformed IDs.

## Fix Focus Areas
- src/static/js/welcome.ts[86-89]
- src/tests/frontend-new/specs/welcome.spec.ts[109-126]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

2. Stale code enables submit 🐞 Bug ≡ Correctness

When redemption fails, redeemTransferCode() restores the button from the captured submitted
code, not the code currently in the editable input. If the user changes the input to an invalid
value while the request is pending, the catch block overrides the input listener and enables the
button, allowing an invalid redemption request.

Agent Prompt

## Issue description
A failed redeem request re-enables the transfer button according to the originally submitted code, even when the user has since edited the input to an invalid value.

## Issue Context
The input remains editable while the fetch is pending. Its input listener correctly updates the disabled state from the current value, but the request catch block can later overwrite that state using stale data.

## Fix Focus Areas
- src/static/js/welcome.ts[119-145]
- src/static/js/welcome.ts[182-201]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools