Improve Archiver error reporting#482
Conversation
Instead of crashing `startWARCWriter` via `os.Exit(1)`, we return the error which is passed via `archiver.Start` in the pipeline. There, the program is terminated via `panic` as it happens with all component errors.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #482 +/- ##
==========================================
- Coverage 56.42% 56.41% -0.01%
==========================================
Files 130 130
Lines 8091 8099 +8
==========================================
+ Hits 4565 4569 +4
- Misses 3161 3162 +1
- Partials 365 368 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
NGTmeaty
left a comment
NGTmeaty
left a comment
There was a problem hiding this comment.
Looks good besides one minor comment!
|
|
||
| // Setup WARC writing HTTP clients | ||
| startWARCWriter() | ||
| if err := startWARCWriter(); err != nil { |
There was a problem hiding this comment.
Would it make more sense to define this as WARCWriterErr or something similar?
There was a problem hiding this comment.
Now, we return the err returned by warc.NewWARCWritingHTTPClient.
How can we change the type of that to WARCWriterErr ?
There was a problem hiding this comment.
I was just talking about the variable name itself not the type, but on second glance I think it's fine as is.
3 participants
Instead of crashing
startWARCWriterviaos.Exit(1), we return the error which is passed viaarchiver.Startin the pipeline. There, the program is terminated viapanicas it happens with all component errors.Relevant to: #473