@mark-robustelli Before I move to this activity, I wanted to share an observation that I made just now

So turns out that the error that I posted doesn't turn up every time I open up one of those pages

It occurs when I open those pages consecutively and the CPU spikes to the "requests" range

So to give you an example:

Click on Users -> Takes around 20s to load -> CPU Spike observed but within request range -> No error in container logs

Click on Users -> Immediately click on Reports/Login -> Move to Reports/Registration -> CPU spikes above request range -> Error in Container logs

So could this be a performance tuning issue?

As for your query about the config

Users: 7061
Applications: 6700
Tenants: 8200

Fusionauth is running on GKE on an n2d-standard-8 (8 vCPU, 32 GB RAM) nodepool, I've already mentioned the resources allocated to the deployment via the helmchart in the original thread message^

@dev I am not sure you can set that level of debugging in FusionAuth. You can change logging in the AdminUI for various things like Lambdas, CORS filter, and that sort of thing.

@mark-robustelli

Here is a detailed explanation of my tests.

Modifying /etc/hosts

I added the following entries to my /etc/hosts file:

127.0.0.1 auth.domain.test 127.0.0.1 app.domain.test Nginx Proxy Configuration Authentication Service server { listen 443; server_name auth.domain.test; ssl_certificate /etc/nginx/conf.d/ssl/localhost.crt; ssl_certificate_key /etc/nginx/conf.d/ssl/localhost.key; location / { proxy_pass http://EC2-instance-IP:9011; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header "X-Forwarded-Port" "80"; proxy_http_version 1.1; } } Application Service server { listen 443; server_name app.domain.test; ssl_certificate /etc/nginx/conf.d/ssl/localhost.crt; ssl_certificate_key /etc/nginx/conf.d/ssl/localhost.key; location / { proxy_pass http://app-container:4200; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } Testing Different TLDs

I then replaced the .test TLD with several alternatives to determine which ones worked in this local setup. The tested TLDs and their outcomes are summarized in the table below:

TLD Result .local Failed .test Failed .internal Failed .net Succeeded .org Succeeded .com Succeeded

Nothing changed in all the tests except the TLDs, so I doubt it's an issue with the proxy.

We deciced to use .net for our local dev env and this working fine now for all our develpers.

@mark-robustelli

This is the error shown in the url after oauth2/authorize redirects to redirect_uri:

?error=invalid_request&error_reason=missing_response_type&error_description=The+request+is+missing+a+required+parameter%3A+response_type

At some point I used a combination of these two params in the oauth2/authorize endpoint to prevent it, is this safe to do or may it come with possible drawbacks?

response_type=code response_mode=form_post

Thanks!