Project

General

Profile

Actions

Improvement #31467

open

Improvement #31248: New Theme based Nextjs application dev analysis

Improvement #31319: Basic Next.js Setup and Architecture Implementation

Improvement #31374: Currency & Language Switcher Architecture

Currency Synchronization Implementation Plan

Added by Sachin Suresh 4 months ago. Updated 4 months ago.

Status:
Fixed not Tested
Priority:
Normal
Assignee:
Target version:
-
Start date:
12/19/2025
Due date:
12/19/2025 (about 4 months late)
% Done:

100%

Estimated time:
Spent time:
remarks:
DB Changes:
Keys & Permissions:
Areas Affected:
Files Changed:

Description

Implement a mechanism to notify other browser tabs when the currency is changed in one tab. The other tabs should display an alert asking the user if they want to update their view to the new currency.

Actions #1

Updated by Sachin Suresh 4 months ago

  • Subject changed from 2Currency Synchronization Implementation Plan to Currency Synchronization Implementation Plan
Actions #2

Updated by Sachin Suresh 4 months ago

  • Status changed from Assigned to In Progress
Actions #3

Updated by Sachin Suresh 4 months ago

  • Status changed from In Progress to Fixed not Tested
  • % Done changed from 0 to 100
  1. Improvement #31319: Concurrent Token Refresh Fix
  1. Issue
    Previous implementation of `getSession` in `auth-actions.ts` had a race condition. When multiple tabs or concurrent requests (e.g., flight search + user profile fetch) attempted to refresh an expired token simultaneously:
    1. Both requests would initiate a refresh call to the Identity Provider.
    2. The first one would succeed and rotate the refresh token.
    3. The second one would fail (because the refresh token was invalidated by the first call).
    4. This would trigger "Guest Recovery" or logout, breaking the session for the second tab/request.
  1. Fix Implementation
    Implemented a Promise Deduplication pattern (Mutex) in `src/actions/auth-actions.ts`.
    - Introduced a module-level `refreshPromises` map.
    - Before refreshing, the system checks if a refresh promise is already pending for the `sessionId`.
    - If a promise exists, the new request simply waits for that existing promise to resolve and reuses the result.
    - If no promise exists, a new one is created, stored, and executed.

This ensures that only *one network call is made to the Identity Provider per session, regardless of how many concurrent requests are triggered.

Actions

Also available in: Atom PDF