Hana Sørby

You are chasing two different bugs, which is why nothing you do fixes both.

Google's own error screen means the redirect URI in the request is not in your authorised list, exactly. Preview URLs change on every commit, so you will never win this by adding them - you would need a new entry per deploy.

Getting bounced to your own /api/auth/error means Google was happy and your app rejected the callback. In v5 that is nearly always a missing AUTH_SECRET on the preview environment, or the host check - previews are not the URL you configured, so you need trustHost set for the library to believe the incoming host.

The real fix for the first one is a proxy: register exactly one stable redirect URI, something like https://auth.yourdomain.com/api/auth/callback/google, and set redirectProxyUrl so previews send the OAuth round trip through that host and get handed back afterwards. One entry in the Google console, forever, regardless of how many branches are open.

Google does not accept wildcards in authorised redirect URIs. Depending on how you enter it you will either get a validation error or it will save and then silently never match anything, which is worse because you will believe it is done.

This is comfortably the most common wrong answer to this problem and it is worth saying out loud every time.

Gradual rollouts exist for this. Even 10% for one hour turns a 812-user incident into an 80-user annoyance you catch on a dashboard before anyone emails you.

Simplest fix is to swap the model for the cheap tier. It's something like 20x less per token, so your $612 becomes $30 and you can stop worrying about the loop entirely.

Two causes, both boring, both in your chart.

The rejections are almost certainly fire-and-forget posts whose response nobody reads. Meter events have an accepted timestamp window; anything you replay from a backlog, a dead-letter drain or a late worker lands outside it and comes back a 400 that goes straight into the void. Log the status code and you will find them in an afternoon.

The dedupe is your retry wrapper. Stripe keeps one event per identifier and it is right to. Your table kept two because you inserted before you sent. Make the identifier deterministic - a hash of the task id, not a uuid generated at send time - and retries become free instead of lossy.

The structural fix is an outbox. Add metered_at and meter_event_id columns to the task row, a worker that fills them, and a query that finds rows older than an hour with metered_at is null. Then the gap is an alert on a Tuesday instead of a discovery at month end.

Ingestion lag is real and it is minutes, not a 6% hole at month end. If the period is closed and the invoice is finalised, the number on the invoice is the number. Waiting a day here just delays finding the actual bug.

Signing config specifically is worth solving once and never touching. Get the credentials managed remotely, verify a build, and then stop having opinions about keystores.

The operational problem with org_id in the token is switching orgs, and it is worth deciding now rather than in six months.

Either you re-mint the token on switch, which is one extra round trip and is completely fine, or you put all memberships in the token and choose at query time, which is also fine until someone belongs to 200 orgs and your cookie no longer fits in a header. Pick the first one unless you have a specific reason.

One caution on security definer: set an explicit search_path on the function. A definer function without one is the classic Postgres privilege-escalation footgun, and it is two words to prevent.

Check that app.config.js is not reading something from process.env at config evaluation time that only exists on your machine. That produces a build whose configuration is subtly different from everyone else's and it is invisible in the diff because the file looks the same.

And inspect it under Application in devtools on both origins, not the response header on the one that set it. The response tab shows you what the server tried to do, which is not the same as what the browser stored.

Alternative shape if the blast radius bothers you: keep the session host-only on the auth origin and give app.example.com its own cookie through a short redirect handshake at login. More moving parts, and the cookie a compromised subdomain can steal is scoped to that subdomain only. Worth it above a certain size, overkill below it.

The included allowance is the part everyone skips and it is the part that makes usage pricing survivable. Same invoice most months, and the overage only shows up when they genuinely got more value.

That works right up until the reason arrives as "we cannot upgrade the SDK", and by then it is urgent, you have no slack, and you are doing the migration and the SDK bump in the same week. Waiting is a real option but it should be a decision with a date on it, not a default.

And if they will export hashes, check the algorithm and parameters too. Getting the hashes is only useful if you can verify against them without asking everyone to reset anyway.

Instrument before you change anything. Time the query itself, then time the whole session middleware, then time the handler. If the query is 0.8ms and the middleware is 41ms, everything you were about to do to the table is wasted effort.

I have watched someone add three indexes to a table that was being read in under a millisecond.

Prebuild once, commit the android folder, edit it directly. That is where most projects end up anyway and it saves you the abstraction.