Fix big object deletion #896
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#896
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:fix/test_big_object_delete_is_flaky"
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?
There was a bug: when GC deletes virtual (parent) object of complex object, it drops GC mark, but does nothing with parent object, so split info returns for Get/Exists requests.
Also changed test logger. Now test related logs grouped after test. There are two differences from the previous implementation:
logger.go 139:
prefix, it istesting
package behaviourBut the ability to see logs for a specific test is more important, in my opinion.
test -race
after logger change)Closes #895
e2debba928
to8ec5eb85f1
4521ed1090
toad47b177b5
d84d846af9
to9e78baa3da
@ -83,3 +83,1 @@
t.Cleanup(func() {
e.Close(context.Background())
})
defer func() {
https://github.com/golang/go/issues/40908
This is exactly why we got rid of
zaptest
and usedzap.L()
, these problems occured all over the tests (and writingt.Cleanup
in the constructor is much easier that to remember writing it everywhere else.#621
There was only one place in the entire project that needed to be fixed. But clear logs make sense for all of tests.
Debatable: we do not need logs at all and when debugging tests usually a single test can be run.
Actually, I see lots of
Cleanup
withClose
inside, they could trigger race detector later at some point.I don't like returning the behaviour which clearly has problems and which we have intentionally fixed at some point.
I disagree with the statement:
we do not need logs at all
. For several tasks already, I needed normal logs of falling tests.Ok, but reverting a fix to a real problem is not the right approach here.
Now there is no problem: race condition for
t.Cleanup
is actual only for engine afterInit()
.Looks like it was an inappropriate fix.
Also see this comment (testing.go: 1580):
As far as I understand
Cleanup
requires all test background goroutines must be stopped. So usingCleanup
forengine.Close
is invalid usage.I am not sure the problems is gone now. The problem is that
done
fieldcc85462b3d/src/testing/testing.go (L1017)
done
is written to intentionally without a mutex incc85462b3d/src/testing/testing.go (L1580)
If you do
rg 'Cleanup\(' -A4
over the codebase, there are multiple calls toreleaseShard
inCleanup
(and to writecache etc.), because we currently useCleanup()
in tests. Are you sure there are no goroutines inShard
which can log and run untilClose()
is called? In the writecache?Or here, is it different from the
list_test.go
situation:cbc78a8efb/pkg/local_object_storage/engine/shards_test.go (L16)
?I would rather see a discussion first.
9e78baa3da
tof658b085e7
WIP: Fix big object delete testto Fix big object deletion@ -330,0 +333,4 @@
garbageBKT := tx.Bucket(garbageBucketName)
key := make([]byte, addressKeySize)
addrKey := addressKey(object.AddressOf(obj), key)
if garbageBKT != nil {
Why not to check it earlier?
Fixed
f658b085e7
to1dc53e0120
1dc53e0120
tocbc78a8efb
LGTM
cbc78a8efb
to9494abdb69
@ -18,4 +17,0 @@
t.Cleanup(func() {
blz.Close()
os.RemoveAll(filename)
t.TempDir
will be removed by testing engine.@ -25,10 +25,6 @@ func (s storage) open(b *testing.B) common.Storage {
require.NoError(b, st.Open(false))
require.NoError(b, st.Init())
b.Cleanup(func() {
Close
call moved to caller.Tests with
-race
fail, disregard approval.9494abdb69
to284ef903ac
284ef903ac
to0cfe98b9be
0cfe98b9be
to50e648e3b1
Fixed