Skip to content

Make RocksDbManager database lifecycle cancellation-safe #5192

Description

@tillrohrmann

Problem

RocksDB storage-pool operations continue after the awaiting future is dropped. The runner executes the operation and ignores failure to deliver its result to the dropped oneshot receiver.

RocksDbManager::open_db only registers a database after RocksDb::open completes. Cancellation can therefore abandon an in-flight open before it is registered, allowing another open or shutdown to race it.

Issue #4790 works around this in the partition processor by making partition-store opening non-cancellable once submitted. Cancellation safety should instead be guaranteed by RocksDbManager.

Related: #4790 and #5113.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions