audit: Fix duplicated request logs #1659
1 changed files with 1 additions and 1 deletions
|
@ -163,7 +163,7 @@ func (a *auditPutStream) Send(ctx context.Context, req *object.PutRequest) error
|
||||||
if err != nil {
|
if err != nil {
|
||||||
a.failed = true
|
a.failed = true
|
||||||
}
|
}
|
||||||
if !errors.Is(err, util.ErrAbortStream) { // CloseAndRecv will not be called, so log here
|
if err != nil && !errors.Is(err, util.ErrAbortStream) { // CloseAndRecv will not be called, so log here
|
||||||
|
|||||||
audit.LogRequestWithKey(ctx, a.log, objectGRPC.ObjectService_Put_FullMethodName, a.key,
|
audit.LogRequestWithKey(ctx, a.log, objectGRPC.ObjectService_Put_FullMethodName, a.key,
|
||||||
audit.TargetFromContainerIDObjectID(a.containerID, a.objectID),
|
audit.TargetFromContainerIDObjectID(a.containerID, a.objectID),
|
||||||
!a.failed)
|
!a.failed)
|
||||||
|
|
Loading…
Add table
Reference in a new issue
Could you explain, why this was called multiple times?
I would expect that if there is an error, that is it, finish.
The explanation should be a part of the commit message.
Updated commit message.
When we do
object put
with audit enabled we get several entries in logs: with and without object id.object put
request is logged in 2 places:(*auditPutStream) CloseAndRecv()
- when the client closes the request stream or when stream gets aborted.(*auditPutStream) Send()
- when stream was NOT aborted.Send()
does error check forErrAbortStream
because if there is any other error - CloseAndRecv will not be called and there won't be any audit log about failed request.It led to logging on every object chunck put, even if
err == nil
.Ok, this PR is approved by me.
But why do we call
CloseAndRecv()
only for this specific error and not for others? It seems there could be multiple logic errors, and ifCloseAndRecv()
does some kind of a graceful shutdown, we should always do it.See
if err := stream.Send(gStream.Context(), patchReq); err != nil {
I don't know why this was done this way.
Did some digging
It was introduced in
7f5fb130c0 (diff-f9fb9a9419164dc9a10f6de9003e9b0d771cfa48)
And it seems we use it to treat signature error as a status error.