DEV Community: Blogs World

JSONDecodeError: Expecting value at char 0? Read the Error Position Before You Touch the JSON

Blogs World — Wed, 11 Nov 2026 05:26:47 +0000

json.load() fails, the message says Expecting value: line 1 column 1 (char 0), and the file looks fine in your editor. So you paste it into a validator, it passes, and you're stuck.

The fix is to stop guessing. A JSONDecodeError tells you exactly which character the parser choked on (e.pos), and the message itself names the cause. Here are six inputs that break json.load(), the exact error each one produces on Python 3.13, and a 12-line helper that shows you the bad spot.

Six broken inputs, six different messages

import json, codecs, pathlib

p = pathlib.Path
p("empty.json").write_text("")
p("bom.json").write_bytes(codecs.BOM_UTF8 + b'{"name": "Asha"}')
p("single.json").write_text("{'name': 'Asha'}")
p("trailing.json").write_text('{"name": "Asha", "city": "Udaipur",}')
p("jsonl.json").write_text('{"id": 1}\n{"id": 2}\n')

for f in ["empty.json", "bom.json", "single.json", "trailing.json", "jsonl.json"]:
    try:
        with open(f, encoding="utf-8") as fh:
            json.load(fh)
    except json.JSONDecodeError as e:
        print(f, "->", e)

Output on Python 3.13.5:

empty.json -> Expecting value: line 1 column 1 (char 0)
bom.json -> Unexpected UTF-8 BOM (decode using utf-8-sig): line 1 column 1 (char 0)
single.json -> Expecting property name enclosed in double quotes: line 1 column 2 (char 1)
trailing.json -> Illegal trailing comma before end of object: line 1 column 35 (char 34)
jsonl.json -> Extra data: line 2 column 1 (char 10)

Read the message, not just the char number. Each one points to a different fix.

1. `Expecting value ... (char 0)`: there is no JSON at all

char 0 means the parser found nothing it could start with. The usual causes:

The file is empty. Something truncated it, or you opened it with "w" before reading.
It's an HTML page. This is the big one with APIs. requests.get(url).json() on a 404, a login redirect, or a Cloudflare page gives you <!DOCTYPE html>, and json.loads("<!DOCTYPE html>") fails with the exact same char 0 message.
Only whitespace. json.loads(" \n") fails at line 2 column 1 (char 4), which is the end of the string.

For API calls, check the response before parsing:

r = requests.get(url, timeout=10)
r.raise_for_status()
if "application/json" not in r.headers.get("Content-Type", ""):
    raise ValueError(f"Expected JSON, got {r.headers.get('Content-Type')}: {r.text[:200]!r}")
data = r.json()

2. `Unexpected UTF-8 BOM`: the file was saved by Windows tooling

Notepad, Excel exports and some PowerShell commands put three invisible bytes (EF BB BF) at the start. Python even tells you the fix in the message:

with open("bom.json", encoding="utf-8-sig") as fh:
    data = json.load(fh)   # {'name': 'Asha'}

utf-8-sig strips the BOM if it's there and behaves like plain UTF-8 if it isn't, so it's safe to use everywhere you read files you didn't write yourself.

A related trap: PowerShell 5's > redirect writes UTF-16. Opening that with encoding="utf-8" doesn't even reach the JSON parser. It dies with UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0. Reading the file as bytes and passing them to json.loads() works, because json auto-detects UTF-8, UTF-16 and UTF-32 from raw bytes:

data = json.loads(open("u16.json", "rb").read())

3. `Expecting property name enclosed in double quotes`: it's a Python dict, not JSON

{'name': 'Asha'} is what print(my_dict) or str(my_dict) produces. JSON needs double quotes. Fix the writer, not the reader: use json.dump(obj, f) instead of f.write(str(obj)). If you're stuck with old files that were written that way, ast.literal_eval() can read them safely. Don't use eval().

4. `Illegal trailing comma`: hand-edited config

JSON doesn't allow a comma after the last item. Older Python versions report this as Expecting property name enclosed in double quotes, which is confusing. Python 3.13 names it directly. The position (char 34) lands right on the stray comma.

5. `Extra data`: it's JSON Lines, not one JSON document

The first object parsed fine, and then the parser found more at line 2. That's a .jsonl / NDJSON file (one object per line), common in logs and data exports. Parse it line by line:

with open("jsonl.json", encoding="utf-8") as fh:
    rows = [json.loads(line) for line in fh if line.strip()]
# [{'id': 1}, {'id': 2}]

6. The one that doesn't fail: `NaN`

