DEV Community: Joel

Our password reset links kept expiring. The bug only happened if you had two tabs open.

Joel — Fri, 07 Aug 2026 10:20:11 +0000

A user told us their password reset link was expired. It was about four minutes old.

I clicked it myself. Worked fine. Asked them to try again. Expired again.

That went on longer than I want to admit, because the bug does not reproduce unless you already have the app open in another tab. I never do while testing. Our users always do.

What was actually happening

Supabase sends the session back in the URL fragment. You land on something like:

https://app.example.com/#access_token=eyJhbG...&type=recovery

The client reads that fragment, exchanges it for a session, and strips it from the URL. The important word is asynchronously. It does not happen on the same tick your app boots.

We had a bit of code at boot that tidied the URL. Nothing exotic:

// what we had
window.history.replaceState(null, '', window.location.pathname)

That runs on mount. If it wins the race, the fragment is gone before Supabase ever reads it. No session, no recovery event, and the reset page renders "That link has expired" on a link that was perfectly valid a second ago.

Why the second tab matters

This is the part I found genuinely interesting.

supabase-js coordinates token refresh across tabs using navigator.locks. With one tab there is no contention and the exchange finishes fast, usually before React has even mounted. Our replaceState lost the race and everything worked.

Open a second tab and the lock is contended. The exchange waits. In our logs GoTrue was saying:

Lock not released within 5000ms

It recovers, but by then it is whole seconds behind. Our replaceState had fired ages ago and eaten the token.

So the bug was not intermittent at all. It was deterministic. It just depended on a variable I was not thinking of as a variable.

Worth saying plainly, because it cost me an afternoon: "I cannot reproduce it" usually means my environment differs from theirs in a way I have not identified yet. It rarely means the user is wrong.

We had two of them

Once I knew what to look for, there was a second offender. A boot routine that normalised query parameters, on a blind 1.5 second timer. Same effect, slightly later, and it explained why a couple of the fixes I tried seemed to half work.

If you have written one URL scrub you have probably written two. Grep for replaceState and pushState before you decide you are done.

The rule that fixed it

Nothing may rewrite the URL while the fragment still carries unconsumed tokens.

In practice that means one of two things. Either wait until the hash is empty, or only touch your own markers and put the fragment back exactly as you found it. We went with the second because it does not need a timer at all:

useEffect(() => {
  if (!callbackType) return
  const { pathname, search, hash } = window.location

  if (search.includes('recovery=1')) {
    const params = new URLSearchParams(search)
    params.delete('recovery')                 // our marker, ours to remove
    const qs = params.toString()
    window.history.replaceState(
      null, '',
      `${pathname}${qs ? `?${qs}` : ''}${hash}`   // fragment goes back untouched
    )
  }
}, [])

Supabase strips the fragment itself once it has consumed it. You do not need to clean up after it. Let it finish.

We also kept a second net, because the exchange can land after mount:

supabase.auth.onAuthStateChange((event) => {
  if (event === 'PASSWORD_RECOVERY') {
    setCallbackType('recovery')
    window.history.replaceState(null, '', window.location.pathname)  // safe now
  }
})

That replaceState is fine, because by the time the event fires the token has already been used.

The bit that bites you next

There is a follow-on problem that is easy to walk straight into once you have fixed the first one.

If anything rewrites the URL at boot, then any code reading window.location later is reading whatever survived, not what the user arrived with. We were checking for a recovery marker after our own scrub had already removed it.

The fix is to snapshot at module evaluation, before React does anything:

const bootHash = typeof window !== 'undefined' ? window.location.hash : ''
const bootSearch = typeof window !== 'undefined' ? window.location.search : ''

Then read bootSearch and bootHash everywhere, never live location. Same idea applies to UTM parameters, referral codes, anything you care about that arrives in the URL and might get tidied away.

We also route expired links to a real screen with a resend button instead of dumping people on the dashboard with no explanation. Some of those links genuinely are expired, and "nothing happened" is a terrible answer.

What I would take from it

If you are using Supabase auth in a SPA, go and grep for replaceState right now. If any of it runs at boot without checking the hash, you have this bug. It will look intermittent, it will not reproduce on your machine, and it only shows up on the flow where users are already frustrated.

Two tabs. That was the whole thing.

I build SOCIALFUEL, which pulls the live ads any brand is running and breaks down why they work. This one came out of our own auth flow, and I would rather write it up than have someone else lose the same afternoon.

Prompt engineering couldn't fix this LLM bug. 20 lines of binary parsing did.

Joel — Wed, 05 Aug 2026 02:23:37 +0000

New here (hey 👋) and wanted to share something. We recently made public an ad intel app we'd been using internally in our agency. The app/system runs video ads through Gemini to pull out a transcript, the hook, and a few timed moments. It works fairly well - especially for ideation. The transcription is genuinely accurate.

A user opened a 2:22 video and saw a moment marked at 3:37.

Not a rounding error. Fifty percent past the end of a video the user was looking at.

The part that makes it interesting

The obvious guess is that the model didn't know how long the video was. That would be a reasonable bug and an easy fix.

But in the same JSON response, Gemini reported duration_seconds correctly.

We measured it properly on one ad, four identical runs, same file, same prompt:

Real duration: 142.08 seconds
duration_seconds reported by the model: correct, every run
Transcript timestamps: drifted past the end on 1 run in 4, reaching t=214

The words were right. The clock was 50% long. The model was holding the correct duration and writing impossible timestamps anyway.

That is not a knowledge problem. It's a consistency problem, and those don't respond to being asked nicely.

Prompt hardening didn't work

We tried the things you'd try. State the duration in the prompt. Tell it no timestamp may exceed that. Restate the constraint after the schema. Put it in caps.

