https://www.ory.sh/ logo
Join Slack
Powered by
hey, we’re seeing an issue since yesterday around ...
# ory-network
k
hey, we’re seeing an issue since yesterday around 17:30 UTC where updates to identities are not reflected immediately in 
GET /whoami
responses…
👀 1
🆘 1
I’m still trying to create a repro for the issue but maybe someone knows something…
this is causing our registration process to fail
f
@high-optician-2097 can you take a look please?
h
Hi, yes, investigating
When and how are you updating the identity? Are you using the Admin API? Are you doing it with a hook? Are you calling 
/session/whoami
inbetween? We released a new feature to production yesterday which significantly decreases latency in any world region. The downside is that changes from the admin API are not immediate but instead eventually consistent. We have a new feature in the pipeline which allows the client to decide how old the content can be using 
Cache-Control: max-age=0
. This is not yet rolled out but will be rolled out by end of day.
sorry, i mean significantly decreases latency lol
For some regions (e.g. australia) latency has dropped from 1.5s to 50ms
k
ok, so the response from 
PUT /admin/identities/{id}
would signal success but the result isn’t immediately reflected in 
GET /sessions/whoami
?
h
Exactly, the first request to 
/session/whoami
can in some cases be stale. The second request to the endpoint will always be fresh (unless you’re requesting them too quickly after one another). By tomorrow you can do:
Copy code
GET /session/whoami
Cookie: the-cookie
Cache-Control: max-age=0
and it will always return a fresh response, but it also will be slower
t
this is quite a significant behavioural change to make without an announcement. I understand that the API is in pre-release state and as such breaking changes are to be expected. but doing so without an announcement is not quite what I would expect. we've been relying on the changes to be synchronous, so our registration flow has now been broken since yesterday evening. obviously that's quite a severe incident for us
🙌 1
k
our flow is that our FE makes a call to the BE, which in turn adds some metadata to the user’s identity (synchronously); when this request completes, FE refreshes the identity from 
/sessions/whoami
(about 2 seconds after the request to BE completed) and the metadata is not updated
h
can in some cases be stale
...which wasn't the case before yesterday, and our FE relies on 
metadata_public
to know if we created our own identity related to this Ory instance
h
Understood, we’ll disable this behavior for now and enable it on a per-project basis with a feature flag & provide the appropriate announcements 🙂
🙌 2
t
thanks, I appreciate the quick reaction!
h
Ok, it’s disabled now - propagation will take a few minutes
Sorry for the inconvenience - we thought that it would be ok for admin API changes to be eventually consistent but obviously did not factor in that some rely on this mechanism for post-registration hydration
k
thanks 👍
I can confirm that the behavior works as previously and registration is succeeding 🙇
👍 1
h
Is setting 
max-age=0
an acceptable solution for ya’ll to ensure that the cache isn’t stale? It’s basically the same behavior as the API had prior. You can control how old the cache should be using e.g. 
Cache-Controle: max-age=60
which would say that you’re fine if the session cache is 60 seconds old and if it is older the server should revalidate. Generally, we always revalidate the cache in the background, so the second request is always fresh
t
generally speaking I think the change makes sense of course. in our case we've been relying on the current behaviour because it makes our flow simpler as we don't have to handle the complexity of eventual consistency. we can adapt of course, but it would be ideal to have a couple of weeks of warning for breaking changes of any kind so we can plan & prioritize tickets in the upcoming iteration.
h
Yes makes sense, I think we’ll make this opt-in for now and ask for people to set max age explicitly if they’re ok with cached responses
Should have done this from the start - we probably got too excited by the performance improvements 😉
h
the post-registration flow is definitely might be a complication for a lot of projects. in our case we have a lot of data propagated after Ory reg. due to business requirements. ideally, we should be able to pass all the needed data to the Ory call (from the FE side) and Ory should be able to pass this custom data further for end usage.
h
Would web hooks help that modify the user before saving them in the DB?
h
I assume that is the way: basically, from FE side instead of calling async: 1. Ory (for account creation) and then 2. our BE to create a user that will be propagated to Ory we would just call Ory with all the needed data propagated and BE will take care of creating an account in our system on successful Ory creation
k
technically we could do it through ory webhooks but most of the data is either: • just for registration and not really something we’d want to put in either metadata/traits, to avoid messing too much with identity schemas • mutable, so putting those in the identity also forces us to keep them in sync
what I think would work for us could be something that’s “registration-only” metadata that you could add to 
POST /self-service/registration
so it gets fed into the webhook but not persisted otherwise…
so you’d add something like to the 
POST /self-service/registration
request
Copy code
"registration_props": {
  "referral_code": "abcdef"
}
and the webhook would include that data (but not persist it in the identity in any way)
🥲 1
h
Our idea was that the webhook is able to modify the identity data. So basically you can respond with:
Copy code
{identity: { traits: { name: 'asdf' } }}
this would then also be already reflected in the session
🙌 1
👀 1
3 Views
Open in Slack
PreviousNext
Powered by