Skip to content

A restore task that cannot lock its backend skips the restore and completes successfully #1025

Description

@maximthomas

What happens

RestoreTask.runTask() guards the restore with if (verifyOnly || lockBackend(backend)) and has no else branch (

). When lockBackend() returns false — the backend lock file is held by another process or cannot be created — the whole restore block is skipped, errorsEncountered stays false, the finally re-enables the backend and notifies the restore task listeners with successful == true, and the task returns getFinalTaskState(), i.e. COMPLETED_SUCCESSFULLY.

The only trace is the ERR_RESTOREDB_CANNOT_LOCK_BACKEND line lockBackend() logs. The task entry, manage-tasks, the restore CLI exit code and every RestoreTaskListener all see a successful restore that never touched the backend.

Expected

The task should end in STOPPED_BY_ERROR (or at least COMPLETED_WITH_ERRORS) and the listeners should be told successful == false, as they are when restoreBackup() itself fails.

Fix

An else { errorsEncountered = true; } on that if, or a plain early return mirroring ImportTask's lock-failure path (ImportTask.java:658-662), which returns STOPPED_BY_ERROR.

Pre-existing, unchanged by #969; found while reviewing it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugdata-lossData integrity / loss of entriestasksServer administrative tasks: import, export, backup, restore

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions