Review errors returned by the gitaly services
We have lot of services gitaly exposes as RPC endpoints. We heavily rely on gRPC technology and use status
package for the errors we return. We use them to provide the caller with the completion code for the operation. In most cases we rely on the helper
package that constructs status object for us, but there are some improvements we can do to it:
- the status code we return should represent the initial error code, but due to error wrapping in lot of cases it is lost
- we shouldn't do double wrapping of status. Otherwise, it may create an impression of calling another RPC which is not a case
- The direct usage of the
status
package should be replaced withhelper
package usage. It hides internal details about gRPC and gives us more flexibility - we don't have much context in some cases and it may be hard to do an investigation of failures
For the past week there are next results of the RPC executions that ended up with codes.Unknown
"json.grpc.method","Count of records"
FetchRemote,"3,644"
FindCommit,"3,313"
FindBranch,"2,407"
RawPatch,"2,113"
ListCommitsByOid,"1,819"
TreeEntry,"1,095"
GetArchive,580
GetTreeEntries,494
ResolveConflicts,347
PackObjectsHookWithSidechannel,200
UserCommitFiles,85
UserMergeBranch,43
RawDiff,7
FetchSourceBranch,5
FindLicense,5
WikiFindPage,4
ApplyGitattributes,1
UserRebaseConfirmable,1
/cc @andrashorvath
Edited by Pavlo Strokov