json.loads('{"score": NaN}') happily returns {'score': nan}. Python accepts it, but strict parsers (JavaScript's JSON.parse, most APIs) reject it. If you produce JSON for someone else, use json.dumps(obj, allow_nan=False). It raises ValueError: Out of range float values are not JSON compliant: nan instead of quietly shipping invalid JSON.

A 12-line helper that shows the bad character

When the file is big, line and column numbers aren't enough. Print the bytes around e.pos:

import json

def load_json_debug(path):
    raw = open(path, "rb").read()
    print(f"{len(raw)} bytes, starts with {raw[:4]!r}")
    text = raw.decode("utf-8-sig")
    try:
        return json.loads(text)
    except json.JSONDecodeError as e:
        lo = max(e.pos - 30, 0)
        print(f"{e.msg} at line {e.lineno}, col {e.colno}")
        print(repr(text[lo:e.pos + 30]))
        print(" " * (e.pos - lo + 1) + "^")
        raise

On the trailing-comma file it prints:

36 bytes, starts with b'{"na'
Illegal trailing comma before end of object at line 1, col 35
'me": "Asha", "city": "Udaipur",}'
                               ^

The first line alone catches most cases. 0 bytes means an empty file, b'\xef\xbb\xbf{' means a BOM, b'\xff\xfe{\x00' means UTF-16, and b'<!DO' means HTML.

Quick checklist

Read the message: "Expecting value" vs "BOM" vs "property name" vs "Extra data" are different bugs.
Look at the first 4 bytes of the file or response.
For APIs, check the status code and Content-Type before calling .json().
Read files you didn't write with encoding="utf-8-sig".
Write JSON with json.dump(), never str(dict).

If you want to see where a large document breaks before writing code, paste it into a JSON formatter and validator. It points at the failing line. For the basics of json.load vs json.loads, nested data and writing files back, there's a longer guide on reading JSON files in Python, and a roundup of other common Python errors and how to fix them.

I write practical debugging guides at Blogs World.

pandas merge() Returned More Rows Than You Started With? Catch Duplicate Keys with validate=

Blogs World — Wed, 04 Nov 2026 05:28:03 +0000

You left-joined 4 orders onto a customer table and got back 6 rows. Worse, the revenue column went from 520 to 830, and nobody noticed until the report reached a manager.

merge() did exactly what it was told. A left join keeps every left row, but if a key appears twice on the right, every matching left row is copied once per match. No error, no warning, just quietly inflated numbers.

Here is how to reproduce it, catch it automatically, and fix the three key problems that cause most "wrong row count" merges.

The 6-line reproduction

import pandas as pd

orders = pd.DataFrame({"order_id": [1, 2, 3, 4],
                       "customer_id": [10, 11, 12, 10],
                       "amount": [250, 120, 90, 60]})
customers = pd.DataFrame({"customer_id": [10, 10, 11, 12],
                          "name": ["Asha", "Asha", "Ravi", "Meera"],
                          "city": ["Udaipur", "Jaipur", "Pune", "Delhi"]})

m = orders.merge(customers, on="customer_id", how="left")
print(len(orders), len(m), orders.amount.sum(), m.amount.sum())

On pandas 3.0 this prints:

4 6 520 830

Customer 10 has two rows (an old address and a new one), so orders 1 and 4 each come back twice:

   order_id  customer_id  amount   name     city
0         1           10     250   Asha  Udaipur
1         1           10     250   Asha   Jaipur
2         2           11     120   Ravi     Pune
3         3           12      90  Meera    Delhi
4         4           10      60   Asha  Udaipur
5         4           10      60   Asha   Jaipur

Step 1: Find the duplicate keys

Before blaming the join, look at the lookup table:

customers["customer_id"].value_counts().loc[lambda s: s > 1]
# customer_id
# 10    2

customers[customers.duplicated("customer_id", keep=False)]
#    customer_id  name     city
# 0           10  Asha  Udaipur
# 1           10  Asha   Jaipur

keep=False marks every copy, so you see all the conflicting rows side by side and can decide which one is correct.

Step 2: Make pandas refuse the bad merge

This is the part most tutorials skip. merge() has a validate= argument that checks the relationship you expect and raises if the data disagrees:

orders.merge(customers, on="customer_id", how="left", validate="many_to_one")

MergeError: Merge keys are not unique in right dataset; not a many-to-one merge

The options are "one_to_one", "one_to_many", "many_to_one" and "many_to_many" (which checks nothing). Many orders per customer, one row per customer, is many_to_one. Put this on every merge in a pipeline that feeds a report: it turns a silent wrong number into a loud failure on the day the lookup table changes.

Step 3: Fix the data, not the symptom

Calling drop_duplicates() on the result hides the problem and can drop legitimate rows. Decide which lookup row wins, dedupe the right side, then merge with the check still on:

customers_latest = customers.drop_duplicates("customer_id", keep="last")

m = orders.merge(customers_latest, on="customer_id", how="left",
                 validate="many_to_one")
print(len(m), m.amount.sum())   # 4 520

If you have an updated_at column, sort by it first so keep="last" really means "most recent", rather than "whatever order the CSV happened to be in".

The opposite symptom: rows that should match don't

Sometimes the count is right but half the joined columns are NaN. Add indicator=True to see which rows actually matched:

orders = orders.assign(sku=["A1", "B2 ", "c3", "A1"])
prices = pd.DataFrame({"sku": ["A1", "B2", "C3"], "price": [5, 6, 7]})

m = orders.merge(prices, on="sku", how="left", indicator=True)
print(m["_merge"].value_counts())

_merge
left_only     2
both          2
right_only    0

left_only rows found no partner. Here it is a trailing space in "B2 " and lowercase "c3". Normalize both sides before joining:

for df in (orders, prices):
    df["sku"] = df["sku"].str.strip().str.upper()

After that every row is both.

Two more traps

Mismatched key types. If one side read IDs as numbers and the other as strings (common after read_excel or a JSON API), pandas 3.0 stops you:

ValueError: You are trying to merge on int64 and str columns for key 'customer_id'.

Convert explicitly with .astype(...) on one side. Don't just cast both to str, or 10 and "10.0" will never match.

NaN keys match each other. Unlike SQL, pandas treats missing keys as equal:

import numpy as np

a = pd.DataFrame({"k": [1.0, np.nan], "x": [1, 2]})
b = pd.DataFrame({"k": [np.nan, np.nan], "y": [3, 4]})
a.merge(b, on="k")
#     k  x  y
# 0 NaN  2  3
# 1 NaN  2  4

One missing key on the left just turned into two joined rows. Drop or fill null keys (df.dropna(subset=["k"])) before merging unless you really want them paired.

Quick checklist

Result has more rows than the left table after a left join? The right side has duplicate keys.
Find them with value_counts() or duplicated(..., keep=False).
Add validate="many_to_one" (or whatever relationship you expect) to every merge feeding a report.
Dedupe the lookup table deliberately, not the merged result.
Lots of NaN after the join? Use indicator=True, then strip and normalize case on string keys.
Check that key dtypes match, and drop null keys first.

If you want a refresher on how inner, left, right and outer joins differ (with diagrams and row counts for each), I wrote it up in pandas merge: inner, left, right and outer join examples. When your data starts life in spreadsheets, reading and writing Excel files with openpyxl covers the import side. And if a key column comes from an API, the free JSON formatter on Blogs World makes it easy to spot a stray string ID or trailing space before it reaches your join.

asyncio.gather() Still Takes 2.5 Seconds? Find the Blocking Call with Debug Mode

Blogs World — Thu, 29 Oct 2026 05:25:02 +0000

You wrapped five calls in asyncio.gather(), expecting them to finish in about the time of the slowest one. Instead the total is the sum of all five, exactly as if you had written a plain for loop.

gather() is almost never the problem. Something inside one of your coroutines is blocking the event loop: a call that does real waiting without ever handing control back with await. While it runs, no other task can make progress, so your "concurrent" code quietly turns sequential.

Here is how to prove it in a minute, find the exact culprit, and fix it.

The 10-line reproduction

import asyncio, time

async def fetch_blocking(i):
    time.sleep(0.5)          # looks harmless, freezes the whole loop
    return i

async def fetch_ok(i):
    await asyncio.to_thread(time.sleep, 0.5)   # waits in a worker thread
    return i

async def main():
    t = time.perf_counter()
    await asyncio.gather(*(fetch_blocking(i) for i in range(5)))
    print(f"blocking: {time.perf_counter() - t:.2f}s")

    t = time.perf_counter()
    await asyncio.gather(*(fetch_ok(i) for i in range(5)))
    print(f"to_thread: {time.perf_counter() - t:.2f}s")

asyncio.run(main())

On Python 3.13 this prints:

blocking: 2.50s
to_thread: 0.51s

Same gather(), same five tasks. The only difference is whether the waiting happens on the event loop thread or off it. In real code time.sleep is rarely the offender. It is usually requests.get(), a sync database driver, open().read() on a big file, subprocess.run(), or a CPU-heavy loop such as parsing a large JSON payload.

Step 1: Turn on asyncio debug mode

You don't need a profiler to find the blocker. asyncio has a built-in detector: in debug mode it logs every step of a task that holds the loop longer than loop.slow_callback_duration (100 ms by default).

Enable it any one of these ways:

asyncio.run(main(), debug=True)

PYTHONASYNCIODEBUG=1 python app.py
# or
python -X dev app.py

Make sure warnings from the asyncio logger are visible (for a quick script, logging.basicConfig(level=logging.DEBUG) is enough). Running the example above with debug=True prints one line per offending step:

WARNING:asyncio:Executing <Task finished name='Task-2' coro=<fetch_blocking() done, defined at demo.py:4> result=0 created at .../asyncio/tasks.py:748> took 0.500 seconds

That line tells you the coroutine name (fetch_blocking), the file and line where it is defined, and how long it froze the loop. Five of those lines, each about 0.5 s, add up to your mysterious 2.5 s.

If your real blockers are shorter, lower the threshold so they show up:

async def main():
    asyncio.get_running_loop().slow_callback_duration = 0.02  # 20 ms
    ...

Debug mode adds overhead, so use it locally or in staging, not as a permanent production setting.

Step 2: Narrow it down inside the coroutine

The warning points at a coroutine, not a line. If that coroutine is long, time the suspect calls directly:

t = time.perf_counter()
resp = client.get(url)          # suspect
print("get took", time.perf_counter() - t)

The rule of thumb: any call that waits on the network, disk, or a subprocess and is not preceded by await is a blocker. So is any pure-Python loop that runs for more than a few milliseconds.

Step 3: Pick the right fix

What blocks	Fix
`time.sleep(n)`	`await asyncio.sleep(n)`
`requests`	an async client such as `httpx.AsyncClient` or `aiohttp`
sync DB driver (`psycopg2`, `pymysql`)	an async driver (`asyncpg`, `aiomysql`, SQLAlchemy's async engine), or wrap calls in `asyncio.to_thread`
a sync library with no async version	`await asyncio.to_thread(func, *args)` (Python 3.9+)
CPU-heavy work (big parsing, hashing, image work)	a process pool via `loop.run_in_executor(ProcessPoolExecutor(), func, arg)`

asyncio.to_thread is the quickest unblock for I/O-bound sync code, but remember it runs in a thread pool. Because of the GIL, threads will not speed up pure-Python CPU work, which is why that row goes to a process pool instead.

The FastAPI version of this bug

This shows up constantly in FastAPI, and it is sneaky because the "fix" people try first makes it worse.

@app.get("/report")
async def report():
    data = requests.get(UPSTREAM).json()   # blocks the event loop
    return data

With async def, FastAPI runs the endpoint on the event loop. The blocking requests.get() freezes every other request the worker is handling, so under load one slow upstream makes the whole service look dead.

You have two honest options:

Keep it sync. Declare it as plain def report():. FastAPI then runs it in a thread pool, and the blocking call only ties up one worker thread.
Go fully async. Keep async def and use an async client with await:

@app.get("/report")
async def report():
    async with httpx.AsyncClient(timeout=10) as client:
        r = await client.get(UPSTREAM)
    return r.json()

What you should not do is mix them: async def plus a sync client is the worst of both. If you are still deciding between frameworks for this kind of service, I compared the trade-offs in FastAPI vs Flask: which is better in 2026.

Once it's unblocked: limit concurrency

When the loop is free, gather() fires everything at once, and 500 simultaneous requests can trip rate limits or exhaust a connection pool. Cap it with a semaphore:

sem = asyncio.Semaphore(10)

async def fetch(client, url):
    async with sem:
        r = await client.get(url)
        return r.status_code

async def main(urls):
    async with httpx.AsyncClient(timeout=10) as client:
        return await asyncio.gather(*(fetch(client, u) for u in urls))

On Python 3.11+ you can use asyncio.TaskGroup instead of gather() when you want one failing task to cancel the rest.

Quick checklist

Total time equals the sum of the tasks? Something is blocking the loop.
Run with asyncio.run(main(), debug=True) or PYTHONASYNCIODEBUG=1 and read the Executing <Task ...> took X seconds warnings.
Lower slow_callback_duration if the blockers are short.
Swap sync clients for async ones, or wrap them in asyncio.to_thread.
Send CPU-heavy work to a process pool.
In FastAPI, never put a blocking call inside async def.

If you're newer to async/await and want the fundamentals first (coroutines, create_task, timeouts and cancellation), there's a beginner walkthrough in this Python asyncio tutorial with examples. And when you're debugging the API payloads themselves, the free browser tools on Blogs World, like the JSON formatter, help you inspect responses without pasting them into random sites.

pip Says "Successfully installed", Python Says ModuleNotFoundError: Find the Interpreter You're Actually Using

Blogs World — Fri, 16 Oct 2026 05:29:26 +0000

You run pip install requests. The terminal prints Successfully installed requests-2.32.3. You run your script and get:

ModuleNotFoundError: No module named 'requests'

The package isn't broken and the install didn't fail. In almost every case I've debugged, the package went into one Python and your script is running on another one. A typical machine has several: the system Python, a python.org install, a Microsoft Store Python, maybe Anaconda, plus a virtual environment per project. Each has its own site-packages folder, and a package installed into one is invisible to the others.

So stop reinstalling and ask a better question: which interpreter is running this code, and which interpreter did pip install into?

Step 1: Ask the running Python who it is

Put these two lines at the very top of the failing script, or run them in the same terminal, notebook or editor run button that throws the error:

import sys
print(sys.executable)

Then ask pip where it installed the package:

pip show requests

Look at the Location: line. If sys.executable points to C:\Users\you\project\.venv\Scripts\python.exe and Location: points to C:\Users\you\AppData\Local\Programs\Python\Python312\Lib\site-packages, you've found the bug in thirty seconds. Different interpreters, different packages.

You can also check from the shell which pip and which python your terminal resolves to:

# Windows (CMD or PowerShell)
where python
where pip

# macOS / Linux
which -a python3
which -a pip3

If those lists start with different folders, pip and python don't belong to each other.

Step 2: Install with the interpreter, not with a bare `pip`

The single habit that prevents most of these errors is to never call pip on its own. Call it through the exact Python you'll run:

python -m pip install requests

python -m pip guarantees pip installs into the site-packages of that python. If you want to be completely explicit, use the path you printed in step 1:

C:\Users\you\project\.venv\Scripts\python.exe -m pip install requests

On Windows, the py launcher can pick a version for you (py -3.12 -m pip install requests), but be aware that py doesn't know about your activated venv unless you call python from inside it. Inside a project, prefer the venv's own python.

If python -m pip itself fails with No module named pip, that interpreter has no pip yet. python -m ensurepip --upgrade usually restores it. I wrote up the other recovery paths, including broken venvs and PATH issues, in how to fix ModuleNotFoundError: No module named pip.

Step 3: Check the five places the mismatch usually hides

1. The venv wasn't active when you installed

Virtual environment activation only lasts for that terminal session. Open a new terminal, forget to activate, run pip install, and the package lands in your global Python. Then you activate the venv, run the script, and it isn't there.

Check for the (.venv) prefix in your prompt before installing anything. On Windows:

.venv\Scripts\activate        # CMD
.venv\Scripts\Activate.ps1    # PowerShell

If PowerShell refuses with an execution policy error, Set-ExecutionPolicy -Scope CurrentUser RemoteSigned is the usual fix. My step-by-step venv guide for Windows covers CMD vs PowerShell activation, .venv vs venv naming, and why you shouldn't commit the folder to Git.

2. Your editor picked a different interpreter

VS Code, PyCharm and other editors have their own interpreter setting, separate from your terminal. The terminal can be inside .venv while the Run button uses the global Python.

In VS Code, open the Command Palette, run Python: Select Interpreter, and choose the one inside your project's .venv. The selected interpreter is shown in the status bar. If the error only appears when you click Run but not when you type python script.py, this is your cause.

3. Jupyter is running a different kernel

Notebooks are the worst offender, because the kernel is a separate process. Running !pip install pandas in a cell installs into whatever pip is first on the shell PATH, which may not be the kernel's Python.

Use the magic command instead, which targets the running kernel:

%pip install pandas

Then restart the kernel. import sys; sys.executable inside the notebook tells you which environment the kernel is really using.

4. Multiple Python versions, one `pip`

Installing Python 3.12 doesn't remove 3.11. If pip belongs to 3.11 and python resolves to 3.12, every install goes to the wrong version. The giveaway is the version number inside the Location: path from pip show.

python -m pip fixes this permanently because the pip always matches the python.

5. Your file is shadowing the package

This one isn't an interpreter problem, but it produces confusing import errors. If your script is called requests.py, random.py or pandas.py, or there's a folder with that name next to it, Python imports your file instead of the installed package. You'll see ModuleNotFoundError: No module named 'requests.adapters', or an AttributeError like module 'requests' has no attribute 'get'.

Rename the file, and delete any __pycache__ folder next to it.

A quick note on package names vs import names

Sometimes the install and the import really are different names. pip install beautifulsoup4 gives you import bs4. pip install opencv-python gives you import cv2. pip install Pillow gives you import PIL. pip install python-dotenv gives you import dotenv. If pip show finds the package in the right interpreter and the import still fails, check the import name in the package's docs.

The 60-second checklist

When pip says it installed and Python says it can't find it:

Print sys.executable from the place that fails (script, Run button, notebook).
Compare it with the Location: from pip show <package>.
Reinstall with <that python> -m pip install <package>.
Make sure the venv is active and your editor or kernel points at it.
Check that no local file or folder shadows the package name.

That's all it usually takes. ModuleNotFoundError is one of the most common errors beginners hit, and I cover it alongside fourteen others, with real tracebacks, in Common Python errors: 15 fixes with real examples.

I write practical debugging guides for Python, Laravel, Next.js and Node.js at Blogs World, along with free browser-based developer tools like a JSON formatter and a regex tester.

Next.js App Router 405s: The Export-Name Trap (and Four Lookalikes)

Blogs World — Mon, 12 Oct 2026 05:27:24 +0000

Your frontend fires POST /api/checkout. The Network panel shows 405 Method Not Allowed. The handler you swear you wrote never logs a line.

In the Pages Router era this usually meant a missing if (req.method === 'POST') branch. In the App Router it almost always means something quieter: Next.js never registered a POST handler for that path, so it correctly refuses the method before your code runs.

Here is the trap, four lookalikes that produce the same status code, and a short checklist that ends the guessing.

The trap: wrong export shape

App Router Route Handlers live in app/api/.../route.ts and register methods by uppercase named exports:

// app/api/checkout/route.ts
export async function POST(request: Request) {
  const body = await request.json();
  return Response.json({ ok: true }, { status: 201 });
}

These do not register POST:

// ❌ default export — Pages Router muscle memory
export default async function handler(req: Request) { /* ... */ }

// ❌ lowercase — not a recognized method export
export async function post(request: Request) { /* ... */ }

// ❌ method switch inside a default export
export default async function handler(req: any, res: any) {
  if (req.method === 'POST') { /* ... */ }
}

Next.js supports GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. If the matched route.ts does not export the method the client sent, you get 405 — by design.

Four lookalikes that feel like "my POST is broken"

1. Wrong file path

POST /api/checkout only hits app/api/checkout/route.ts. A file at app/api/checkout/route.tsx, pages/api/checkout.ts, or app/api/checkouts/route.ts will not help. Dynamic segments must match too: /api/tickets/12 needs app/api/tickets/[id]/route.ts.

2. `page.tsx` and `route.ts` at the same segment

You cannot put both at the same route segment. If a page.tsx already owns /api/checkout (unusual but it happens during messy migrations), the Route Handler never mounts the way you expect. Split the paths.

3. Proxy / middleware short-circuit

Next.js has been moving from middleware.ts toward a proxy convention. Whatever sits in front of the handler can return, redirect, or rewrite before your POST export runs. If logs inside POST never fire, inspect the proxy/middleware matcher and early returns next — not the handler body.

4. CORS preflight confusion

A browser cross-origin POST often starts with OPTIONS. If you only exported POST and a gateway or edge layer answers OPTIONS poorly, DevTools can look like "POST failed" when the preflight did. For intentional cross-origin APIs, export OPTIONS (or set headers in config) and verify with a real preflight. A local CORS header tester helps isolate whether the browser is blocked before your handler runs: CORS Header Tester & Generator.

A five-minute triage

Confirm the request URL and method in DevTools (no trailing-slash surprise, no rewrite).
Open the exact app/api/.../route.ts that should own that path.
Confirm an uppercase export async function POST (or whichever method you need).
Add one log on the first line of that export. Redeploy / refresh. If the log never appears, the export is not matched — fix path or export shape before debugging business logic.
If only production fails, check the deployment adapter, basePath, and any CDN rules that strip or rewrite /api.

Migration note (Pages → App)

You can keep pages/api endpoints alive while you migrate UI routes. When you do move an endpoint, rewrite it as named method exports on the Web Request/Response APIs — do not paste a Pages-style default handler into route.ts and expect it to work. For the broader migration checklist (layouts, navigation hooks, async params), see the Next.js App Router vs Pages Router migration guide on Blogs World.

If you are stuck on a stubborn 405 after the export shape is correct, the deeper walkthrough — Proxy matchers, deployment adapters, and App Router-specific pitfalls — is here: Next.js API Route 405 Method Not Allowed Fix (App Router).

Bottom line

A 405 in App Router Route Handlers is usually not a mystery HTTP bug. It means no handler was registered for that method on that path. Fix the export name and the file location first. Everything else is a lookalike.

— Published for developers who would rather spend the afternoon on product work than on route.ts archaeology. More practical guides and browser tools: Blogs World.

Laravel retry_after vs timeout vs backoff: The Three Numbers Behind Duplicate Queue Jobs

Blogs World — Fri, 09 Oct 2026 05:25:57 +0000

A customer gets charged twice. A report email goes out three times. The logs show App\Jobs\SyncInvoice has been attempted too many times even though the job "only ran once" as far as anyone can tell.

When I dig into these, the code inside handle() is almost never the problem. The problem is three numbers that people treat as interchangeable: retry_after, timeout, and backoff. They live in different files, they're owned by different parts of Laravel, and they mean completely different things.

Here's what each one actually controls, and the single rule that keeps them from fighting each other.

1. `retry_after`: "I assume this worker died"

retry_after lives on the queue connection in config/queue.php:

'redis' => [
    'driver' => 'redis',
    'connection' => 'default',
    'queue' => env('REDIS_QUEUE', 'default'),
    'retry_after' => 90,
    'block_for' => null,
],

It is not a retry delay. It's a lease. When a worker reserves a job, the queue gives it retry_after seconds. If the job hasn't been deleted or released by then, the queue assumes the worker crashed and makes the job available again, so another worker can pick it up.

Notice what that means: if your job legitimately takes 120 seconds and retry_after is 90, a second worker will grab the same job at second 90 while the first one is still running. That's your double charge. Each pickup also counts as an attempt, which is how you end up with "attempted too many times" on a job whose business logic never finished.

(SQS doesn't use retry_after; its visibility timeout plays the same role and is configured in AWS.)

2. `timeout`: "kill this job if it runs too long"

Timeout is owned by the worker process, not the connection. You set it on the command:

php artisan queue:work redis --timeout=60

or per job:

class SyncInvoice implements ShouldQueue
{
    public $timeout = 60;
}

When the limit is hit, the worker process is killed (this needs the pcntl PHP extension; without it, timeouts are silently ignored). The job then goes back through the normal attempt rules. If you'd rather a timed-out job fail immediately instead of being retried, set:

public $failOnTimeout = true;

3. `backoff`: "wait before the next attempt"

backoff is the one people think retry_after is. It's the delay before a job that threw an exception is attempted again:

class SyncInvoice implements ShouldQueue
{
    public $tries = 4;

    // 10s, then 60s, then 5 minutes
    public $backoff = [10, 60, 300];
}

Without a backoff, a job that fails because an external API is down gets retried almost instantly, burns through all its tries in a few seconds, and lands in failed_jobs before the API has even recovered.

The rule: timeout < retry_after

The Laravel docs state it plainly, and it's the one line I'd tattoo on every queue config:

The --timeout value should always be at least several seconds shorter than your retry_after configuration value.

That ordering guarantees the worker kills a stuck job before the queue hands it to someone else. Get it backwards and you've built a duplicate-processing machine.

A sane starting point for a job that normally finishes in under 30 seconds:

Setting	Where	Value
Job `$timeout` / `--timeout`	job class or worker command	60
`retry_after`	`config/queue.php` connection	90
`$backoff`	job class	`[10, 60, 300]`
`$tries`	job class	4

If you have one genuinely long job (a big export, video processing), don't raise retry_after for everything. Put it on its own connection with a larger retry_after, and run a dedicated worker with a matching larger --timeout.

Horizon users

Horizon sets the worker timeout per supervisor in config/horizon.php:

'supervisor-1' => [
    'connection' => 'redis',
    'queue' => ['default'],
    'timeout' => 60,
    'tries' => 3,
],

The same rule applies: that timeout must stay below the retry_after of the connection it uses. It's easy to raise one and forget the other during an incident.

Make the job safe to run twice anyway

Even with perfect numbers, a worker can die after charging the card but before deleting the job. Treat "runs at least once" as the contract and make the side effect idempotent:

public function handle(PaymentGateway $gateway): void
{
    $invoice = Invoice::findOrFail($this->invoiceId);

    if ($invoice->paid_at !== null) {
        return; // already done on a previous attempt
    }

    $gateway->charge($invoice, idempotencyKey: "invoice-{$invoice->id}");

    $invoice->update(['paid_at' => now()]);
}

Most payment providers accept an idempotency key, which makes the gateway itself refuse a second identical charge.

A 2-minute audit

Before you change anything else, check these in order:

Open config/queue.php and write down retry_after for the connection you actually use. Confirm QUEUE_CONNECTION in .env points at that connection.
Find the effective timeout: the job's $timeout if set, otherwise the worker's --timeout (default 60), or the Horizon supervisor's timeout.
Confirm timeout is at least a few seconds lower than retry_after.
Check that the job has a $backoff if it calls anything over the network.
Run php -m | grep pcntl on the worker server.
After changing config, run php artisan queue:restart (or horizon:terminate). Long-running workers keep the old config and code in memory until they restart.

That last one catches a lot of people: you fix the numbers, deploy, and nothing changes because the workers never reloaded.

When retries still don't behave

This post covers why jobs run too many times. The opposite problem, a failed job that won't retry at all, has a different set of causes: tries and retryUntil() interacting, exceptions being swallowed inside handle(), queue:retry pushing to a queue no worker is listening to, and Horizon quirks. I wrote that up in detail, with Laravel 11 to 13 differences, here: Laravel Queue Failed Job Retry Not Working: Causes & Fixes.

And if you need to send your .env to a teammate while debugging queue settings, don't paste raw secrets into chat. The free Laravel .env security validator on Blogs World masks passwords and keys in the browser (nothing is uploaded) and flags production risks like APP_DEBUG=true along the way.

What's the worst duplicate-job bug you've hit? I'm curious whether it was the numbers or the missing idempotency check.

Laravel Sanctum 419 Errors: A 5-Request Network Panel Triage

Blogs World — Mon, 05 Oct 2026 05:25:18 +0000

You set up Sanctum for your SPA, hit "Log in", and get 419 Page Expired (or a CORS error, or a 401 right after a "successful" login). Then the guessing starts: flip supports_credentials, add a domain somewhere, clear cache, try again.

There's a faster way. Sanctum cookie auth is a chain of requests, and the browser's Network panel tells you exactly which link is broken. This is the triage order I use before touching any config.

How the chain is supposed to work

For a first-party SPA using Sanctum's cookie (stateful) mode:

The SPA calls GET /sanctum/csrf-cookie. Laravel sets an XSRF-TOKEN cookie and a session cookie.
The SPA sends POST /login. The HTTP client copies XSRF-TOKEN into an X-XSRF-TOKEN header and sends the cookies.
Laravel validates the CSRF token, starts the session, and returns success.
The SPA calls GET /api/user with the same cookies and gets the authenticated user.

A 419 means step 3 failed: Laravel didn't get a CSRF token that matches the session. Everything below is about finding out why.

Request 1: the preflight (OPTIONS)

Open DevTools, tick Preserve log, filter to Fetch/XHR, and log in once. If your SPA and API are on different origins, you'll see an OPTIONS request before the real one.

Check the response headers:

Access-Control-Allow-Origin must be your exact frontend origin (for example http://localhost:3000), never *. Browsers refuse credentials with a wildcard.
Access-Control-Allow-Credentials: true must be present.

If either is wrong, the fix is in config/cors.php:

'paths' => ['api/*', 'sanctum/csrf-cookie', 'login', 'logout'],
'allowed_origins' => [env('FRONTEND_URL', 'http://localhost:3000')],
'supports_credentials' => true,

A common miss: login isn't in paths, so /sanctum/csrf-cookie works but /login gets no CORS headers at all.

Request 2: `/sanctum/csrf-cookie`

You want a 204 with two Set-Cookie headers: XSRF-TOKEN and your session cookie (laravel_session or your app's name).

If the cookies are set but show a yellow warning icon in the Cookies tab, the browser rejected them. Hover the icon; it usually tells you why:

Domain mismatch: SESSION_DOMAIN doesn't cover the host. Use null for plain localhost, or .example.com when the SPA and API share a parent domain (app.example.com and api.example.com).
Secure over HTTP: SESSION_SECURE_COOKIE=true on a non-HTTPS local setup means the cookie is silently dropped.

Request 3: `POST /login` (where the 419 shows up)

Open the request headers and check two things:

Is X-XSRF-TOKEN present? If not, your client isn't reading the cookie. With Axios 1.6.2 and later, cross-origin requests need both flags:

import axios from 'axios';

export const api = axios.create({
  baseURL: 'http://localhost:8000',
  withCredentials: true,
  withXSRFToken: true,
});

Use this one instance everywhere. A second bare axios.post() call somewhere in the codebase is a classic source of "it works on one page but not another".

Is the Cookie header sent? If the header exists but cookies are missing, go back to Request 2. The browser never stored them.

If both are present and you still get 419, Laravel probably isn't treating the request as stateful. Check the next section.

The stateful-domain check

Sanctum only applies session and CSRF middleware to requests from domains listed in SANCTUM_STATEFUL_DOMAINS. The value is a host with port, without scheme:

SANCTUM_STATEFUL_DOMAINS=localhost:3000
SESSION_DOMAIN=null

And in Laravel 11+ make sure stateful API middleware is enabled in bootstrap/app.php:

->withMiddleware(function (Middleware $middleware) {
    $middleware->statefulApi();
})

Two traps I see all the time:

The frontend runs on localhost, but the API is called via 127.0.0.1. To the browser those are different sites, so cookies don't cross over. Pick one and use it everywhere.
You edited .env but config is cached. Run php artisan config:clear and restart the server.

Request 4: `GET /api/user`

If login returns 200/204 but this returns 401, the session cookie from login isn't coming back. Usually that's the same SESSION_DOMAIN or localhost vs 127.0.0.1 mismatch, or the route is protected with auth:sanctum while the request isn't recognised as stateful.

Request 5: the one you shouldn't make

Don't "fix" 419 by adding /login to the CSRF exceptions. It hides the symptom and removes protection from the route that needs it most. If the chain above checks out, Sanctum works with CSRF on.

Quick checklist

[ ] Access-Control-Allow-Origin is the exact SPA origin, not *
[ ] supports_credentials is true, and login/logout are in CORS paths
[ ] /sanctum/csrf-cookie sets both cookies with no browser warning
[ ] X-XSRF-TOKEN header and Cookie header are both on POST /login
[ ] SANCTUM_STATEFUL_DOMAINS includes host and port, no scheme
[ ] Same hostname everywhere (localhost or 127.0.0.1)
[ ] php artisan config:clear after every .env change

If you want to sanity-check what your API actually returns for a given origin before digging into Laravel config, I built a free CORS header tester and generator for exactly that.

For the full Laravel 13 walkthrough, including different-subdomain setups, Next.js server-context gotchas, and a long FAQ, see the complete guide: Laravel Sanctum CORS 419 Error Fix (Laravel 13) on Blogs World.

Laravel Sanctum 419 Error: A 5-Step Debugging Guide

Blogs World — Tue, 08 Sep 2026 12:49:05 +0000

Your Laravel API works.

Your credentials are correct.

/sanctum/csrf-cookie might even return 204.

Then you send the login request:

POST /login

and Laravel responds with:

419 Page Expired

If you've been changing random CORS settings hoping the error disappears, stop there.

A Laravel Sanctum 419 error is usually a CSRF/session authentication problem, and the fastest way to fix it is to identify exactly where the Sanctum authentication flow breaks.

Here's the debugging order I use.

TL;DR

For Laravel Sanctum SPA authentication, verify these five things:

1. Stateful middleware
2. SANCTUM_STATEFUL_DOMAINS
3. CORS credentials
4. Session cookies
5. Axios CSRF handling

And always request:

GET /sanctum/csrf-cookie

before:

POST /login

If one piece of that chain is wrong, Laravel can respond with 419 CSRF token mismatch / Page Expired.

1. Understand What 419 Actually Means

When using Laravel Sanctum's SPA authentication, Laravel relies on normal session cookies and CSRF protection.

The browser flow looks roughly like this:

Frontend
   |
   | GET /sanctum/csrf-cookie
   v
Laravel
   |
   | Sets XSRF-TOKEN
   | Sets session cookie
   v
Browser
   |
   | POST /login
   | Cookie + X-XSRF-TOKEN
   v
Laravel validates request

When Laravel cannot validate that CSRF/session relationship, you can end up with:

419 Page Expired

So the question isn't simply:

"Is my CORS config correct?"

The better question is:

"At which point does the authentication chain break?"

2. Start With the Browser Network Panel

Before touching .env, Axios, or Laravel configuration, open:

Chrome DevTools → Network

Then perform the login again.

Find the first request that doesn't behave as expected.

Case A: OPTIONS fails

If the browser blocks an OPTIONS request, investigate CORS first.

Case B: `/sanctum/csrf-cookie` fails

Your browser isn't successfully initializing Sanctum's CSRF protection.

Case C: CSRF request succeeds but `/login` returns 419

This is where I'd inspect:

XSRF-TOKEN
Laravel session cookie
X-XSRF-TOKEN
cookie domain
Axios credentials
Sanctum stateful domains

Case D: Login succeeds but `/api/user` returns 401

Now the problem is more likely related to the authenticated session or Sanctum recognizing the request as stateful.

This simple classification eliminates a lot of unnecessary debugging.

3. Make Sure Sanctum Treats the SPA as Stateful

Modern Laravel applications can enable Sanctum's stateful API middleware in bootstrap/app.php.

For example:

use Illuminate\Foundation\Configuration\Middleware;

->withMiddleware(function (Middleware $middleware): void {
    $middleware->statefulApi();
})

This matters because Sanctum needs to understand that requests coming from your first-party SPA should use session authentication.

If you're following an older Laravel tutorial, you may see instructions involving:

app/Http/Kernel.php

Be careful.

Laravel's application structure has evolved, so old Sanctum tutorials can send you to configuration locations that aren't appropriate for newer Laravel applications.

4. Check `SANCTUM_STATEFUL_DOMAINS`

Assume your setup looks like this:

Frontend:
https://app.example.com

API:
https://api.example.com

Your SPA host needs to be recognized as stateful.

For example:

SANCTUM_STATEFUL_DOMAINS=app.example.com

One common mistake is adding the protocol:

SANCTUM_STATEFUL_DOMAINS=https://app.example.com

That's not what you normally want here.

Think host, not frontend URL.

localhost can be even trickier

Suppose Vite runs on:

http://localhost:5173

Then you may need:

SANCTUM_STATEFUL_DOMAINS=localhost:5173

Don't casually mix:

localhost
127.0.0.1
localhost:5173
127.0.0.1:5173

Use one consistent development setup.

A surprising number of Sanctum bugs come from tiny hostname differences.

5. CORS Must Allow Credentials

If your SPA authentication uses cookies, your CORS configuration must allow credentialed requests.

A typical setup could include:

return [

    'paths' => [
        'api/*',
        'sanctum/csrf-cookie',
        'login',
        'logout',
    ],

    'allowed_methods' => ['*'],

    'allowed_origins' => [
        'https://app.example.com',
    ],

    'allowed_headers' => ['*'],

    'supports_credentials' => true,

];

The important setting is:

'supports_credentials' => true,

And don't casually do this:

'allowed_origins' => ['*']

when you're relying on cookie credentials.

Specify the frontend origin explicitly:

https://app.example.com

Origin and domain are not the same thing

For CORS:

https://app.example.com

is an origin.

The scheme matters.

These are different origins:

http://app.example.com
https://app.example.com

Meanwhile, Sanctum's stateful domain configuration is concerned with the appropriate host/domain.

Mixing these concepts is one reason Sanctum configuration feels confusing at first.

6. Inspect Your Session Cookie Configuration

Now suppose your architecture is:

app.example.com
api.example.com

Both are under:

example.com

A typical production session configuration might include:

SESSION_DOMAIN=.example.com
SESSION_SECURE_COOKIE=true
SESSION_SAME_SITE=lax

The parent-domain cookie configuration allows the session to work across the relevant subdomains.

After changing environment settings, also remember that cached configuration can make you think your changes aren't working.

Depending on your deployment workflow, refresh Laravel's configuration cache appropriately.

For example:

php artisan config:clear

and rebuild/cache configuration according to your production deployment process.

7. Configure Axios Correctly

Your Laravel setup can be perfect and still fail if the frontend never sends the cookies back.

For Axios:

import axios from 'axios';

const api = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
  withCredentials: true,
  withXSRFToken: true,
  headers: {
    Accept: 'application/json',
  },
});

Before login:

await api.get('/sanctum/csrf-cookie');

await api.post('/login', {
  email,
  password,
});

The two important Axios options are:

withCredentials: true

and:

withXSRFToken: true

Now look in the browser.

After:

GET /sanctum/csrf-cookie

you should normally be able to see the relevant CSRF/session cookies.

Then inspect:

POST /login

and confirm the authentication data is actually being sent back to Laravel.

A Better Way to Debug 419

Instead of changing Laravel, CORS, Axios, cookies, and middleware simultaneously, use this sequence.

Test 1 — CSRF endpoint

Request:

GET /sanctum/csrf-cookie

Expected:

Successful response
+
XSRF/session cookies created

If no cookies appear, don't debug your login controller yet.

Test 2 — Login request

Request:

POST /login

Check:

Are cookies attached?
Is X-XSRF-TOKEN present?
Is the request being blocked by CORS?

If the answer is no, you've narrowed the problem substantially.

Test 3 — Authenticated endpoint

After successful login:

GET /api/user

If login succeeds but this gives:

401 Unauthenticated

focus on:

Sanctum stateful configuration
Session cookie
Cookie domain
withCredentials
Middleware

instead of CSRF.

419 vs 401 vs 422

These errors frequently get mixed together.

419

Usually investigate:

CSRF
XSRF token
Cookies
Session

401

Usually investigate:

Authentication
Session recognition
Sanctum stateful requests
Missing credentials

422

Usually investigate:

Validation errors
Missing fields
Invalid input

Knowing the difference can save a surprising amount of time.

Why Does Sanctum Work in Postman but Fail in Chrome?

This is an extremely common situation:

Postman ✅
Browser ❌

And it's an important clue.

Browsers enforce:

CORS
cookie policies
origins
credentials
SameSite behavior
CSRF flows

API clients such as Postman don't behave exactly like a browser page.

So if the API works from Postman but fails from React/Vue/Vite, start investigating the browser authentication flow, not your database credentials.

Don't "Fix" 419 by Disabling CSRF

You might find solutions online suggesting that you exclude your login endpoint from CSRF protection.

That can make the error disappear.

It doesn't necessarily mean you've fixed Sanctum.

For first-party SPA session authentication, the better solution is to correctly configure:

CSRF
Session cookies
Stateful domains
CORS
Frontend credentials

rather than removing the protection that exposed the configuration problem.

One Production Architecture Detail People Miss

This setup:

app.example.com
api.example.com

is very different from:

my-app.vercel.app
api.example.com

In the first example, the frontend and backend share the same top-level site.

In the second, they're on unrelated domains.

CORS cannot magically turn unrelated domains into the same first-party cookie environment.

So if you're struggling with Sanctum cookie authentication across completely different production domains, revisit the architecture itself.

A custom frontend domain such as:

app.example.com

can make a first-party Sanctum setup considerably cleaner.

My 60-Second Sanctum 419 Checklist

Before searching Stack Overflow again, check this:

[ ] statefulApi() enabled

[ ] SPA exists in SANCTUM_STATEFUL_DOMAINS

[ ] Exact frontend origin allowed by CORS

[ ] supports_credentials = true

[ ] Correct SESSION_DOMAIN

[ ] Secure cookie configuration matches HTTPS setup

[ ] Axios withCredentials = true

[ ] Axios withXSRFToken = true

[ ] /sanctum/csrf-cookie called before login

[ ] XSRF-TOKEN appears in browser

[ ] Session cookie appears in browser

[ ] Login request sends cookies

[ ] X-XSRF-TOKEN is sent correctly

If all twelve are correct, you've eliminated most of the common causes of a Laravel Sanctum 419 error.

The Debugging Order Matters More Than the Fix

The biggest lesson isn't a specific .env setting.

It's this:

Debug the first broken request instead of randomly changing authentication configuration.

Use this order:

OPTIONS
   ↓
/sanctum/csrf-cookie
   ↓
Cookies
   ↓
POST /login
   ↓
/api/user

Find where the expected behavior stops.

That's usually where your real problem begins.

Need the Full Laravel Sanctum 419 Reference?

I wrote a more detailed guide covering Laravel Sanctum CORS, CSRF cookies, Axios configuration, production domains, localhost issues, session configuration, 401 vs 419 vs 422 errors, and deployment troubleshooting.

👉 Read the complete Laravel Sanctum CORS 419 Error Fix guide

Use the full guide when the quick checklist above doesn't expose the problem immediately.

If you're debugging Sanctum today, remember:

419 is the symptom. The browser's request flow tells you the cause.

AI Coding Tools Are Fast. That Doesn't Mean They Make You Faster

Blogs World — Wed, 02 Sep 2026 12:20:43 +0000

AI coding assistants can generate a surprising amount of code in a fo a terrible way to measure whether the tool is actually making a developer more productive.

A 200-line implementation generated in thirty seconds sounds great until you spend the next hour understanding the diff, correcting assumptions, repairing tests, and discovering that the assistant quietly changed something outside the requested scope.

The more useful question is not:

"How much code did the AI generate?"

It is:

"How quickly did I get from a clearly defined problem to a change I would actually be comfortable merging?"

That difference changes how you evaluate tools such as GitHub Copilot, Cursor, Claude Code, Codex, JetBrains AI Assistant, and other coding agents.

Generated Code Is Not Finished Work

Consider two coding assistants.

Tool A generates a complete implementation in five minutes.

Tool B takes twelve minutes.

Tool A looks much faster.

But then you review the results.

With Tool A:

two unrelated files were modified
one existing test was changed to match the new implementation
an edge case was missed
you spend thirty minutes debugging the result

With Tool B:

only the relevant files were changed
existing tests were preserved
a new regression test was added
the implementation passes the project's checks

Tool B was technically slower at generating code.

It was faster at producing usable code.

That is the metric developers should care about.

Measure Time to a Verified Change

A better productivity metric for AI-assisted development is what I think of as verified-change latency.

Start the timer when the task is clearly defined.

Stop it when the change has:

passed the relevant tests
passed linting and type checks
survived code review
avoided unnecessary modifications
preserved existing behavior
satisfied security checks where required

This gives you a much more realistic picture of productivity.

Lines generated per minute tells you almost nothing.

Minutes required per trustworthy change tells you a lot.

Different AI Coding Tools Solve Different Problems

Another mistake is expecting one AI tool to be the best at everything.

Coding assistance now covers several very different workflows.

1. Autocomplete

Autocomplete should feel almost invisible.

You type part of a function and the assistant predicts what comes next.

The important factors here are:

suggestion latency
acceptance rate
understanding of nearby code
consistency with existing naming patterns

For this type of work, a fast editor-integrated assistant can be more useful than an autonomous agent.

You probably don't need an agent planning an entire implementation when all you wanted was to finish a mapping function.

2. Repository Exploration

The problem changes when you inherit an unfamiliar project.

Now you might ask:

Where is authentication actually enforced?

or:

Which services eventually call this database method?

Answering that requires understanding relationships across several files.

This is where repository-aware assistants become much more useful than ordinary autocomplete.

A good assistant should be able to trace the path through the codebase rather than simply explain the file currently open in the editor.

3. Multi-File Implementation

Then there are tasks where the assistant needs to:

inspect the repository
understand the requirement
modify several files
run commands
observe failures
adjust the implementation
report what changed

This is where agent-style tools become interesting.

But autonomy creates another problem:

the bigger the task, the bigger the possible wrong diff.

Giving an agent a prompt such as:

Improve this project.

is asking for trouble.

A much better task looks like:

Fix the failed login attempt counter. Preserve the current API response structure, add a regression test, run the authentication test suite, and do not modify unrelated files.

The completion condition is observable.

Either the relevant tests pass or they do not.

Give the Tool Evidence, Not Just a Problem Description

When debugging with an AI assistant, avoid starting with:

My application isn't working. Fix it.

Provide evidence.

For example:

Command:
npm test -- auth

Expected:
All authentication tests pass.

Actual:
2 tests fail.

Error:
Expected status 401 but received 500.

Relevant behavior:
This started after the refresh-token validation change.

Now the assistant has something concrete to investigate.

For debugging work, I prefer asking the tool to identify the likely root cause before changing anything.

That small instruction makes a big difference.

Otherwise, coding agents often jump straight into editing the first suspicious file they encounter.

Protect Your Tests

One of the easiest ways for generated code to appear correct is to change the test.

Imagine the requirement says:

A user without permission must receive HTTP 403.

The implementation accidentally returns 200.

A bad AI-assisted workflow might change the test expectation from:

expect(response.status).toBe(403);

to:

expect(response.status).toBe(200);

Congratulations. Everything is green.

The bug is still there.

This is why existing tests should be treated as part of the specification unless the requirement itself has intentionally changed.

When using an AI coding agent, explicitly state:

Do not weaken or remove existing assertions simply to make the test suite pass.

That sentence can prevent a surprising amount of nonsense.

AI Review Should Focus on Consequences

AI-assisted code review has another common failure mode: noise.

A review containing twenty comments about variable names is not necessarily useful.

A review identifying one broken authorization path can be extremely useful.

For AI review, prioritize questions such as:

Can this change expose data to the wrong user?
Is error handling missing?
Did the change introduce an extra database query?
Is a null or empty state unhandled?
Can two concurrent requests create inconsistent state?
Did the implementation alter an existing API contract?
Are tests missing for the failure path?

Formatters already know how to complain about spaces.

Use AI review for things that require context.

Security Still Needs Deterministic Tools

An AI assistant can notice insecure code.

That does not make it a security scanner.

If you ask:

Is this application secure?

you will probably receive a confident answer containing several reasonable observations.

You will not receive proof that every relevant vulnerability has been found.

Use dedicated static-analysis, dependency-scanning, and secret-detection tools for concrete findings.

Then use AI to:

explain the finding
trace the affected path
suggest remediation
generate a regression test
help interpret scanner output

The order matters.

Detection first. AI-assisted remediation second. Verification last.

Don't Give an Agent Unlimited Scope

AI agents are particularly effective when the task has boundaries.

Good:

Update the user endpoint to validate email addresses.

Requirements:
- preserve the existing response schema
- return 422 for invalid emails
- add tests for empty and malformed addresses
- run the API test suite
- list the files changed

Not so good:

Improve user management.

The first prompt defines success.

The second defines an adventure.

And adventures create large pull requests.

Repository Instructions Are Underrated

Developers often spend a lot of time improving prompts when the real problem is missing project context.

Your repository should tell an assistant things such as:

Package manager: pnpm

Run tests:
pnpm test

Run type checking:
pnpm typecheck

Architecture:
API handlers live in /src/api
Database access belongs in /src/repositories

Rules:
Do not edit generated files.
Do not modify migrations that have already shipped.
Do not add dependencies without explaining why.

Those instructions are much more useful than trying to invent a magical universal prompt.

AI coding tools are extremely sensitive to context.

Better context usually beats clever wording.

Compare Tools Using the Same Task

If you are deciding between coding assistants, don't compare them using random daily interactions.

Create one small but representative task.

For example, prepare a repository containing:

one failing unit test
one bug spanning multiple files
one simple security problem
one documented completion command

Then give every tool the same task.

Record:

first-pass test result
time to completion
number of correction prompts
files modified
unrelated modifications
whether existing tests were changed
accuracy of the final explanation
time required for human review

Run the test more than once.

Agent output is not perfectly deterministic, so a single successful attempt can be misleading.

I put together a more detailed comparison of current assistants, including GitHub Copilot, Cursor, Codex, Claude Code, JetBrains AI Assistant and specialist review/security workflows, in this AI coding tools comparison for developers.

The useful part isn't picking a universal winner. It is matching the tool to the type of development work you actually do.

The Best AI Workflow Still Has a Human Owner

The most important rule is simple:

Someone must still own the final diff.

Before merging an AI-assisted change, a developer should understand:

what changed
why it changed
what could break
how the change was tested
whether security or data handling is affected
how the change would be rolled back

AI can generate the implementation.

It can run commands.

It can explain the diff.

It can even review parts of its own work.

But the person merging the change still owns the result when production behaves differently at 2 AM.

That responsibility hasn't been automated.

A Simple Rule for Using Coding Assistants

Before accepting an AI-generated change, try to explain it in one or two sentences without looking at the assistant's explanation.

If you cannot explain what the code does, you probably should not merge it yet.

AI coding tools are becoming incredibly capable.

The winning workflow, however, isn't the one that generates the most code.

It's the one that gets you to a small, understandable, tested and reviewable change with the least unnecessary work.

That's a much less exciting benchmark than "10x developer."

It is also much closer to how good software actually gets shipped.

React App Works Locally but Not on Vercel? A Production Checklist

Blogs World — Fri, 21 Aug 2026 12:50:23 +0000

npm run dev works. The production build finishes. Vercel shows a reassuring green Ready label.

Then somebody refreshes /dashboard and gets a 404.

Or the page opens, but login does nothing. The API request is still going to localhost. An image that looked fine on your laptop has disappeared. None of these failures feels related to deployment because, technically, the deployment succeeded.

That green label proves Vercel built and published something. It does not prove that every route, environment variable, browser request, and authentication assumption survived the move to production.

The short answer

If a React app works locally but fails on Vercel, check these in this order:

Run the production build locally.
Confirm the project root, build command, and output directory.
Test a direct visit and refresh on every client-side route.
Check environment-variable names, values, and deployment scope.
Inspect the real API URL, HTTPS, CORS, and cookie settings.
Look for filename-case and asset-path differences.
Read the browser's first Console or Network error before changing configuration.

The order matters. Changing the framework preset will not repair a CORS policy, and adding a rewrite will not install a missing package.

First, separate “deployed” from “working”

A deployment pipeline can answer a few useful questions:

Could it install the dependencies?
Did the build command exit successfully?
Was there an output directory to publish?

It cannot automatically confirm that a user can sign in, that the API accepts the production origin, or that React Router can recover after a hard refresh.

Before debugging in the dashboard, I would reproduce the production build locally:

npm ci
npm run build

For a Vite project, inspect that build with:

npm run preview

For an older Create React App project, you can serve the generated folder locally:

npx serve -s build

This is a better test than npm run dev. Development servers are forgiving. Production builds are much less interested in forgiving a missing dependency, a bad import, or a filename whose capitalization is wrong.

If you are still at the initial setup stage, this step-by-step guide to deploying a React app on Vercel covers the complete GitHub import flow, framework settings, environment variables, SPA routing, and common deployment errors. Here, I want to stay with the awkward part that begins after Vercel says the app is ready.

Three settings quietly control the whole build

Most React deployment problems are not mysterious. Vercel is simply looking in one place while the app is building in another.

Project setup	Build command	Normal output directory
Vite + React	`npm run build`	`dist`
Create React App	`npm run build`	`build`
React app inside a monorepo	Usually `npm run build`	Depends on the selected app and its configuration

The monorepo case is where this becomes easy to miss. If the repository looks like this:

company-project/
├── api/
├── docs/
└── apps/
    └── web/
        ├── package.json
        ├── src/
        └── vite.config.js

then apps/web is the project root. Pointing Vercel at company-project may leave it searching for the wrong package.json or running the correct command from the wrong directory.

There is one more wrinkle: dist is only Vite's default. If vite.config.js contains a custom build.outDir, the Vercel output directory has to match it.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: 'public-app'
  }
})

