I would try creating another tenant and seeing if the same SMTP settings fail. Then I'd try standing up a version with the very latest FusionAuth version and seeing if you see the same behavior.

Also, do you have the same tenant smtp settings? That is under the "advanced" tab, then "smtp settings".

I'm going to have to talk to sales as I want to enable the features temporarily to use it as a POC. Also so I can justify the cost per month for actual support beyond forums.

Thank you for your time.

The documentation says that this is optional. But not in my case.

Can you elaborate on where you found this in the doc?

The error should say missing "X-FusionAuth-TenantId"

Can you elaborate on this?

When I get back the "code" do I need to manually convert it to a token, or is this done automatically?

You may want to review our OAuth guide. Using a OAuth2 flow, it is common to have two separate endpoints (authorize and token) to obtain access. The "code" is returned from FusionAuth and is used (in conjunction with a few other possible factors) to obtain an access token (in our typescript client, this is the client.exchangeOAuthCodeForAccessTokenUsingPKCE function)

We do have a few tutorials as well, that show this in action (nodeJS tutorial being one of them)

Lastly, for general housekeeping's sake, this thread is getting a bit long, with a few related posts clumped together. For future questions, if the question is unrelated to the posts immediately above, it might be good to open a new thread.

But if I put these in the application, won't this be a security problem?

If you put them in a javascript app, yes. But if they are in the php application only, then it'll be like a database password. Not really a security issue.

You could also inject them as an environment variable or pull from a secrets manager; however you manage your database credentials, I'd suggest doing the same with the client id/secret.

#FROM fusionauth/fusionauth-app:1.19.4

and we replaced it with:

FROM fusionauth/fusionauth-app:1.19.7

Best Regards,

Glad that you are able to figure it out. I am not sure if that qualifies as a bug, but definitely something to be aware of and might be worth calling out in our documentation.

I believe that you should have email templates after a kickstart (at least the default ones). I can do some more testing to see if that same thing happens to me when I kickstart.

Thanks,
Josh

I'll send you a message.

@it-contracts Can you please share the OAuth settings you have for your application? In the Fusion Auth Admin UI select Applications. Select Edit or view for your application. Share the OAuth and JWT settings. Be sure to remove any sensitive information before posting here.

I did not make any settings in JWT, so there is nothig there.

In the OAUTH section here's what I have:

That's it.
Thank you Mark
Rudy

I’ve been investigating the issue over the last few weeks.

Having taken a JVM dump while the issue was occurring, here is the stack trace for the thread causing the deadlock

I enabled trace logging in io.fusionauth.http.server.internal to analyse the process in HTTPWorker

The HTTPWorker begins the process of reading and writing the response for the request, and continues for 2.6 minutes until the HTTPServerThread terminates it because the minimumWriteThroughput (16KB/sec) threshold has not been met.

HTTPServerCleanerThread kills the server-side connection mid-response due to a write throughput check that measures average bytes/sec since the first socket write.
The client is waiting for data that the server is generating very slowly.

Analyzing why the server is writing so slowly (16271 bytes/sec):
The call is http://localhost:9012 — FusionAuth calls itself. Client and server virtual threads share the same JVM's carrier thread pool.
With Kubernetes CPU limit = 1000m, JDK 21 uses UseContainerSupport (default), so availableProcessors() = 1 → only 1 carrier thread.

com.inversoft.rest.JSONResponseHandler$BetterBufferedInputStream.read(byte[], int, int) is synchronized — causes virtual thread carrier thread pinning in JDK 21.

BetterBufferedInputStream.read() pins that single carrier thread while blocking on ChunkedInputStream.fastRead(), leaving no carrier thread for the server to write more data. The resulting ping-pong limits throughput to ~16 KB/sec on a 2.5MB response.

HTTPServerCleanerThread computes average throughput since the very first write (not a recent window). With 2.5MB written at 16271 bytes/sec average, that's ~156 seconds (2.6 min) before the average decays below the 16384 bytes/sec threshold.

With 9 themes, the response is small enough to fit entirely within the kernel’s socket buffer (~128KB). The server writes the entire content in one go without blocking on socket.write() (the buffer does not fill up), transitions to the KeepAlive state, and the cleaner can no longer terminate the connection due to write throughput.

As a workaround, I resolved the issue increasing the Kubernetes CPU limit from 1000m to 1050m.
Kubernetes translates the CPU limit into the container’s cgroups, setting 2 carrier threads instead of 1.

With that CPU limit, all themes are recovered properly, also with 35 themes (~6.2 MB response).

Can you reproduce it setting Kubernetes CPU limit to 1000m (1 core) in your environment?