Skip to content
Snippets Groups Projects
Commit 215369c1 authored by Georges Racinet's avatar Georges Racinet
Browse files

servicer.load_repo: completed error treatment.

Up to know, we were thinking that raising `KeyError` and setting
code and details on the context was enough, but apparently, it
is at least problematic with streaming gRPC methods.

We're instead using the two-layer organisation that was suggested
as comment in `service.repository`. As it turns out, the error
code to set in case of unknown storage depends at least on the
service. This was already visible in the error treatment of the
full path methods of `RepositoryService`, which does not need
to be specific any more.

The new `STATUS_CODE_*`class attributes make it easy to tweak the
error code in service implementations. Specific methods could override
them with instance attributes if needed.

In the process, we're basically giving up on providing the same
`details` as Gitaly: these are highly dependent on implementation
(it's just stderr if the implementation relies on a
`git` subprocess) and chances that it may matter are low, given
that GitLab these days pushes towards "structured errors", i.e. with
programmatically usable details provided in metadata.
As a result, the normalization of error details in `assert_compare_errors`
is not used any more. We're keeping it in the code base, as it may
turn useful for forthcoming tests were the details would not be a
simple stderr echo.
parent 008b961e
No related branches found
No related tags found
1 merge request!141Better error compliance and comparison tests refactor
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment