systemtest: migrate one sourcemap test to Go #4488
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Just migrating one for now, to simplify the R&D into moving source mapping to ingest node.
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Steps errors
Expand to view the steps failures
|
jalvz
approved these changes
Dec 3, 2020
simitt
pushed a commit
to simitt/apm-server
that referenced
this pull request
Dec 15, 2020
Just migrating one for now, to simplify the R&D into moving source mapping to ingest node.
simitt
added a commit
that referenced
this pull request
Dec 15, 2020
Just migrating one for now, to simplify the R&D into moving source mapping to ingest node. Co-authored-by: Andrew Wilkins <[email protected]>
stuartnelson3
added a commit
to stuartnelson3/apm-server
that referenced
this pull request
Mar 4, 2021
timeouts configured at the server level result in the request context being canceled; translate this to a "server timeout" message before logging/sending to the client. the actual message being sent and status code could also be changed, if there's a better way to communicate what's happening, or a more appropriate status code, we can change it. i'm not sure at which point in the request/response lifecycle it's failing, so it could be a 408 or 503. note: this feels like a very broad approach. reading around online did not provide a concrete way to check that the request had timed out. an alternative method, such as setting a context.WithTimeout on the request for instead of the server's ReadTimeout might give us more visibility into the cause. my concern is that some un-related error might cause the request (and context) to be canceled, and then we report this as a timeout. fixes elastic#4488
stuartnelson3
added a commit
to stuartnelson3/apm-server
that referenced
this pull request
Mar 4, 2021
timeouts configured at the server level result in the request context being canceled; translate this to a "server timeout" message before logging/sending to the client. the actual message being sent and status code could also be changed, if there's a better way to communicate what's happening, or a more appropriate status code, we can change it. i'm not sure at which point in the request/response lifecycle it's failing, so it could be a 408 or 503. note: this feels like a very broad approach. reading around online did not provide a concrete way to check that the request had timed out. an alternative method, such as setting a context.WithTimeout on the request instead of the server's ReadTimeout might give us more visibility into the cause. my concern with the approach in this PR is that some un-related error might cause the request (and context) to be canceled, and then we report this as a timeout. fixes elastic#4488
1 task
axw
pushed a commit
to axw/apm-server
that referenced
this pull request
Mar 25, 2021
timeouts configured at the server level result in the request context being canceled; translate this to a "server timeout" message before logging/sending to the client. the actual message being sent and status code could also be changed, if there's a better way to communicate what's happening, or a more appropriate status code, we can change it. i'm not sure at which point in the request/response lifecycle it's failing, so it could be a 408 or 503. note: this feels like a very broad approach. reading around online did not provide a concrete way to check that the request had timed out. an alternative method, such as setting a context.WithTimeout on the request instead of the server's ReadTimeout might give us more visibility into the cause. my concern with the approach in this PR is that some un-related error might cause the request (and context) to be canceled, and then we report this as a timeout. fixes elastic#4488
mergify bot
pushed a commit
that referenced
this pull request
Apr 27, 2021
timeouts configured at the server level result in the request context being canceled; translate this to a "server timeout" message before logging/sending to the client. the actual message being sent and status code could also be changed, if there's a better way to communicate what's happening, or a more appropriate status code, we can change it. i'm not sure at which point in the request/response lifecycle it's failing, so it could be a 408 or 503. note: this feels like a very broad approach. reading around online did not provide a concrete way to check that the request had timed out. an alternative method, such as setting a context.WithTimeout on the request instead of the server's ReadTimeout might give us more visibility into the cause. my concern with the approach in this PR is that some un-related error might cause the request (and context) to be canceled, and then we report this as a timeout. fixes #4488 (cherry picked from commit 506311f)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation/summary
Just migrating one for now, to simplify the R&D into moving source mapping to ingest node.
There were two identical (except for the names) Python system tests; I removed both. I suppose the "changed_index" test was meant to do something different, but right now it's just dead weight.
Checklist
- [ ] I have updated CHANGELOG.asciidocI have considered changes for:
- [ ] documentation- [ ] logging (add log lines, choose appropriate log selector, etc.)- [ ] metrics and monitoring (create issue for Kibana team to add metrics to visualizations, e.g. Kibana#44001)- [ ] telemetry- [ ] Elasticsearch Service (https://cloud.elastic.co)- [ ] Elastic Cloud Enterprise (https://www.elastic.co/products/ece)- [ ] Elastic Cloud on Kubernetes (https://www.elastic.co/elastic-cloud-kubernetes)How to test these changes
cd systemtest && go test -vRelated issues
#3606