Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Catch previously undetected errors from git exit codes in async scans#1118

Merged
sinbad merged 10 commits into
masterfrom
scanner-async-errors
Apr 5, 2016
Merged

Catch previously undetected errors from git exit codes in async scans#1118
sinbad merged 10 commits into
masterfrom
scanner-async-errors

Conversation

@sinbad

@sinbad sinbad commented Mar 31, 2016

Copy link
Copy Markdown
Contributor

Fixes #1100 as well as surfacing a number of other fail states previously missed.

Wraps all scanner channels so that consumer only has to worry about primary results as channels, then check error result from wrapper.Wait() at the end to pick up any bad exit conditions (rather than having to handle 2 channels themselves).

Fixed a bunch of other issues while I was at it.

sinbad added 7 commits March 31, 2016 12:00
Problem is that the clean filter will fail earlier because of corruption
and this in turn fails the diff-index, which we now pick up. But this
then fails ScanIndex which fsck treats as fatal instead of realising it's
a symptom of something it can fix. Not sure how to handle this better yet
Reason is that although the first entry in the line is "(delete)", the
check occurs on the result which only includes the SHAs; this is actually
all zeroes in the delete case. This was silently failing before we
error checked more rigorously.
Comment thread lfs/scanner.go
// stderr, _ := ioutil.ReadAll(cmd.Stderr)
// err := cmd.Wait()
// if err != nil {
// errchan <- fmt.Errorf("Error in git diff-index: %v %v", err, string(stderr))

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not totally sure what to do about this yet, any ideas?

Comment thread lfs/scanner.go
for e := range w.errorChan {
if err != nil {
// Combine in case multiple errors
err = fmt.Errorf("%v\n%v", err, e)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will lose the backtrace from any scans that return multiple errors. Any panics will show this as the culprit of the bug, and not a scanner that returns a channel wrapper. If it becomes a problem, I could see us using some MultiError type that preserves them, and teaching commands.Panic() how to handle it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, I did consider pulling in https://github.com/hashicorp/go-multierror but thought it was overkill, and concentrated on making the error text itself return more useful info instead.

@technoweenie

Copy link
Copy Markdown
Contributor

This looks good to me. 👍

Fixed a bunch of other issues while I was at it.

What issues? Anything worth adding a test for?

@technoweenie technoweenie mentioned this pull request Apr 4, 2016
17 tasks
@sinbad

sinbad commented Apr 5, 2016

Copy link
Copy Markdown
Contributor Author

What issues? Anything worth adding a test for?

The main specific one was in pre-push and push where it would not correctly detect delete branch push modes. You're right that should have tests on it, I'll add a couple.

Other issues were just clarifications really, most of all the prevalence of exit code 128 errors (now includes stderr so you know what the problem was) and just generally the failure to detect git errors in all of these methods, some of which are used outside of the scan context.

@sinbad sinbad merged commit 825cf2e into master Apr 5, 2016
@sinbad sinbad deleted the scanner-async-errors branch April 5, 2016 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants