safer error handling

[briskt]

The defaultErrorHandler presently compares the environment against "production" to determine whether it's safe to dump debugging details. When running in staging (or qa, etc.), it is preferable to not have debugging detail since it could be hosted on a public server. This PR reverses the logic so the detailed error message is only used when the environment is "development".

[sio4]

Hi @schparky,

Currently, the main branch is not configured properly. I am working on the cleanup of v1 release and the main will be used for the next version. Did you make the change based on the main branch? Please use v1 branch.

[sio4]

Ah, it looks like you started from the correct branch. I changed the target.

Still failing. I will take a look at this issue.

[sio4]

I tested two things.

1. filed my own PR against v1 branch --> the tests worked fine
2. retry the failed test for this PR after changing merge target --> still failing

The symptom: actions/checkout@v3 keep trying to merge this PR against the last commit of main.

  HEAD is now at 7cc1cdc Merge 13d320b2917516df9d7a8674c9f9b7975c75a0c6 into 89ed84d0d3bf2db8474659131231a0f5117eba27

89ed84d is the latest commit in the main branch.

• Not sure if this issue is the same as: checkout action performing merge commit from incorrect base SHA actions/checkout#27
• or https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs

I tested after delete the last commit 89ed84d from the main branch to see if the action noticed it and merged the PR into the last commit of the main branch, but the action still keep trying to merge into the deleted sha.

[sio4]

This issue was originally discussed in the Slack channel and I think it could be fine. Even though it changes the behavior of error handling for each environment, the direction of this change is narrowing down the scope of a safe place, it could be better.

• The previous behavior: shows the simple error page for production but shows debugging pages for all others
• The changed behavior: shows the simple error page for all other environments, but only shows debugging page when the environment is exactly set as development

This is better from the security point of view and allows users have other custom environment names for their various production-ish environments.

I basically agree that those debugging messages SHOULD only be allowed for a specific narrow environment so != development looks better than == production to me. However, regardless the other values are mentioned in the doc or not, behavior change should be handled carefully so I just ask you to consider them if you are fine. 

[1] https://gophers.slack.com/archives/C3MSAFD40/p1663318963883059

[sio4]

LGTM

[briskt]

Thank you, @sio4