Name Resolution of App's Current URL Failing Internally (SSR) - Happening for others?

1

I have been developing an App on Fly.io that for some reason started having issues yesterday. The application is deploying just fine but I then found that the applications login pages had stopped working.

After some deep debugging I have found that this seems to be related to DNS resolution of my Next.js Application whilst rendering server side.

I am utilising next-auth for authentication and the sign up page (and others) use fetch to make API calls when server side using the canonical URL of the application (IE [appname].fly.dev). This does not seem to be resolving and is causing a TypeError: fetch failed error which is indicative of a bad URL.

This was working fine previously so I’m wondering if something has changed / is there a current issue?

Just to confirm that this was an issue I have also SSH’d into the running instance, installed curl and tried to curl the apps external address and got a similar error.

What would be the correct address to call when wanting to talk to the local machine? as http://localhost:8080 also seems to fail when using fetch (Although it does work through curl oddly). Reason I ask is that next-auth did implement a NEXTAUTH_URL_INTERNAL env var that can be used for situations like this.

2

Hmmmn - This just seems to have been resolved for me :tada:

Glad that is the case even though I spent a long-time last night and this morning debugging … :person_facepalming:.

Was there a known issue that has been fixed or does it need reporting for investigation to try and stop in the future etc?

3

Maybe I spoke too soon … One of my App deployments has started working and resolving its own canonical URL when server side but another has not ?! :face_with_spiral_eyes:…

4

same problem :slightly_frowning_face:

5

So I did find a URL when server side of http://127.0.0.1:8080 did work for server side calls, however next-auth has not fully implemented their NEXTAUTH_URL_INTERNAL env var and it is not used for unstable_getServerSession calls so I can’t work around this issue at the moment :frowning: … Trying to submit a separate issue to next-auth now.

p.s. for extra info my applications are in the lhr region.