Timestamps getting updated unexpectedly
Hey
I've got a pretty standard User resource backed by a users PG table and using AshAuthentication
I'd seen some weirdness with users in the past and only just gotten some time to look into it
Basically I've seen cases where
updated_at isn't being updated but other fields are
E.g. this is > 0:
SELECT COUNT(*) FROM users WHERE email_confirmed_at > updated_at;
I can reproduce this locally pretty easily
1. http://localhost:4000/sign-in
2. Request magic link
3. Visit link in email
This updates email_confirmed_at but not updated_at
* email_confirmed_at being updated every time a user signs in with magic link seems like a potential other bug (or misconfig on my side)
Doing something like: User.update!(user, %{display_name: "confirmed"}, authorize?: false) updates updated_at to the current time as expected
Would be great to get some feedback on if this is a bug, intended behavior or if my setup is a borked
And let me know if more info is needed - i can try to get a reproduction repo if it'll help 🙂7 Replies
This is in my
attributes block in pretty much every resource:
timestamps(type: AshPostgres.TimestamptzUsec)If email is already confirmed, it doesnt do anything
hence the .update() is a no-op and no updated_at should be modified
hey, thanks for the response @Oliver
but for whatever reason I am finding
email_confirmed_at to be updated even if already set (i.e. email is already confirmed)Does it actually update? With an update statement
I think it's just a config thing in ash authentication
It sets upsert fields to only email confirmed at
However, that's not necessarily wrong 🙂
Every time you use a magic link
You confirm access to your email
thanks for the input!
yeah I think I can live with that, seems odd initially but could be nice metadata to know
the fact that it's not updating the
updated_at is what gets me as wrong and it seems to be happening for other tables too
i'll try to do some more digging when i get some time as it's probably to ambigious of a problem atm but if anything comes to mind it'd be great to hear 🙂Upserts can choose in their upsert fields option what to affect so I'd be looking there