indigo945

AI slop that lower() was called on

Why do *you* think people move to the cloud?

> friendships: user_a uuid fk auth.users, user_b uuid fk auth.users, status text ('pending', 'accepted'), pk(user_a, user_b), check (user_a < user_b) for canonical ordering so no duplicates. With just these columns, you cannot know who sent the pending friend request and who has to accept it. That will lead to vulnerabilities allowing people to accept friend requests that they themselves have sent. I would recommend keeping pending requests in a separate table (with a more pending-request-specific schema), and only inserting into `friendships` after the request has been accepted. The `user_a < user_b` trick is common and I wouldn't judge it harshly. Just remember that you need two separate BTree indexes, one for `user_a` and one for `user_b`, not just the automatically-created compound index for the primary key (which works as an index for `user_a` only, not for `user_b`). > originally i built this with pg_cron querying users whose last moods.logged_at was >= 2 days ago, inserting into an email_queue table, and another cron picking up the queue and calling resend via pg_net. it worked but debugging failed emails was annoying because pg_net responses are fire-and-forget. Yes, the pg_net async story is ugly if you need to access the HTTP responses. For small apps like yours, doing synchronous HTTP calls with pgsql-http may be an option as well. For scale, an edge function can properly run async and just `select... for share` the mails from the queue. > also not sure if i need an index on (user_id, logged_at desc) or if the primary key covers it. Realistically, with one mood logged per day, it will take many years of logging moods before an index becomes useful here.

More AI slop. It's obvious too that you tried to hide it by lowercasing the slop response. Lazy as hell and what do you get out of this? More fake internet points for your fake stories?

I don't think `getClaims()` ever checks for revocation - even if `getUser()` previously determined that the token has been revoked, `getClaims()` will still let it through. I may be wrong though.

People don't move to the cloud to get multi-region failover or because of real uptime concerns, they move to the cloud because then when stuff inevitably breaks, they can point at the cloud provider and say "see, it's not my fault". Besides, major AWS outages tend to be global anyway, so it's not like failover is super likely to work (especially if your DNS is also hosted on AWS).

I recommend one file per schema, not per table. But you can also do a file per table if that makes sense for your application. Putting everything in the same file is going to cause trouble.