DEV Community: Hassan Naeem

My crawler said 1 in 7 websites were down. They weren't, and retrying made it worse.

Hassan Naeem — Wed, 14 Oct 2026 04:32:01 +0000

I'm building Fresh Leads, a tool that finds local businesses and grades their websites so agencies know who to pitch. One of the strongest signals it reports is simple:

"Their website is down."

If you sell web design, that's the best cold-call opener there is. It's also the worst thing to get wrong. If a customer calls a coffee shop and says "your site is down" while the owner is looking at it working fine, the customer loses the call and I lose the customer.

So when I finally checked those verdicts properly, the result hurt.

The measurement

I took 47 sites that one crawl had recorded as unreachable and opened each one from my laptop.

6 of them loaded instantly. That's 13% wrong. A second, larger run gave the same answer: 56 of 413, or 14%. Two of the "dead" sites belonged to well-known coffee chains, and both were serving pages perfectly well.

The cause wasn't hard to guess. The crawler runs on a serverless platform, so every request comes from a datacentre IP address. Cloudflare, Shopify and similar platforms block or challenge datacentre traffic as a matter of routine. To my crawler, a site that blocks it looks the same as a site that doesn't exist.

"Did not answer us" and "is down" are not the same sentence.

I tried three fixes. The first two failed, and the way they failed taught me more than the fix that worked.

Attempt 1: just retry the failures

The original pipeline already had a "quiet re-check" stage. Any site that failed during the main crawl (24 fetches running at once) was retried later, three at a time with a longer timeout. The reasoning sounded right: a big concurrent crawl causes throttling, so a gentle second try should get a truer answer.

That stage took up 22% of every search's runtime. Nothing recorded what it actually recovered, so I added two counters, recheck_tried and recheck_recovered, and let it run on real production searches.

36 sites retried across 6 production searches
 0 recovered

Not "low". Zero.

And looking back, it could never have been anything else. A block is perfectly consistent. If an IP gets blocked, it gets blocked again eight seconds later, and it'll keep getting blocked at any concurrency and with any timeout. Retries catch slow hosts. They can't catch refusals, and refusals were nearly all I had.

I deleted the stage. Searches got 22% faster, and the results didn't change at all.

Attempt 2: wait six hours and check again

Next idea: if retrying immediately can't tell a block from a dead site, maybe time can. A dead site stays dead. A flaky one recovers.

So I wrote confirmDown(). A first failure is recorded with a timestamp but never shown to the customer. Only a second failure at least six hours later, from a fresh connection, is allowed to say "down". A success at any point clears the record.

export function confirmDown(previous: Audit | null, next: Audit, now = Date.now()): Audit {
  // It answered: whatever happened before, it isn't down.
  if (next.reachable !== false) return { ...next, firstDownAt: null, downConfirmed: false };

  const firstDownAt = previous && !previous.reachable && previous.firstDownAt
    ? previous.firstDownAt
    : new Date(now).toISOString();

  const since = now - new Date(firstDownAt).getTime();
  // A clock that has gone backwards must not confirm anything.
  const confirmed = Number.isFinite(since) && since >= SIX_HOURS;
  return { ...next, firstDownAt, downConfirmed: confirmed };
}

It's clean, testable, and it feels rigorous. Two days later I checked it against reality: of 60 sites it had confirmed down, 13 loaded instantly from a normal connection.

unconfirmed failures   14% wrong
confirmed failures     22% wrong

Confirmation made it worse.

The reason is obvious once you see it. Waiting six hours filters out transient failures, like a server that was briefly overloaded. Those were the cases that would have recovered anyway. A datacentre block isn't transient. It fails the first check and the second one too. So the filter removed the harmless cases and left a pool that was concentrated with exactly the false verdicts it was supposed to exclude.

Time can't tell a block from a dead site. I needed a different signal.

Attempt 3: read the error I was throwing away

