Evgenii Stratonikov
b42bcdc6fa
All checks were successful
DCO action / DCO (pull_request) Successful in 1m24s
Tests and linters / Run gofumpt (pull_request) Successful in 1m18s
Vulncheck / Vulncheck (pull_request) Successful in 1m30s
Pre-commit hooks / Pre-commit (pull_request) Successful in 2m20s
Build / Build Components (pull_request) Successful in 2m30s
Tests and linters / gopls check (pull_request) Successful in 2m50s
Tests and linters / Staticcheck (pull_request) Successful in 3m22s
Tests and linters / Lint (pull_request) Successful in 3m55s
Tests and linters / Tests (pull_request) Successful in 6m3s
Tests and linters / Tests with -race (pull_request) Successful in 6m2s
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> |
||
|---|---|---|
| .. | ||
| acl | ||
| ape | ||
| common | ||
| delete | ||
| get | ||
| internal | ||
| patch | ||
| put | ||
| search | ||
| util | ||
| audit.go | ||
| common.go | ||
| metrics.go | ||
| remote_reader.go | ||
| request_context.go | ||
| response.go | ||
| server.go | ||
| sign.go | ||
| transport_splitter.go | ||