-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Allow stack traces in HTTP responses only if INCLUDE_STACK_TRACES_IN_HTTP_RESPONSE
is enabled
#12938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Currently, only patch changes are allowed on main. Your PR labels (semver: minor) indicate that it cannot be merged into the main at this time. |
1 similar comment
Currently, only patch changes are allowed on main. Your PR labels (semver: minor) indicate that it cannot be merged into the main at this time. |
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 2h 30m 54s ⏱️ For more details on these failures, see this check. Results for commit e152ef5. ♻️ This comment has been updated with latest results. |
LocalStack Community integration with Pro 2 files ±0 2 suites ±0 1h 45m 40s ⏱️ + 1m 18s For more details on these failures, see this check. Results for commit e152ef5. ± Comparison against base commit 2d08a27. This pull request removes 1 and adds 4 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
general question: if we remove this, how does the devx look like for localstack developers? the stacktrace is added when DEBUG=1
is set so the stack traces appear in test failures directly, which has helped (at least me) in the past to find issues very quickly.
That's a good point: it returns the error directly in the client call, which allows the test annotation to show the error directly and not have to go through the logs of the running LocalStack instance. I think there's a fine line with the customer running with |
that's fair. so perhaps instead of removing the behavior (returning stack traces) all together, we could tie it to our tests being run. for example |
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 8m 32s ⏱️ Results for commit c28d16c. ♻️ This comment has been updated with latest results. |
f103562
to
5c4c022
Compare
5c4c022
to
0fde5fd
Compare
INCLUDE_STACK_TRACES_IN_HTTP_RESPONSE
is enabled
Motivation
As a part of the initiative for improving Localstack error messages, this PR aims to conditionally remove stack traces from HTTP responses. A new environment variable
INCLUDE_STACK_TRACES_IN_HTTP_RESPONSE
is introduced, which when enabled, allows stack traces to be included in the HTTP response.This is expected to be always enabled during test runs, where it improves LocalStack devX, unless its explicitly disabled. This flag is for internal use only. The stack traces wouldn't appear in the HTTP responses for users unlike before when
DEBUG
is enabled.Current Behaviour:
Expected Behaviour:
Changes
This PR excludes stack traces from HTTP responses when
DEBUG=1
mode is enabled (forDEBUG=0
we already do not log stack trace in the response) and rather allow stack traces whenINCLUDE_STACK_TRACES_IN_HTTP_RESPONSE
is enabled.Testing
The responses to:
INCLUDE_STACK_TRACES_IN_HTTP_RESPONSE
have been tested locally by deliberately introducing an error by assigninga = request["KeyId"][100]
indescribe_key
handler and runawslocal kms describe-key --key-id=411cff4c-e1d0-49cc-9ec7-73ac91049d86
command ensuring expected stack trace behaviour for both cases.TODO