That app produces public-app, not dist. The setting is not wrong; the two sides just need to agree.

The home page works, but `/account` does not

This failure is almost a rite of passage with a client-side React app.

Clicking from / to /account works because React Router is already running in the browser. Refreshing /account is different. The browser asks the server for /account, and a static host may look for a real file at that path. There is no such file, so the server returns 404 before React gets a chance to render anything.

For a frontend-only Vite single-page application using browser history, add a vercel.json file at the project root:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/index.html"
    }
  ]
}

Commit the file and deploy again. The browser keeps the requested URL, Vercel serves index.html, and the client-side router decides which screen belongs there.

Do not paste a catch-all rewrite into every repository without looking at its architecture. A project that also contains API routes, server-rendered pages, or other separately served paths may need a more specific routing rule. Vercel's Vite deployment documentation is the right reference for the current SPA behavior.

My route test is deliberately boring: paste a nested production URL into a new private window, open it directly, and refresh it twice. Navigation from the home page is not the same test.

An environment variable can be present and still be wrong

There are four separate ways an environment variable can fail:

The name does not match the build tool.
The value belongs to local development.
It was added to Preview but not Production, or the reverse.
It was changed after the current deployment was built.

Vite exposes browser variables through import.meta.env, normally with a VITE_ prefix:

