Cool I’m going to log res.getHeaders() in production to check the issue. Our forest-express-sequelize version is already at ^7.3.1
On my end, your project is marked as 7.3.1, that’s why I was suggesting this potential fix.
Let me know when you are able to do your test to see if at least the CORS headers are correctly computed by your agent 
1 Like
Hi @jeffladiray
I’ve added in log statements to log res.getHeaders() in production. I can see the correct logs when I’m in staging. However, when I switch to Production and go to the Production Admins team and trigger the smart action I cannot even see the log of the smart action endpoint. So the smart action call to the API is not happening. This suggests perhaps it could be some sort of firewall issue that is blocking this particular request. This is the only thing I could think of when discussing this issue with another engineer on my team this morning.
That would mean the OPTION/preflight request is not going through for not having the ACAO header …
Let restart from the beginning 
You don’t have any logs on your agent.
Your code is strictly the same between production and staging.
The request works as expected everywhere else.
Using your custom domain or app.forestadmin.com doesn’t change anything.
Roles for the Production Admin allow usage of the Update Units smart action.
And finally
The request fails in the Production Admins Team in Production, with a OPTION/preflight that fails and, obviously, no call is triggered to your agent via POST.
I’ll clearly discuss this very weird issue with the team, since I’m clueless here.
In the meantime, again, a few questions:
On what kind of provider do you host your forestadmin backend?
Do you have hands on the allowed headers on this provider?
Did you add any middleware that can interfer/modify the current set of headers?
1 Like
Yes that is an excellent summary of the current issue.
Our forestadmin backend is hosted on Google Cloud Platform - it is built in Google Cloud build and then deployed to Google Cloud run.
As far as headers are concerned, we set some of them in the app code. However, some maybe set in GCP hosting and we’re also proxying the domain through a cloudflare worker so some of the headers will be set there too. The only middleware we use ( that I can see anyway ) that modifies the headers is here:
Hope this gives you enough info - let me know if you need any more info
Thanks for all your help - this bug seems to be very tricky
Hi @Mitchell_Lloyd,
After further discussion with the team, let’s eventually try one more thing - Could you add a logging middleware to check the request headers and response headers are correct before and after the CORS middleware?
Even if the preflight fails, you should be able to see the before CORS log of the headers, that might show something interesting.
Let me know if that helps.
1 Like