Skip to content

Remove error return value from ExecuteCmd#1400

Closed
tamird wants to merge 3 commits intocockroachdb:masterfrom
tamird:executecmd-error
Closed

Remove error return value from ExecuteCmd#1400
tamird wants to merge 3 commits intocockroachdb:masterfrom
tamird:executecmd-error

Conversation

@tamird
Copy link
Copy Markdown
Contributor

@tamird tamird commented Jun 17, 2015

This is already returned on the Call's reply header.

This refactor introduced a test failure (see the first commit which fixes the error message for that test), but I'm not sure why.

@tbg tbg added the PTAL label Jun 17, 2015
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 pattern seems fragile: if err is ever shadowed then the error wouldn't be returned correctly. I'd rather call SetGoError each time we have if err != nil { return } instead of calling it in a defer.

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.

done

This is already returned on the Call's reply header.
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.

rng.AddCmd() has the same issue as this method. Does rng.AddCmd() ever return an error that is different from reply.GoError? If so, we used to leave the reply.GoError alone but this change will overwrite it with the returned error. I'm not sure if that has anything to do with the test failure but I'm having a hard time spotting other behavioral changes.

@tbg
Copy link
Copy Markdown
Member

tbg commented Jun 17, 2015

I haven't looked at the details so it may not be relevant here, but something that I tripped over in the past is that header.SetGoError(err) equals a subsequent header.GoError() only if err is one of the proto error types that SetGoError knows about. That means returning non-proto errors via headers will mush them into a generic error which bypasses all upstream type assertions.

Btw, CircleCI has a bunch of test failures - which one should I be looking at?

@tamird
Copy link
Copy Markdown
Contributor Author

tamird commented Jun 17, 2015

Closing this in favour of the approach discussed in #1403

@tamird tamird closed this Jun 17, 2015
@tbg tbg removed the PTAL label Jun 17, 2015
@tamird tamird deleted the executecmd-error branch June 17, 2015 22:29
tbg added a commit to tbg/cockroach that referenced this pull request Jun 19, 2015
- always update response cache in applyRaftCommand, allowing early returns
- add replicaCorruptionError, bogus handling and test
- anticipate cockroachdb#1400 by not using reply.Header().GoError() as authoritative
  error source and by setting it only in r.processRaftCommand (though
  it is still set in r.executeCmd and below) for now
- deduplicate some logic around the verification of leader leases
- move leadership check from applyRaftCommand to processRaftCommand and add
  a comment
tbg added a commit to tbg/cockroach that referenced this pull request Jun 19, 2015
- always update response cache in applyRaftCommand, allowing early returns
- add replicaCorruptionError, bogus handling and test
- anticipate cockroachdb#1400 by not using reply.Header().GoError() as authoritative
  error source and by setting it only in r.processRaftCommand (though
  it is still set in r.executeCmd and below) for now
- deduplicate some logic around the verification of leader leases
- move leadership check from applyRaftCommand to processRaftCommand and add
  a comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants