Al

Put a counter on it. I patch global.fetch in a test that renders the route and assert the number of upstream calls per render is what I think it is. Took twenty minutes to write, has caught two of these, one of which was a dependency's SDK deciding to refresh a token on every request.

Billing regressions are the only regressions where nobody files a bug for six weeks.

This is the single highest-value thing to grep your whole policy set for. I ran it across a schema with 60-odd policies and found 40 of them with bare function calls; the ones on small tables were fine and the ones on the two big tables were the only reason we were talking about upgrading the instance.

Before you change anything, look at the network tab and find the request with ?_rsc= in it during the click. Time it. If that request takes 2.8s and returns one payload, nothing is streaming and you are debugging the wrong layer. If it takes 200ms and streams chunks, your fallback is rendering somewhere you cannot see and it is a CSS/layout problem instead.

Half the "streaming does not work" threads I read are people who never checked whether the response was chunked.

Also worth interrogating whether the reranker is earning 6 seconds. Build a 60 question eval set from real queries, measure recall at 5 with and without it, and look at where it helps.

Half the reranker deployments I have reviewed improved a metric nobody was measuring and cost seconds that everybody noticed.

When you move it, add a test that fires the same action 12 times and asserts the 11th is rejected. Rate limiters are the classic thing that silently stops working after a refactor because nobody ever exercises the unhappy path.

The decision you are actually making is where authorisation lives, and neither option gives it to you.

With route handlers you will write the same six lines of session check at the top of 40 files and forget one. With server actions you will do the same thing, except the forgotten one is directly callable by anyone who can read your JS bundle, because every action is a public endpoint whether you meant it or not.

Write one wrapper - authed(schema, handler) - before you write endpoint number three, and make it impossible to define an action without going through it.

Add the test too: seed two orgs, run your list endpoint as a user in org A, assert zero rows belong to org B. Run it against the real code path, not the query builder. That test would have failed on the PR that introduced this, which is worth more than any review checklist.

Ninety two percent is too high anyway. If you are not failing cards you are not being asked anything.

You did not get walked. You got priced.

One practical thing regardless of which you choose: pick it now and write it into packageManager plus a CI check that fails if a second lockfile appears. The genuinely bad outcome is not choosing wrong, it is having half the team on each and two lockfiles that disagree.

Then get it out of your hands entirely. The test that matters is one sentence: user B cannot see user A's row. Write it once per table as an integration test, seed two users, run it in CI on every migration.

pgTAP if you like your assertions in SQL, or plain test-runner code hitting your real client if you would rather test the path the app uses. I prefer the latter, because the bug is usually not in the policy - it is in the one query that goes around it.

Add a retention rule on the staging area at the same time. Almost every disk-full I have seen was old intermediate output nobody meant to keep.

Disk filling up is the one that is genuinely on you, and it will happen again. Set the alert at 70 percent, not 90.