Introduce ChainRouterError
error type and wrap only these errors with ObjectAccessDenied
status #1563
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1563
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "aarifullin/frostfs-node:fix/ape_logicalerr"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
ChainRouterError
incommon/ape
packagetree
service. Maketree
service wrap withObjectAccessDenied
onlyChainRouterError
object
service. Makeobject
service wrap withObjectAccessDenied
onlyChainRouterError
Since errors can be differentiated logical check errors and server internal errors.
4ead7084a9
tocb63ea028c
@ -0,0 +14,4 @@
}
func (e *ChainRouterError) Error() string {
return fmt.Sprintf("access to operation %s is denied by access policy engine: %s", e.Operation(), e.Status().String())
.String()
can be omitted for%s
.Fixed
@ -0,0 +25,4 @@
return e.status
}
func NewChainRouterError(operation string, status apechain.Status) *ChainRouterError {
Do we need to export this?
Fixed
@ -8,0 +10,4 @@
func processAPECheckErr(err error) error {
var chRouterErr *checkercore.ChainRouterError
if !errors.As(err, &chRouterErr) {
return err
Where do we do wrapping to internal status (if we have any)?
I am wondering whether these changes may break client code (see
PrmInit.ResolveFrostFSFailures()
in SDK), because we will get an error instead of status.We don't do that for all errors, but they are implicitly (from the point of this middleware) wrapped to
internalServerError
anyway. Aren't they?Although that's not true for
tree
serviceFor now non-
chainRouterError
errors are explicitly wrapped with ServerInternal status for the all goodness sake@ -92,3 +92,3 @@
cnrID, objID, err := getAddressParamsSDK(partInit.GetHeader().GetContainerID(), partInit.GetObjectID())
if err != nil {
return toStatusErr(err)
return processAPECheckErr(err)
Why all the renaming?
I implied as we don't wrap all errors to status but this can be made after some processing. For now I think we need to wrap errors explicitly and the name is going to be returned
Naming have been returned back
cb63ea028c
to6e82661c35
New commits pushed, approval review dismissed automatically according to repository settings
Please, create the same PR in the
support/v0.44
branch.