Hi, we are currently implementing the Recovery Flo...
# talk-kratos
a
Hi, we are currently implementing the Recovery Flow (email/pw, type: code) with Ory Kratos. After doing a successful recovery, the user gets redirected to
/settings?flow=3e...
The following submit on the settings page triggers a POST call to
/self-service/settings?flow=3e...
which leads to a 200 OK What is concerning, Kratos then removes the
state_changed_at
field from the identity, which causes trouble regarding the authentication afterwards. Basically the identity authentication is broken after that. Q: is it intended that the
state_changed_at
property gets dropped by Kratos? If yes, why? Q2: what process drops this property? ty!
I also recognized that
updated_at
field on the identity does not get updated. Is this a bug? šŸ›
I looked into PostgreSQL and indeed state_changed_at gets set to an empty string "", which later does not gets serialized.
Also metadata_public and metadata_admin get set to
null
Looked into the traces and the following update query is run:
Copy code
UPDATE "identities" AS identities SET "created_at" = $1, "metadata_admin" = $2, "metadata_public" = $3, "nid" = $4, "schema_id" = $5, "state" = $6, "state_changed_at" = $7, "traits" = $8, "updated_at" = $9 WHERE identities.id = $10 AND identities.nid = $11
Probably the arguments there are wrong / invalid.
see: persister_identity.go => UpdateIdentity
i
Do you also lose your email verification status? After recovery my email verification status goes from verified to unverified.
a
you mean verifiable_addresses[id].verified? no it stays on verified...
Any comment on this? Ty šŸ™
m
I’m also getting this bug where using
/self-service/settings
will unset the
state_changed_at
Is there any update or fix on this? šŸ™
m
Hello @mysterious-balloon-83741 Please have a look at the issue posted above. I was not able to reproduce the problem on my instance, so please leave some more information in the issue.
a
I actually tried it again for different cases and also can not reproduce it anymore. So state_changed_at does not change. So I guess we can close the issue. If we experience it again I will create a new one... just fyi: "metadata_public": null and "metadata_admin": null is default behavior and nothing to worry about, right?