yarn rw deploy serverless --first-run uses old API_URL

[joconor]

When deploying to AWS via the Serverless framework, the --first-run flag is used to instruct the deployment to create the linkage from the web side to the api side using API_URL. API_URL is not set until after the api side is successfully deployed, at which time the web side knows where to find the api.
However, if API_URL is already set, likely from a prior deploy, even though API_URL is overwritten, the web side is deployed using the prior value of API_URL

Steps to reproduce:

Prerequisites: yarn rw setup deploy serverless has previously been run successfully

1. Ensure .env.production with API_URL does not exist and API_URL is not set elsewhere in the environment
2. Run yarn rw deploy serverless --first-run, answer y when prompted to Add API_URL to your .env.production
3. Observe both api and web sides were successfully deployed and are working
4. Observe that .env.production has been created and API_URL set in that file. Take note of the value of API_URL
5. Navigate to api and perform yarn serverless remove --stage production (Note: AWS keys need to be set in shell environment for this)
6. Navigate to web and perform yarn serverless remove --stage production (Note: AWS keys need to be set in shell environment for this)
7. Observe that both CloudFormation stacks have been removed from AWS
8. Run yarn rw deploy serverless --first-run, answer y when prompted to Add API_URL to your .env.production
9. Observe that API_URL in .env.production has changed
10. Run your application. The front-end will load, but attempts to reach the api (the graphql endpoint) will fail
11. Use the browser developer tools to see what URL the browser is attempting to use when accessing the back-end. You'll see that it is referencing the URL from the prior deployment, the URL noted in step 4, Even though API_URL was set to a different value

[joconor]

Additional verification: In your deployed app's directory, use grep -rl "old-url-here" . to verify that the old API_URL value is present in the deployed web/dist/static/js/app.????????.js file (where "old-url-here" is the API_URL from step 4)

[joconor]

Hypothesis: The first-run process relies on reloading the environment via dotenv-default. See

redwood/packages/cli/src/commands/deploy/serverless.js

Line 181 in e2033ad

loadDotEnvForStage(dotEnvPath)

But if I'm correct, this is similar to another issue I've filed, #5657 , where the issue is caused by dotenv-default (and dotenv) intentionally not overwriting any environment variable already present. So even though the command attempts to reload the environment, it won't ever see any change in any already set variables. See https://github.com/motdotla/dotenv/blob/42eed1f52777b55dde6d241e017839a0083f8f2b/lib/main.js#L83-L86

[dac09]

Adding to core team discussion queue - as it seems like a fundamental difference in philosophy using dotenv defaults.

Desired behaviour: if I supply an env var in my .env, it should override whatever is in my current shell

Thank you @joconor for reporting, and the analysis here.

[thedavidprice]

Been doing some digging on this and can confirm it doesn't work. Effectively, only the yarn rw deploy serverless --first-run command is configured to use .env.production. The Redwood CLI doesn't support this otherwise, which is why it fails otherwise.

Also, this is a close duplicate of #4548

I suggest the way forward here is to remove the .env.production usage entirely from both the --first-run process and the Deploy Serverless documentation