Extract the barman-restorer error -> gRPC code switch from
restoreFromBarmanObjectStore into a pure helper,
classifyWALRestoreError, so it can be exercised in isolation
without the surrounding k8s client / configuration scaffolding.
Add ginkgo specs that check:
- each barman sentinel maps to the expected gRPC status code
(ErrConnectivity and ErrGeneric both -> Unavailable, since
barman uses exit 4 for some retryable conditions too),
- an unclassified error falls through to codes.Internal,
- classification still works through multiple fmt.Errorf wraps,
- the switch matches by errors.Is identity rather than message
substring (so a NotFound whose message happens to mention
"connectivity" still maps to NotFound).
internal/cnpgi/common had no tests before; this introduces the
suite scaffolding alongside the new specs.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
The per-case and helper comments asserted what the operator will do
with each gRPC code ("the operator stops retrying", "the operator
will retry the request", etc.). On the current cloudnative-pg main,
the operator only differentiates ErrWALNotFound; the precise-code
distinctions become meaningful only after the operator-side retry
work lands.
Rewrite the comments to describe what the code emits and why (per
gRPC convention), so they stay accurate regardless of the operator
version on the other end. Also note that barman returns ErrGeneric
(exit 4) for some retryable conditions too — not only ErrConnectivity
(exit 2) — which justifies why both map to codes.Unavailable.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Map each restorer sentinel to the gRPC status that best reflects whether
the operator should retry:
- ErrWALNotFound -> NotFound (terminal)
- ErrInvalidWalName -> InvalidArgument (terminal)
- ErrConnectivity -> Unavailable (retry)
- ErrGeneric -> Unavailable (retry)
- anything else -> Internal (terminal)
Previously every non-NotFound failure was returned verbatim, leaving the
operator unable to tell transient blips apart from terminal conditions
like a malformed WAL name.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
The plugin now returns a 404 status code when a requested WAL file does
not exist in the object store.
This prevents misleading log entries such as "Error while handling gRPC
request" for expected missing-file scenarios.
The `ErrEndOfWALStreamReached` now returns `OutOfRange` error.
The `ErrMissingPermissions` now returns `FailedPrecondition` error.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