VITE_API_BASE_URL=https://api.example.com

const apiBaseUrl = import.meta.env.VITE_API_BASE_URL

An existing Create React App project uses the older convention:

REACT_APP_API_BASE_URL=https://api.example.com

const apiBaseUrl = process.env.REACT_APP_API_BASE_URL

Those conventions are not interchangeable.

There is also a security trap hidden in the friendly phrase “environment variable.” A VITE_* value used by client-side code is bundled into JavaScript and can be inspected by anyone using the site. Vite's environment-variable guide is explicit about this. Public API base URLs and browser-safe identifiers are fine; database passwords, service-role keys, private payment credentials, and similar secrets are not.

Keep privileged values on a backend or server-side function.

Finally, changing a variable in the Vercel dashboard does not rewrite a bundle that has already been deployed. Build a new deployment after the change, and check whether you edited the Production, Preview, or Development value.

Sometimes the React app is innocent

Open the deployed site, launch DevTools, and look at the failed request in the Network panel. The actual URL usually tells a better story than the UI.

The request still points to localhost

This will never reach the backend on your laptop:

http://localhost:3000/api/products

For every visitor, localhost means that visitor's own device. Replace it with the deployed HTTPS API URL through the correct environment variable.

The page is HTTPS but the API is HTTP

Browsers can block active mixed content. If the frontend is served over HTTPS, the production API should be available over HTTPS too.