Failure rate went down. It didn't go to zero. A hardened run still drifted to t=218 on a 142-second video.

This is where I'd argue the general lesson lives:

If a model can violate a constraint, prompting reduces how often it does. Only code makes it impossible.

For most output that trade is fine, because most output is hard to falsify. Nobody checks whether a "psychological driver" is really the third most important one.

Timestamps are different. A timestamp is falsifiable in one click. The user scrubs to 3:37 on a 2:22 video and the whole analysis loses credibility, including all the parts that were correct. One checkable wrong number poisons everything unverifiable around it.

So we needed a ground truth the model couldn't wander away from.

Ground truth: read it out of the file

The video is already in memory as a Buffer before it goes anywhere near the model. MP4 files carry their own duration in the mvhd atom (movie header). No API call, no dependency, and ffprobe isn't installed on our host anyway.

The layout after the 4-byte mvhd type is: version (1 byte), flags (3), then for version 0 — created (4), modified (4), timescale (4), duration (4). For version 1, the timestamps are 8 bytes and duration is 8.

Duration in seconds is duration / timescale.

function mp4DurationSeconds(buf: Buffer): number | null {
  const limit = buf.length - 24;
  for (let i = 0; i < limit; i++) {
    // scan for the ASCII bytes 'm','v','h','d'
    if (buf[i] !== 0x6d || buf[i+1] !== 0x76 || buf[i+2] !== 0x68 || buf[i+3] !== 0x64) continue;

    const version = buf[i + 4];
    try {
      const base = i + 8; // past 'mvhd' + version(1) + flags(3)
      if (version === 1) {
        const timescale = buf.readUInt32BE(base + 16);
        const duration  = Number(buf.readBigUInt64BE(base + 20));
        if (timescale > 0 && duration > 0) return duration / timescale;
      } else {
        const timescale = buf.readUInt32BE(base + 8);
        const duration  = buf.readUInt32BE(base + 12);
        if (timescale > 0 && duration > 0) return duration / timescale;
      }
    } catch {
      // malformed atom, keep scanning for a valid one
    }
  }
  return null;
}

Two deliberate choices worth explaining.

We scan for the atom rather than walking the box tree. Walking is more correct in principle. Scanning handles both faststart files (moov at the front) and files with moov at the end, without implementing a parser for a container format we only need one number out of.

A malformed atom keeps the loop going instead of throwing. The four bytes mvhd can appear inside compressed video data by coincidence. If you bail on the first match that doesn't parse, a random byte sequence takes down your duration check.

Then enforce it, rather than trusting the enforcement

With a real ceiling, every timestamp gets validated server-side before it reaches the client. Same doctrine as validating any untrusted input, because that's what model output is.

The interesting decisions were about what to do with a bad value, not how to spot one.

Keep the words, drop the clock. The transcription is accurate. Only the timing is untrustworthy. So an impossible timestamp is deleted and the text survives. Our transcript component already renders a blank gutter for a missing t, so a stripped timestamp degrades into a clean script instead of a wrong number.

Null both ends of a pair, not just the bad one. We track "curiosity loops" with an open and a close time. If the close is impossible, nulling only that one leaves a surviving open time next to a blank close, which renders as precision we don't have. Both go.

The bug inside the fix

This one cost me an afternoon and it's pure JavaScript, nothing to do with AI.

The first version coerced timestamps with Number(x). Looks harmless:

// WRONG
const t = Number(chunk.t);

Number(null) is 0.

A model that honestly returns null for "I don't know when this happened" gets that turned into 0, which renders as 0:00, which then reads as a loop closing before it opens, which trips the validation that was supposed to be protecting us. An honest null became a confident lie in one implicit coercion.

const asSeconds = (x: any): number | null => {
  if (x === null || x === undefined || (typeof x === 'string' && !x.trim())) return null;
  const n = Number(x);
  return Number.isFinite(n) ? n : null;
};

Caught by a unit test, thankfully, and not by a user. If you're sanitising LLM output, null and 0 mean completely different things and JavaScript will happily merge them for you.

Not all bad timestamps mean the same thing

The last piece is the one I'd have got wrong without looking at the actual failures.

The observed mode is a drifting tail. The model transcribes accurately the whole way through, but its clock stretches as it goes, so the late chunks are impossible while every earlier timestamp is fine. Those early ones are good data and worth keeping.

Scattered bad timestamps through the body are a different signal entirely. That means the timing pass itself is unreliable, and presenting a mix of right and wrong as though it were precise is worse than presenting nothing.

So: a contiguous run of bad timestamps ending at the final chunk is treated as tail drift and trimmed. Anything else strips all timings.

My first instinct was a percentage threshold, something like "if more than 25% are impossible, drop everything". That's wrong, and the reason is worth internalising:

The same failure would be judged differently depending on how many chunks the model happened to emit. A five-chunk drift is 19% of a 26-chunk transcript and 28% of an 18-chunk one. Identical failure, opposite verdicts, decided by something you don't control. Threshold on the shape of the failure, not its proportion.

What I'd take from this

A model can hold a fact and violate it in the same response. Reporting the duration correctly told us nothing about whether it would respect it.

Prompting sets a tendency. Code sets a guarantee. For anything a user can check in one click, you need the guarantee.

Find the ground truth in the artefact you already have. The buffer was in memory the whole time. We were asking a language model for a number that was sitting in a binary header 20 lines of code away.

Partial output usually beats no output, if you're honest about which part you dropped. The words were always right. Only the clock was wrong. Shipping an accurate transcript with no timestamps is better than shipping either a wrong timestamp or nothing at all.

I build SOCIALFUEL, which pulls the live ads any brand is running and decodes what makes them work. The video pipeline behind it is where this bug lived. If you're doing timed analysis on video with an LLM, I'd check your timestamps against the container before you trust them.