[jira] [Resolved] (SOLR-18344) Backup status is not reported on /replication?command=details until the backup completes

["Eric Pugh (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Pugh resolved SOLR-18344.
------------------------------
    Fix Version/s: 10.1
         Assignee: Eric Pugh
       Resolution: Fixed

> Backup status is not reported on /replication?command=details until the backup completes
> ----------------------------------------------------------------------------------------
>
>                 Key: SOLR-18344
>                 URL: https://issues.apache.org/jira/browse/SOLR-18344
>             Project: Solr
>          Issue Type: Bug
>          Components: Backup/Restore
>    Affects Versions: 10.0, main(11.0), 9.10.1
>            Reporter: Idan Tepper
>            Assignee: Eric Pugh
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 10.1
>
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The "backup" key in the /replication?command=details response is only populated once a backup has finished. While one is running there is no indication that it is running, and the key still holds the *previous* backup's payload -- including "status": "success".
> Anything that issues /replication?command=backup and then polls command=details therefore reads the stale "success" of an earlier backup as the result of the one it just started, and concludes the new backup is already done. With no prior backup the key is simply absent, so a poller cannot distinguish "running" from "never started".
> SnapShooter.createSnapAsync already accepts a Consumer<NamedList<?>> that ReplicationHandler wires to its volatile snapShootDetails field, which getReplicationDetails publishes under the "backup" key. That consumer is only invoked once, at the very end of the snapshot.
> Proposal: keep the consumer and emit through it while the snapshot progresses, adding two in-progress statuses ahead of the existing terminal ones:
>  * "waiting for commit" -- published synchronously, before the worker thread starts, so a stale "success" can no longer be mistaken for the new backup's result. Carries no file counts, as the index commit (and with it the file list) is not resolved yet.
>  * "running" -- published after each file is copied, with "fileCount" and "finishedFileCount" so callers can show progress.
> The existing "success" and exception payloads are unchanged. The change is additive to the
> response and needs no change to ReplicationHandler.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org