The API rejects the Vercel origin

That is a backend CORS decision, not a React build failure. Add the exact production frontend origin to the API's allowed origins. If preview deployments also need API access, decide how those changing preview origins will be handled rather than opening the API to every origin by reflex.

Using cookies? Check Secure, SameSite, the cookie domain, credentialed CORS headers, and whether the browser actually stored the cookie. A response can return 200 while the next authenticated request still fails because the browser rejected the session cookie.

This is why “the API works in Postman” is useful but incomplete. Postman is not enforcing the browser's CORS and cookie rules.

The capitalization bug that waits for production

Some local filesystems treat Header.jsx and header.jsx as though they are the same filename. A Linux build environment does not have to be so generous.

import Header from './components/header'

If the real file is Header.jsx, make the import match exactly:

import Header from './components/Header'

The same issue appears with public assets. /Logo.png and /logo.png are different paths on a case-sensitive system. When only one image or module fails, compare the requested path with the repository filename character by character.

Also confirm that the missing file was committed. Git cannot deploy an image that only exists in your local working directory.

Preview deployments are more than disposable links

Once Git is connected, a branch push can create a Preview deployment while the production branch continues serving the current release. That is useful only if the preview is tested as a real environment.

A sensible flow is:

Push the change to a feature branch.
Let Vercel create the Preview deployment.
Test direct routes, authentication, API calls, and browser errors there.
Merge only after those checks pass.
Verify the new Production deployment once more.

Vercel documents the branch behavior in its Git deployment guide. For applications that can charge cards, send messages, modify customer data, or perform admin actions, point Preview at a staging backend or test account. A hard-to-guess preview URL is not a security boundary.

A five-minute production check

After every meaningful deployment, I would test these before sharing the link:

Open the home page in a private window.
Paste a nested route directly into the address bar and refresh it.
Complete one real sign-in and sign-out cycle.
Trigger one representative API read and, where safe, one write.
Look for the first red Console error.
Inspect failed Network requests and their full URLs.
Check one narrow mobile viewport.
Confirm that Production is using the intended environment values.

It is a small checklist, but it catches more than staring at a green deployment card ever will.

Diagnose by symptom, not by guesswork

What you see	Likely area	First place to look
Build fails	Dependency, import, Node version, or build script	Earliest relevant build-log error and local `npm run build`
Deployment is ready but the page is blank	Runtime JavaScript or missing configuration	Browser Console
`/` works but refreshing `/dashboard` returns 404	SPA fallback routing	`vercel.json` and direct-route test
Requests go to `localhost`	Production API variable	Network request URL
Browser reports a CORS error	Backend origin policy	API CORS configuration
Images fail only in production	Case mismatch or asset path	Requested URL and repository filename
Preview works but Production fails	Environment scope or branch configuration	Production variables and production branch

