I’ve got a pending ticket with support that I’d like to share here in case others struggle with the same or related issues.
The query gets users with lucene:
curl -H “Authorization: Bearer $token”
(The token was an API Explorer Client token in this case.)
The query has 3 issues, listed by prio:
- Query returns outdated user_metadata object.
After adding new properties to the user_metadata object, they are visible when browsing the user_metadata editor in the dashboard/user details, but the query returns the old object without the added props.
Query fails with a 503 error (quite) some times.
Query fails with a 500 error in a new tenant before creating a first user.
When you call the query and it doesn’t work, this could be the issue. The response is pasted below. Immediately after creating a user (even if deleting it again), the query starts working (returning
] in case of no users).
Server Error”,“message”:“An internal
We can work around 2 and 3, but 1 is pretty annoying.
Thanks for updating, that’s in line with the support answers and my experience.
on #3, this is particularly relevant for multi-stage deployments.
Multi-stage deployments are done in order to ensure that an auth0 production tenant is flawlessly set up from a deterministic process like a setup script. With that, instead of manually playing around with options until “things work” in production, you play with a script in staging, test it in test, and deploy it one time in prod.
This is of particular importance, because required, in environments with regulated IT (e.g. Good Clinical Practice).
Now there are some other issues with using multi-stage deployments in auth0 that we discovered:
- When you create an auth0 tenant, it may come with different functionality depending on when you open it (e.g. introduction of new client grants happens in newly created tenants only for now)
- Which is fine, but it appears like you can’t make an existing tenant mimic that behaviour
- Also, it seems you can’t “reset” it to remove all your customization to the auth0 default
- and if you try to delete/re-create it: once deleted, a tenant name cannot be simply re-claimed but remains blocked.
So, at the bottomline there’s an issue that your deploy script may work in staging but not in production, and you have no way of “cleaning out” your tenant to ensure just that.
It looks like some of the tenant mechanism is currently under development, so hopefully we’ll have an API controlled “soft reset” that allows us to clean our tenant and set it up with the most recent auth0 default configs.