Skip to content

Fix silent data loss in DMap.Delete with multi-key/multi-owner deletes - #287

Open
fcraviolatti wants to merge 1 commit into
olric-data:masterfrom
fcraviolatti:fix/deletekeys-multi-owner-dataloss
Open

Fix silent data loss in DMap.Delete with multi-key/multi-owner deletes#287
fcraviolatti wants to merge 1 commit into
olric-data:masterfrom
fcraviolatti:fix/deletekeys-multi-owner-dataloss

Conversation

@fcraviolatti

Copy link
Copy Markdown

Fixes #286

Summary

  • deleteKeys returned unconditionally after the first remote owner
    (success or error), skipping remaining remote owners in multi-key
    deletes and silently leaving their keys undeleted.
  • Fan-out now uses errgroup.Group, matching the pattern already used
    by deleteBackupOnCluster/destroyOnCluster in the same file: every
    owner is attempted, first error is returned only after all owners
    have completed. Returned count reflects keys actually processed.

Test plan

  • Added TestDMap_Delete_MultiKeyDifferentRemoteOwners, confirmed
    it fails on master and passes with this fix
  • go test ./internal/dmap/... -run TestDMap_Delete (8/8 pass)
  • go test ./... (539/539 pass, 35 packages)
  • go test ./internal/dmap/... -race (97/97 pass, no races)

deleteKeys groups the requested keys by partition owner, then loops
over that map to delete each group. The remote-owner branch of the
loop returned unconditionally after handling the first remote owner
(both on success and on error), so any additional remote owners in
the map were never processed. With a multi-node cluster and enough
keys to span more than one remote owner, Delete(ctx, keys...) silently
skipped deleting the keys owned by every remote owner after the first,
returning no error.

Fix the fan-out to use errgroup, matching the pattern already used by
deleteBackupOnCluster and destroyOnCluster: every owner (local and
remote) is processed, and the first error (if any) is returned only
after all owners have been attempted. The returned count now reflects
the keys actually processed across all owners.

Added TestDMap_Delete_MultiKeyDifferentRemoteOwners, which reproduces
the bug deterministically on a 3-node cluster by asserting the test's
own key set hashes to at least two different remote owners before
calling Delete.
Copilot AI review requested due to automatic review settings July 24, 2026 10:17

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a silent data loss bug in DMap.Delete where multi-key deletes spanning multiple remote partition owners would stop after the first remote owner, leaving remaining keys undeleted without returning an error.

Changes:

  • Refactors deleteKeys to fan out deletes to all owners using errgroup.Group and aggregate the processed-key count.
  • Adds a regression test ensuring multi-key deletes across multiple remote owners actually delete all keys.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
internal/dmap/delete.go Fans out delete requests to all owners concurrently and waits for completion instead of returning after the first remote owner.
internal/dmap/delete_test.go Adds a regression test covering multi-key deletes across multiple remote owners.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread internal/dmap/delete.go
Comment on lines +151 to +153
// Fan out to every owner instead of stopping at the first remote one -
// see the errgroup pattern used by deleteBackupOnCluster/destroyOnCluster.
var count int64
require.NoError(t, err)

ctx := context.Background()
const keyCount = 30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DMap.Delete silently drops keys owned by remote nodes after the first, when deleting multiple keys across multiple owners

2 participants