The signal had been there the whole time. My fetch wrapper looked like this:

try {
  return await fetch(url, { signal });
} catch {
  return null; // 🪦 every reason for failure, flattened into one
}

Node's fetch tells you why a request failed, in error.cause.code. And some of those reasons are proof, while others aren't:

Error	What it means	Can a browser on any network load it?
`ENOTFOUND`	DNS has no record for the domain	No. It's gone.
`ECONNREFUSED`	The host answered and nothing is listening on the port	No. It's down.
timeout, `ECONNRESET`, aborted TLS handshake, …	Something is there but won't talk to us	Often, yes

The last row is exactly what being blocked from a datacentre looks like. It's indistinguishable from a slow or hostile server, so I can't call it "down".

So I kept the reason:

let lastFailure: string | null = null;

try {
  const res = await fetch(url, { signal });
  lastFailure = null;
  return res;
} catch (e) {
  // Node puts the useful part in `cause.code`: ENOTFOUND when DNS has nothing,
  // ECONNREFUSED when nothing is listening, a timeout or reset when something
  // is there but won't talk to us.
  const cause = (e as { cause?: { code?: string } })?.cause;
  lastFailure = cause?.code ?? (e as Error)?.name ?? "unknown";
  return null;
}

And I made reachable three-valued instead of a boolean:

export function failureIsFatal(code: string | null | undefined): boolean {
  return code === "ENOTFOUND" || code === "ECONNREFUSED";
}

// After both http:// and https:// have failed:
return {
  reachable: failureIsFatal(lastFailure) ? false : null,
  failure: lastFailure,
  // ...every other finding is null too: we didn't see the page
};

true: we fetched it.
false: we have proof it's down (no DNS record, or the port refused).
null: we couldn't reach it, and we can't say why.

confirmDown() stayed, but only for the false case. A second look is cheap, and a wrong "down" is still the most expensive thing the product can say. What it no longer does is turn an inconclusive failure into a confident one just because it happened twice.

The `null` that wasn't "fine"

One trap is worth calling out, because I nearly fell into it.

My scoring code treats an audited site with no problems found as a good site. If "couldn't reach it" had been stored as "audited, no problems found", every blocked site would quietly have been graded healthy. The bug would just have flipped from "falsely down" to "falsely fine".

So null means not audited. The lead shows up as "we haven't checked their website yet", and its grade can go up later once we manage to look. It never drops now because of a claim we can't back up.

I also found that a deadline test was asserting the bug. When an audit ran out of its time budget, it returned reachable: false, which reported my timeout as a fact about their website. That test now expects null.

The cache still believed the old rule

Fixing the crawler didn't fix the data it had already written. When I counted the live table, there were 2,141 businesses whose sites showed as down, and 1,501 of them had no failure code at all. They'd been decided by a rule I'd already retired. Seventy per cent of the claim rested on evidence I'd stopped trusting.

I didn't run a backfill. The verdict is now earned on read: a row has to say it failed twice and that it failed with a fatal code. A row that can't answer the second question reads as "not checked", and the next crawl settles it under the current rule.

What I took away from it

Measure what your retry actually recovers. Mine cost 22% of every search and recovered nothing. Two integer counters would have told me that months earlier.
Retries and waiting only fix transient failures. If the failure is consistent, as a block is, repeating the check just confirms the wrong answer with more confidence.
Filtering can concentrate errors instead of removing them. If your filter removes the cases that were never the problem, what's left can be worse than what you started with.
Never catch { return null } at a boundary that makes a decision. The reason for the failure was the signal.
"Unknown" deserves its own value. A boolean forced me to pick between two lies. null let the code tell the truth: we didn't manage to look.

The fix ended up being a few lines. The lesson was that "we couldn't reach it" is a fact about you, not about them, and the code should never say otherwise.

Have you been burned by a check that was confidently wrong? Or a retry loop that turned out to do nothing? Tell me in the comments.

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.