I’m configuring the Scout addon for my rails application using the config/scout_apm.yml file but the key isn’t being picked up so my application isn’t connecting to Scout.
Running the rake scout:doctor rails command through the Render shell shows that the key is being set to nil by an environment variable (see screenshot)
I can also find the SCOUT_KEY in the rails env variables set to nil with this ENV.keys['SCOUNT_KEY'] #=> nil.
Issue:
Blank SCOUT_KEY env variable is overwriting yaml config. My app doesn’t have a SCOUT_KEY env in it’s settings.
Assuming SCOUT_KEY is set somewhere by Render after installing a global addon?
Can confirm SCOUT_KEY is being set to nil in another rails app running on Render where the Scout gem not installed.
Temporary Fix:
Override nil value by setting SCOUT_KEY in my app’s env variables.
Expected behaviour:
Blank SCOUT_KEY shouldn’t exist in my app’s env variables.
I would like all my credentials to live in the rails config/credentials.yml.enc file so the app if fast & easy to port to other environments and providers with minimal ENVs.
Ideally, even if the addon correctly populates the SCOUT_KEY, I would like the choice to remove it so the yaml file credentials are used.
When I check your service by logging in through the shell, I see that the SCOUT_KEY environment variable is set correctly (I ran printenv SCOUT_KEY) . It looks like something in your process itself is changing the environment variable.
To debug, you might want to update your start command to start with printenv SCOUT_KEY && to confirm that it’s present before your process starts, which should help you narrow down where it’s getting overwritten.
Yep, that’s because I implemented the temporary fix, described in my message above, because I wanted Scout to work
As I mentioned in my message above, I saw the same problem in a completely separate Render Rails app that didn’t have the scout gem installed or any scout logic in the code.
Thanks for helping me understand better—I was misinterpreting what the problem was. You’re right: we’re setting empty values for the environment variable.
We’ve identified the source of the issue and are deploying a fix now. I’ll update this thread when the fix has been released.