Assemble complex object headers if linking object is deleted on EC containers #1295
No reviewers
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
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#1295
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:fix/virtual_object_head"
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?
Scenario:
Head
without--raw
this objectAs is:
object not found
will be thrown, log will containcan't unmarshal child with parent: object ID is not set
errorTo be: object headers will be returned
Frostfs-testcases for Object API passed:
@ -126,17 +127,16 @@ func (e *StorageEngine) head(ctx context.Context, prm HeadPrm) (HeadRes, error)
return true
})
if head != nil {
Reason to change priority: if some shard returns split info error, but other shard has linking object, then return head result directly.
@ -730,7 +730,7 @@ func TestGetRemoteSmall(t *testing.T) {
t.Run("VIRTUAL", func(t *testing.T) {
testHeadVirtual := func(svc *Service, addr oid.Address, i *objectSDK.SplitInfo) {
headPrm := newHeadPrm(false, nil)
For
raw == false
cases it is expected to return object headers, but not split info error.@ -90,3 +90,2 @@
func (r *request) canAssemble() bool {
return !r.isRaw() && !r.headOnly()
func (r *request) canAssembleComplexObject() bool {
To make method name more clear.
b099058d46
to3cbea98e28
@ -65,15 +77,33 @@ func (a *assembler) Assemble(ctx context.Context, writer ObjectWriter) (*objectS
return a.parentObject, nil
}
func (a *assembler) getHead(ctx context.Context, sourceObjectID oid.ID, writer ObjectWriter) (*objectSDK.Object, error) {
It seems to be completely independent of other
assembler
methods, do we have a reason to provideheadOnly
as a parameter to theassembler
instead of writing a separate function?Good point. Now this method looks more related to assembling: it tries to find parent headers from linking and last part objects.
@ -75,2 +103,4 @@
a.log.Debug(logs.LastPartIDFound, zap.Stringer("last_part_object_id", sourceObjectID))
return sourceObjectID, true
}
a.log.Warn(logs.EmptySplitInfo)
We return
false
, then create an error and will log again. Why is thisWarn
?This
Warn
explains whyAssemble
returns error.I don't like the assembler being able to log anything, as it will be eventually moved to the SDK.
It only adds complexity (by producing side-effects), even though we can return everything in the result.
The result in turn is what we log and can use for troubleshooting.
I disagree, but fixed.
@ -731,3 +731,3 @@
t.Run("VIRTUAL", func(t *testing.T) {
testHeadVirtual := func(svc *Service, addr oid.Address, i *objectSDK.SplitInfo) {
headPrm := newHeadPrm(false, nil)
headPrm := newHeadPrm(true, nil)
I would expect the tests to stay the same, what is the reason?
For
raw == false
cases it is expected to return object headers, but not split info error, as test does. So this test looks loke something unrelated to real code and works just because of mocks.3cbea98e28
to82d8190691
@ -68,0 +112,4 @@
if parent == nil {
return nil, objectSDK.NewSplitInfoError(a.splitInfo)
}
if err := writer.WriteHeader(ctx, obj.Parent()); err != nil {
obj.Parent() -> parent
Fixed
82d8190691
tocac6d59bfa
cac6d59bfa
to8e51d7849a