[
https://issues.apache.org/jira/browse/SOLR-16302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603946#comment-17603946
]
Albert Moser commented on SOLR-16302:
-------------------------------------
[~gerlowskija] I created a PR with the change
[https://github.com/apache/solr/pull/1009]
> Backup restore silently skips config restore if config with same name already
> exists (in cloud mode)
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-16302
> URL: https://issues.apache.org/jira/browse/SOLR-16302
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
> Affects Versions: 9.0
> Reporter: Albert Moser
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have tested this only in cloud mode.
>
> We have noticed when a backup is restored that contains a config with the
> same name as one that already exists in solr, the config restore is silently
> skipped (also when the configs are different but share the same name). I
> would expect that at least a warning appears in the logs when this happens.
> We saw that this happens with backups from local repositories as well as gcs
> repository (possibly others too).
> Steps to reproduce the issue:
> # Start solr in cloud mode
> # Upload a config (any config, we tried with the default one)
> # Create a collection with the config
> # Create a backup
> # Delete collection in UI
> # Change the config either in backup or in solr (we added an additional
> comment)
> # Restore collection
> # Have a look that after restore the old solr config has remained and the
> restored collection is using it. At the same time, the config from the backup
> has been ignored and no warning was produced whatsoever.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
