Email+password Provider with BuiltInUI doesn't handle non-existing accounts gracefully

[n2k3]

• EdgeDB Version:
  • Local(dev): 5.3+cc878d8
  • Production: 5.2+ddd8aa4
• EdgeDB CLI Version: 5.1.0+fdf5320 (local only)
• OS Version:
  • Local(dev): Windows 11 Enterprise 23H2 22631.3296 (Microsoft Windows NT 10.0.22631.0 x64)
  • Production: Unknown (the one that comes with the Free tier of EdgeDB Cloud)

Setup:

My EdgeDB client (with the Auth extention) is setup in a Next.js TypeScript project (using v0.3.1 of the @edgedb/auth-nextjs package) with the baseUrl configured with the value of https://www.example.com. I have a landing page with signin button wrapped in a Link component <Link href={auth.getBuiltinUIUrl()}>...</Link>

Steps to Reproduce:

Production:

1. Click the button, fill in (known non-existing account credentials) email (john@example.com) + password (foobar) that do not exist, and press the big Sign In button at the bottom
2. It redirects to the url:
   https://<removed>.edgedb.cloud:5656/db/main/ext/auth/ui/signin?selected_tab=password&error=Could+not+find+an+Identity+matching+the+provided+credentials&email=john@example.com
   and the body result being:
   {"error": {"message": "Missing \"challenge\" in register request", "type": "InvalidData"}}
   (note: there is a challenge in the url before clicking the Sign In in the url search parameters)

---

When I do the above steps exactly the same but on local(dev), the result is handled gracefully within the builtInUI
Redirects to: http://localhost:10701/db/main/ext/auth/ui/signin
and shows an error in above the sign in form:

The work-around that fixes it:

On production, before entering the email + password, I change the part of the url from .../db/edgedb/ext/auth/... to .../db/main/ext/auth/... so the url on production is instead of:
https://<removed>.edgedb.cloud:5656/db/edgedb/ext/auth/ui/signin?challenge=EyO5lgr4...<removed>
it's this:
https://<removed>.edgedb.cloud:5656/db/main/ext/auth/ui/signin?challenge=EyO5lgr4...<removed>
Then it handles the known non-existing account gracefully with the same error as on local.

I also noticed the production instance auth settings gives this as an example:

So the auth.getBuiltinUIUrl() on production is actually redirecting to somewhere else than as stated in the example above.

The extra weird part: after doing this once in a browser session, this now keeps working even with the .../db/edgedb/ext/auth... in the url! Opening a new private window, breaks it again until the work-around is executed again.

I'm confused as to why this is happening, locally vs on production.
Doesn't look like I doing something wrong, but I could've miss-configured something somewhere?
I've tried to explain my issue as best I can, if you have questions, please let me know.

[scotttrinh]

Thanks for the report here, we will look into this. Definitely seems related to the whole database -> branch change we introduced and how we're building these URLs from the current connection configuration (which is 100% dependent upon the environment it is running in).