// writing
Page 6 of 8
Assuming a token refresh returns a new refresh token will permanently kill an integration the first time the provider decides not to. The fix is a single fallback, and a lazier refresh.
A machine-learning model loaded per request will quietly cost you CPU and leak native memory if disposal ever slips. The fix is old: a long-lived handle behind a stateless facade.
Cursor pagination is lovely until you let people sort by an arbitrary column. If the cursor doesn't carry the sort value, it quietly degrades to skipping and duplicating rows at page boundaries.
Half a dozen optional integrations, each able to be missing. Instead of branching everywhere, they degrade to a no-op that still runs the surrounding path. Plus the one no-op that's dangerous.
I started a local-first tool on async in-memory SQLite and kept losing writes. A synchronous native database deleted the whole category of bug. For a single-process app, sync is the safer choice.
The app read its connection string from one key; the deployment supplied a different one. So production quietly ran on an ephemeral SQLite file that vanished on restart, with no error at boot.
The real-time feature looked done: a hub class on the server, a client connected with auto-reconnect. It was quietly updating by polling, because nothing on the server ever actually pushed.
Two quiet Postgres and EF Core decisions that only bite you later: storing a bare local-or-UTC timestamp, and committing a migration without the snapshot it belongs to.
Seed data in a migration felt convenient until I realised it meant a known admin login running on every deployment. On what belongs in a migration and what absolutely does not.
Postgres RLS is a lovely way to enforce tenant isolation in the database, and it has a few quiet ways of being completely bypassed. The ones that caught me.
No matches, try another word.