DEV Community: Hassan Naeem

The token refresh bug that kept logging our users out, and took me 3+ weeks to solve

Hassan Naeem — Wed, 07 Oct 2026 00:36:35 +0000

While I was working with a company on their mobile app, we ran into a bug that sounded impossible:

Users were getting logged out, even though their refresh token was valid for seven hours.

No crash, no obvious error. People just got sent back to the login screen. I spent more than three weeks researching and debugging it. I went through the frontend and backend code over and over, read everything I could find about token refresh flows, and tested theory after theory until I found the actual cause and a fix that worked.

The symptom

Access token expires, which is expected.
Refresh token is still valid for hours.
The user gets kicked to the login screen anyway, and only sometimes. That's the worst kind of bug.

"Sometimes" is the clue. When a bug depends on timing, look for a race condition.

The root cause: everyone refreshes at once

Think about what a typical screen does when it opens. It fires several API calls in parallel: profile, notifications, feed, settings.

If the access token has just expired, all of them fail with 401 at the same time. A naive interceptor handles each failure independently:

GET /profile        → 401 → POST /auth/refresh ┐
GET /notifications  → 401 → POST /auth/refresh ├─ 4 refreshes racing each other
GET /feed           → 401 → POST /auth/refresh │
GET /settings       → 401 → POST /auth/refresh ┘

Each request tries to refresh the token on its own. Those refresh calls conflict with each other. With refresh-token rotation, for example, the first refresh invalidates the old refresh token, and every other call is now holding a dead one. One of them fails, the error handler treats it as a failed refresh, and the app logs the user out.

The token was never really invalid. The app just tried to refresh it four times at once.

The fix: one refresh, everyone else waits in a queue

Here's how I solved it:

Notice that parallel requests are each triggering their own token refresh.
Build a queue on the frontend to hold incoming requests while a refresh is in progress.
Let only one request trigger the actual refresh call.
Make all other requests wait in the queue until that refresh completes.
Once the new token arrives, update storage and release all queued requests with the new token.

GET /profile        → 401 → POST /auth/refresh ──────┐
GET /notifications  → 401 → wait in queue ⏳          │
GET /feed           → 401 → wait in queue ⏳          │
GET /settings       → 401 → wait in queue ⏳          │
                                                      ▼
                         new token saved → retry all 4 requests ✅

The code

Here it is as an Axios interceptor. It works the same in React Native and on the web.

import axios, { AxiosError, InternalAxiosRequestConfig } from 'axios';
import { tokenStore } from './tokenStore'; // wraps SecureStore / AsyncStorage / localStorage
import { logout } from './auth';

const API_URL = 'https://api.example.com';
export const api = axios.create({ baseURL: API_URL });

let isRefreshing = false;
let queue: Array<{
  resolve: (token: string) => void;
  reject: (error: unknown) => void;
}> = [];

// Release every waiting request, either with the new token or with the error.
function flushQueue(error: unknown, token: string | null) {
  queue.forEach(({ resolve, reject }) => (error ? reject(error) : resolve(token!)));
  queue = [];
}

// Attach the current access token to every request.
api.interceptors.request.use(async (config) => {
  const token = await tokenStore.getAccessToken();
  if (token) config.headers.Authorization = `Bearer ${token}`;
  return config;
});

api.interceptors.response.use(
  (response) => response,
  async (error: AxiosError) => {
    const original = error.config as InternalAxiosRequestConfig & { _retry?: boolean };

    // Only handle 401s, and only retry a request once.
    if (error.response?.status !== 401 || !original || original._retry) {
      return Promise.reject(error);
    }
    original._retry = true;

    // This request went out with an old token, and another request has already
    // refreshed since. Nothing to refresh: just retry with the token we have now.
    const sent = String(original.headers.Authorization ?? '').replace('Bearer ', '');
    const current = await tokenStore.getAccessToken();
    if (!isRefreshing && current && current !== sent) {
      original.headers.Authorization = `Bearer ${current}`;
      return api(original);
    }

    // A refresh is already running: wait in the queue, then retry.
    if (isRefreshing) {
      const token = await new Promise<string>((resolve, reject) => {
        queue.push({ resolve, reject });
      });
      original.headers.Authorization = `Bearer ${token}`;
      return api(original);
    }

    // This request is the one that refreshes.
    isRefreshing = true;
    try {
      const refreshToken = await tokenStore.getRefreshToken();
      // Use bare axios, not `api`, so the refresh call doesn't loop through this interceptor.
      const { data } = await axios.post(`${API_URL}/auth/refresh`, { refreshToken });

      await tokenStore.save(data.accessToken, data.refreshToken);
      flushQueue(null, data.accessToken);

      original.headers.Authorization = `Bearer ${data.accessToken}`;
      return api(original);
    } catch (refreshError) {
      // The refresh really failed, so logging out is now the right call.
      flushQueue(refreshError, null);
      await logout();
      return Promise.reject(refreshError);
    } finally {
      isRefreshing = false;
    }
  }
);

Things worth noticing:

isRefreshing is the lock. Only the first 401 starts a refresh. Every later one gets parked in queue.
The queue holds promises, not requests. Each waiting request is a pending promise that resolves with the new token, then retries itself.
The refresh call uses bare axios. If it went through api, a 401 from the refresh endpoint would trigger another refresh, and you'd have an infinite loop.
A late 401 doesn't start a second refresh. A slow request sent with the old token can fail after the refresh has already finished. By then isRefreshing is false again, so without the current !== sent check it would refresh a second time, and with rotation that second refresh can fail and log the user out. The bug comes back through the side door.
_retry stops retry loops. A request that still gets a 401 after a fresh token is a real auth failure, not a race.
Logout only happens when the refresh itself fails. That's the whole point: a single expired access token should never log anyone out.