The first error is normally more valuable than the tenth. Later errors are often just consequences of the first failed import, request, or initialization step.

Frequently asked questions

Do I need to upload the `dist` folder to Vercel?

Not for a normal Git-based deployment. Commit the source code, package.json, and the correct lock file. Vercel installs dependencies, runs the build command, and publishes the generated output. Generated folders such as dist, build, and node_modules are normally ignored.

Why did changing a Vercel environment variable do nothing?

Client-side Vite variables are inserted when the app is built. Redeploy after changing the value, and make sure the variable was added to the environment—Preview or Production—used by that deployment.

Why does React Router work when I click a link but fail after refresh?

Client-side navigation happens after React has loaded. A refresh sends the nested path to the server first. A static SPA needs a fallback rewrite so the server returns index.html and React Router can handle the URL.

Can the React frontend and API use different hosting providers?

Yes. Use the API's deployed HTTPS address and configure the backend to accept the frontend's production origin. Cross-site authentication may also require deliberate cookie and CORS settings.

Is Vercel a good host for every React project?

It is a strong fit for many Vite SPAs, frontend dashboards, prototypes, and applications built for supported serverless or framework patterns. A traditional long-running Express server, background worker, persistent WebSocket process, or content-heavy site needing server rendering has different requirements and should be evaluated separately.

“Ready” is the start of verification

A reliable React deployment is a small contract: the repository supplies a repeatable build, Vercel publishes the correct output, the router can recover on direct requests, the frontend receives the right public configuration, and the backend accepts requests from the deployed origin.

When one part of that contract breaks, start with evidence. Build locally. Open the first browser error. Read the failed request URL. Change one verified cause at a time.

That approach is slower than random dashboard edits for about thirty seconds. After that, it is much faster.

_Disclosure: This article was prepared with AI assistance. Its technical examples were checked against the linked Vercel and Vite documentation.

Java’s `this` keyword helps distinguish fields from parameters, chain constructors, and reference the current object. Practical examples: https://www.blogs-world.in/blog/understanding-the-this-keyword-in-java-a-comprehensive-guide/

