services/horizon: Purging log.Fatal, to make horizon CLI easier to test. #3766
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
Shaptic
reviewed
Jul 13, 2021
There was a problem hiding this comment.
Bit of a Catch-22 here: can't write CLI tests without this refactor, can't test this refactor without CLI tests! Everything seems pretty straightforward aside from the WaitGroup changes, though. My vote is to get this in really early into a sprint so that we can all interact with it a bunch throughout.
2opremio
reviewed
Jul 14, 2021
|
I am in favor of this. My only concern: could this have any negative operational implications? (e.g. the monitoring system not catching bad restarts anymore because the failure wasn't logged as expected) |
|
Yeah, we'll need to be super careful not to change error output messages too much with this. Good call. |
paulbellamy
force-pushed
the
paulb/cmd_integration_testing
branch
4 times, most recently
from
81ce7e7 to
e9ecc08
Compare
- Purging fatals from flags
paulbellamy
force-pushed
the
paulb/cmd_integration_testing
branch
2 times, most recently
from
fc5f184 to
6ec2579
Compare
paulbellamy
force-pushed
the
paulb/cmd_integration_testing
branch
from
6ec2579 to
d297418
Compare
paulbellamy
changed the title
tamirms
reviewed
Aug 3, 2021
Shaptic
approved these changes
Aug 3, 2021
tamirms
reviewed
Aug 4, 2021
tamirms
approved these changes
Aug 4, 2021
tamirms
pushed a commit
that referenced
this pull request
Aug 20, 2021
…st. (#3766) * Purging os.Exit and log.Fatal from horizon/cmd - Purging fatals from flags * Passing back flag fail errors to see if that impacts integration tests * Return the right error from tick setup * wip -- integration tests * Fix introduced whitespace in error messages * Better usage error handling * Add comment warning about error behaviour of UpdateStellarCoreInfo
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.
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Remove
log.Fatalandos.Exitcalls from Horizon.log.Fatalandos.Exitshould only be called infunc main(), andfunc init().error, which propagates up tofunc main()Why
As discussed in #3741 (comment), using
log.Fatalandos.Exitmake integration testing Horizon harder. They force you to launch it as a subprocess and faff around with managing that. Removing these should make it simpler.Reducing friction for CLI-type tests would have helped catch #3762 type bugs sooner/easier.
Known limitations
[WIP]at this point, as I want to get people's opinions, and if there are any gotchas to watch out for here before spending more time on this. If we're happy with the approach we should merge #3741 as-is, then use this to simplify it, and add a few more cli tests.The one big outstanding thing here re: testing are the places we use
os.Getenv. But.. One thing at a time.