How I learned this

I didn't learn this from a course or a tutorial. It came from spending real time on a real product, debugging a painful production issue, and refusing to give up until I understood exactly what was happening under the hood.

Three weeks felt like a long time to spend on one bug. But I came out of it understanding auth flows, interceptors, and race conditions far better than any tutorial could have taught me. Ever since, it's the first thing I check when an app logs users out for no clear reason.

Go deep on the "why" behind your bugs. The fix is useful once. Understanding it keeps paying off.

Have you hit this bug in your own app? Or a different auth race condition? Tell me in the comments.

I built a browser agent that plays a game by looking at pixels

Hassan Naeem — Tue, 21 Apr 2026 15:53:03 +0000

A lot of "AI agents" are just an LLM with a REST API stitched to it. I wanted to build something where the agent can't cheat, no DOM shortcuts, no hidden game state. Just a browser, a screen, and a mouse.

So I built a small agent that plays Block Champ on CrazyGames.

Repo: https://github.com/Hassan-Naeem-code/Browser-Operating-Agent

Here's what was interesting about it, and the techniques all transfer to any canvas-based web app (whiteboards, in-browser IDEs, design tools, games).

The problem with "browser agents."

Most browser automation tutorials assume the app cooperates: meaningful HTML, readable labels, queryable buttons. Games don't. The whole board lives inside a <canvas> element, which from the DOM's point of view is just a black box.

On top of that, this game lives inside nested iframes, a CrazyGames wrapper frame, and inside it, the actual game frame. So the agent needs to:

Land on the page
Find the outer iframe
Switch context into it
Find the inner iframe
Switch context again
Find the canvas
Figure out its absolute position on the screen
Drag the mouse in global coordinates that map back to the canvas

Every step is a place where a naive script breaks.

Step 1 — Traversing nested iframes

Playwright's content_frame() is the key. You query for the iframe element as usual, then ask Playwright to give you the frame's context so you can query inside it:

await page.wait_for_selector('iframe#game-iframe', timeout=15000)
iframe_element = await page.query_selector('iframe#game-iframe')
iframe = await iframe_element.content_frame()

# And again, one level deeper
nested_iframe_element = await iframe.query_selector(
    'iframe[src*="block-champ/2/index.html"]'
)
nested_game_frame = await nested_iframe_element.content_frame()

Small gotcha: you have to wait_for_timeout between switches. IFrames load asynchronously, and if you query too early, you get None back with no obvious error.

Step 2 — Canvas positioning

Once you've got the canvas, bounding_box() gives you its position inside its frame. But the mouse API operates on the page's global coordinates. So you have to add them:

canvas_box = await canvas.bounding_box()
iframe_box = await nested_iframe_element.bounding_box()

global_x = iframe_box['x'] + canvas_box['x'] + canvas_box['width'] / 2
global_y = iframe_box['y'] + canvas_box['y'] + canvas_box['height'] * 0.85

This is the thing most people miss: every iframe has its own coordinate system. Nested iframes stack those offsets. Forget to add them, and your clicks land on nothing.

Step 3 — Humanlike mouse movement

Block Champ only registers drugs that look like real drugs. If you teleport the mouse from A to B, the game ignores it. You need intermediate moves:

steps = 40
for i in range(steps):
    intermediate_x = source_x + (target_x - source_x) * (i / steps)
    intermediate_y = source_y + (target_y - source_y) * (i / steps)
    await self.page.mouse.move(intermediate_x, intermediate_y)
    await asyncio.sleep(0.01)

Forty steps with a 10ms sleep between each gives you a ~400ms drag — smooth enough to register. This same technique works for bot-detection bypass in legitimate testing contexts, drag-and-drop in design tools, slider inputs, anywhere mouse dynamics matter.

Step 4 — Reading a canvas with pixels

Here's the fun part. The canvas is opaque to the DOM, but Playwright can screenshot just the canvas element and hand you raw bytes:

img_bytes = await canvas.screenshot()
img = Image.open(io.BytesIO(img_bytes))

From there, it's just PIL. For Block Champ, I divided the canvas into a 10×10 grid, sampled one pixel at the center of each cell, and classified it as empty or filled based on brightness:

grid_size = 10
cell_w = width // grid_size
cell_h = height // grid_size
threshold = 220  # empty cells are near-white in this game

for gx in range(grid_size):
    for gy in range(grid_size):
        px = gx * cell_w + cell_w // 2
        py = gy * cell_h + cell_h // 2
        r, g, b = pixels[px, py]
        if r > threshold and g > threshold and b > threshold:
            empty_count += 1
        else:
            filled_count += 1

Crude, but it works. And it's the pattern you'd use to let an LLM "see" any canvas-based UI: screenshot, grid, classify, pass the grid as text to the model.

What's still missing

The current version makes random moves. The structure is there for smarter play; choose_best_move(board_state) is a placeholder waiting for real logic.

Next steps I'm exploring:

Send the board state to an LLM as structured text and let the model pick moves
Use a small local vision model to classify cell shapes instead of just "empty/filled."
Run it headless on a schedule and track scores over time

Why this matters beyond a game

The exact same pattern — traverse → locate → screenshot → classify → act ,is how you'd build agents for:

Figma/Miro automation
In-browser CAD or music tools
Any legacy internal tool that renders to canvas
Visual testing of rich web apps

The DOM is no longer the only API for the web. If you can take a screenshot and send a mouse event, you can build an agent.

Repo with full code: https://github.com/Hassan-Naeem-code/Browser-Operating-Agent

If you're building agents or doing browser automation, I'd love to hear what you're working on. Drop a comment or find me on GitHub.