Blogs World — Tue, 18 Aug 2026 08:08:08 +0000

Mastering this in Modern Java — 2026 Developer Playbook

Master the this keyword in Java with clear examples, best practices, and advanced tips for cleaner, bug-free code. Boost your Java skills today!

blogs-world.in

I Kept Reaching for Redux by Default. One Question Fixed That

Blogs World — Tue, 18 Aug 2026 07:50:31 +0000

There's a specific kind of shame that comes from opening a pull request review and seeing npm install @reduxjs/toolkit react-redux as the first line of the diff, for a feature that turned out to be a dropdown and a boolean.

I did that more than once. Not because I didn't understand Redux. Because I didn't have a real test for when not to reach for it, so I defaulted to the tool that felt "serious."

The habit nobody tells you to unlearn

Early in my React years, the advice I absorbed from tutorials was basically: small app, use useState. Big app, use Redux. That's a size-based rule, and size is a terrible proxy for what actually matters, which is how the state behaves, not how many files your project has.

A five-screen internal tool with a workflow editor, undo history, and three roles fighting over permissions? That probably wants Redux. A forty-page marketing site with a theme toggle and a mobile nav state? That's Context, maybe not even that.

I learned this the slow way, on a dashboard project where I'd wired notification counts, a selected-workspace value, and a live job feed all into one AppContext. It worked fine in the demo. Then someone added a fourth thing to that context, a component three levels down started re-rendering on every WebSocket tick, and I spent an afternoon staring at React DevTools trying to figure out why a settings icon was blinking every two seconds like it had a heartbeat.

What actually separates the two tools

Here's the reframe that fixed it for me, and it's less "which library" and more "what job is this state doing."

Context is a plumbing solution. It moves a value down the tree without prop drilling. That's it. It doesn't care where the value came from or how it changes — you could feed it a useState, a useReducer, or a hardcoded object, and Context wouldn't know the difference.

Redux is an architecture. Actions, reducers, a single store, a predictable flow of "this happened → here's the new state." You get that structure whether you need it or not, and for small, cohesive values, that structure is overhead, not help.

So the actual decision isn't Context vs Redux. It's closer to:

useState / useReducer + Context
        vs.
Redux Toolkit + selectors

Once I started asking "does this state need an architecture, or does it just need to reach three components without fifteen props," most of my choices got obvious fast.

A quick gut-check I actually use now

Three questions, roughly in this order:

Who owns this? One feature tree, or does it get read/written across totally unrelated routes?
How does it change? A handful of clean transitions, or a tangle of business rules that touch five other pieces of state?
Who's subscribing? Do consumers basically all need "the same thing," or does one tiny badge need to react to a firehose of updates without the rest of the screen re-rendering?

If the answers land on "one feature, simple transitions, everyone wants the same value" — Context, and honestly probably just useReducer + Context, no extra library required.

If it's "read everywhere, complicated rules, and only slivers of it change independently" — that's where Redux Toolkit's selector model starts paying for its setup cost.

The mistake I don't make anymore

I used to think memoizing everything in a context provider was the fix for re-render pain. useMemo on the value, useCallback on every handler, wrap, wrap, wrap. It helps with accidental identity changes — a new object reference on every render for no reason — but it can't give you the thing Redux's useSelector gives you for free: a component subscribing to one slice of a much bigger state tree.

Memoization fixes noise. It doesn't fix architecture. If you're three layers of useMemo deep just to stop unrelated components from updating, that's usually a sign the state itself is trying to tell you something — probably that it's outgrown Context, or that it was never one cohesive value in the first place and needs splitting into separate providers.

That second one, by the way, is underrated as a fix. Before reaching for Redux, try just... splitting the context. A ThemeContext and a NotificationsContext and a WorkspaceContext instead of one AppContext solves a surprising number of "why is everything re-rendering" problems on its own.

Where I landed

These days my default order looks something like: local state first, always — don't be the person adding global anything for two props. Context next, for stuff that's genuinely shared but genuinely simple. Redux Toolkit only once I can point at real coordination complexity — multiple features reacting to the same event, selectors doing real work, or a debugging need that "just add a console.log" won't satisfy anymore.

And API data doesn't go in either bucket, honestly. That's a separate problem — caching, refetching, staleness — that neither Context nor a hand-rolled Redux slice handles well without a lot of extra plumbing you're better off not building yourself.

I went looking for a writeup that laid out the decision framework more rigorously than my "vibes and a bad afternoon" version, and found a genuinely thorough one — includes a full decision framework, side-by-side code for both approaches, and a section specifically on the failure modes (the universal-context trap, memoizing a design problem instead of fixing it, stuffing every form input into Redux) that I definitely lived through firsthand. Worth the read if you're mid-decision on a real feature right now: React Context API vs Redux: When to Use Each.

If you've got your own "I reached for the wrong tool and paid for it" story, I'd genuinely like to hear it in the comments. Misery loves company, and also I collect these for the next time I'm tempted to npm install my way out of a design decision.

DEV Community: Blogs World

JSONDecodeError: Expecting value at char 0? Read the Error Position Before You Touch the JSON

Six broken inputs, six different messages

1. Expecting value ... (char 0): there is no JSON at all

2. Unexpected UTF-8 BOM: the file was saved by Windows tooling

3. Expecting property name enclosed in double quotes: it's a Python dict, not JSON

4. Illegal trailing comma: hand-edited config

5. Extra data: it's JSON Lines, not one JSON document

6. The one that doesn't fail: NaN

A 12-line helper that shows the bad character

Quick checklist

pandas merge() Returned More Rows Than You Started With? Catch Duplicate Keys with validate=

The 6-line reproduction

Step 1: Find the duplicate keys

Step 2: Make pandas refuse the bad merge

Step 3: Fix the data, not the symptom

The opposite symptom: rows that should match don't

Two more traps

Quick checklist

asyncio.gather() Still Takes 2.5 Seconds? Find the Blocking Call with Debug Mode

The 10-line reproduction

Step 1: Turn on asyncio debug mode

Step 2: Narrow it down inside the coroutine

Step 3: Pick the right fix

The FastAPI version of this bug

Once it's unblocked: limit concurrency

Quick checklist

pip Says "Successfully installed", Python Says ModuleNotFoundError: Find the Interpreter You're Actually Using

Step 1: Ask the running Python who it is

Step 2: Install with the interpreter, not with a bare pip

Step 3: Check the five places the mismatch usually hides

1. The venv wasn't active when you installed

2. Your editor picked a different interpreter

3. Jupyter is running a different kernel

4. Multiple Python versions, one pip

5. Your file is shadowing the package

A quick note on package names vs import names

The 60-second checklist

Next.js App Router 405s: The Export-Name Trap (and Four Lookalikes)

The trap: wrong export shape

Four lookalikes that feel like "my POST is broken"

1. Wrong file path

2. page.tsx and route.ts at the same segment

3. Proxy / middleware short-circuit

4. CORS preflight confusion

A five-minute triage

Migration note (Pages → App)

Bottom line

Laravel retry_after vs timeout vs backoff: The Three Numbers Behind Duplicate Queue Jobs

1. retry_after: "I assume this worker died"

2. timeout: "kill this job if it runs too long"

3. backoff: "wait before the next attempt"

The rule: timeout < retry_after

Horizon users

Make the job safe to run twice anyway

A 2-minute audit

When retries still don't behave

Laravel Sanctum 419 Errors: A 5-Request Network Panel Triage

How the chain is supposed to work

Request 1: the preflight (OPTIONS)

Request 2: /sanctum/csrf-cookie

Request 3: POST /login (where the 419 shows up)

The stateful-domain check

Request 4: GET /api/user

Request 5: the one you shouldn't make

Quick checklist

Laravel Sanctum 419 Error: A 5-Step Debugging Guide

TL;DR

1. Understand What 419 Actually Means

2. Start With the Browser Network Panel

Case A: OPTIONS fails

Case B: /sanctum/csrf-cookie fails

Case C: CSRF request succeeds but /login returns 419

Case D: Login succeeds but /api/user returns 401

3. Make Sure Sanctum Treats the SPA as Stateful

4. Check SANCTUM_STATEFUL_DOMAINS

localhost can be even trickier

5. CORS Must Allow Credentials

Origin and domain are not the same thing

6. Inspect Your Session Cookie Configuration

1. `Expecting value ... (char 0)`: there is no JSON at all

2. `Unexpected UTF-8 BOM`: the file was saved by Windows tooling

3. `Expecting property name enclosed in double quotes`: it's a Python dict, not JSON

4. `Illegal trailing comma`: hand-edited config

5. `Extra data`: it's JSON Lines, not one JSON document

6. The one that doesn't fail: `NaN`

Step 2: Install with the interpreter, not with a bare `pip`

4. Multiple Python versions, one `pip`

2. `page.tsx` and `route.ts` at the same segment

1. `retry_after`: "I assume this worker died"

2. `timeout`: "kill this job if it runs too long"

3. `backoff`: "wait before the next attempt"

Request 2: `/sanctum/csrf-cookie`

Request 3: `POST /login` (where the 419 shows up)

Request 4: `GET /api/user`

Case B: `/sanctum/csrf-cookie` fails

Case C: CSRF request succeeds but `/login` returns 419

Case D: Login succeeds but `/api/user` returns 401

4. Check `SANCTUM_STATEFUL_DOMAINS`

The home page works, but `/account` does not

Do I need to upload the `dist` folder to Vercel?