Skip to content

[Bug]: skipmap: Store value silently lost under concurrent LoadAndDelete #36

@jmasters-git

Description

@jmasters-git

Operating System

MacOS 26.3.1

Go Version

1.26.1 darwin/arm64

Package Version

v1.10

Reproduction Steps

See bytedance/gopkg#264 for original bug report.

A porcupine linearizability test reliably reproduces this with 16 goroutines performing a uniform mix of Load, LoadOrStore, Store, and LoadAndDelete on 10 keys (200 ops per client). The failure is intermittent but typically triggers within a few runs.

Image


Observed timeline

LoadAndDelete(key_0) -> 700091   [deletes the old value]
Store(key_0, 200019)             [concurrent, should install new value]
LoadAndDelete(key_0) -> nil      [value from Store is gone]

There is no valid linearization of these operations: if Store(key_0, 200019) linearizes after the first LoadAndDelete, the key should hold 200019. The second LoadAndDelete returning nil means the Store's effect was lost without any corresponding delete.

Expected Behavior

The effect of Store(key, value) operations must cause the value to be visible to subsequent operations.

Actual Behavior

A Store completes successfully but its value is never observed. A subsequent LoadAndDelete returns nil, and no operation accounts for the removal of the stored value. (see reproduction)

Screenshots

No response

Additional Context

Originally reported in an bytedance/gopkg issue bytedance/gopkg#264, but the bug also applies to this version as well. The issue has been confirmed to be present in this implementation as well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions