Handle nasty race condition when putting tombstone #1435

Merged

dstepanov-yadro merged 1 commit from fyrchik/frostfs-node:fix-gc into master

2024-10-26 11:30:27 +00:00

fyrchik commented

2024-10-17 11:56:09 +00:00

Owner

Close #1433

fyrchik added 2 commits 2024-10-17 11:56:10 +00:00

[#1433 ] shard/test: Use WithDisabledGC() option where possible b0c5def2d9

Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>

[#1433 ] services/object: Put object before auxiliary info

DCO action / DCO (pull_request) Successful in 1m24s

Details

Tests and linters / Run gofumpt (pull_request) Successful in 1m18s

Details

Vulncheck / Vulncheck (pull_request) Successful in 1m30s

Details

Pre-commit hooks / Pre-commit (pull_request) Successful in 2m20s

Details

Build / Build Components (pull_request) Successful in 2m30s

Details

Tests and linters / gopls check (pull_request) Successful in 2m50s

Details

Tests and linters / Staticcheck (pull_request) Successful in 3m22s

Details

Tests and linters / Lint (pull_request) Successful in 3m55s

Details

Tests and linters / Tests (pull_request) Successful in 6m3s

Details

Tests and linters / Tests with -race (pull_request) Successful in 6m2s

Details

b42bcdc6fa

Consider the following operations ordering:
1. Inhume(with tombstone A) --> add tombstone mark for an object
2. --> new epoch arives
3. --> GCMark is added for a tombstone A, because it is unavailable
4. Put(A) --> return error, because the object already has a GCMark

It is possible, and I have successfully reproduced it with a test on the
shard level. However, the error is related to the specific
_ordering_ of operations with engine. And triggering race-conditions like
this is only possible on a shard level currently, so no tests are
written.

Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>

fyrchik requested review from storage-core-committers 2024-10-17 11:56:22 +00:00

fyrchik requested review from storage-core-developers 2024-10-17 11:56:25 +00:00