Hello, The cause is similar but SOLR-17200 being fixed does not mean that SOLR-17049 is. The latter might be a bit trickier to fix.
Vincent On Mon, Apr 29, 2024 at 3:41 PM Rajani M <rajinima...@gmail.com> wrote: > Hi All, > Saw this SOLR-17200 <https://issues.apache.org/jira/browse/SOLR-17200> > fixed > in 9.6. which seems to be similar to SOLR-17049 > <https://issues.apache.org/jira/browse/SOLR-17049>. Could you please take > a > look and let me know your thoughts? > > Thank you, > Rajani > > On Thu, Oct 26, 2023 at 9:43 AM Vincent Primault > <vprima...@salesforce.com.invalid> wrote: > > > Hello, I created a JIRA to track this: > > https://issues.apache.org/jira/browse/SOLR-17049 > > > > On Thu, Oct 26, 2023 at 3:30 PM rajani m <rajinima...@gmail.com> wrote: > > > > > Is this an issue in that case? If so, should we create a jira to > address > > > it? > > > > > > On Sat, Oct 7, 2023 at 8:32 PM Mark Miller <markrmil...@gmail.com> > > wrote: > > > > > > > Yeah, it’s not going to fix that updates can come in too early if you > > > just > > > > delay when the replica publishes active. It’s still going to show up > > > active > > > > when it’s not. That gets rectified if you end up replicating the > index, > > > > it’s when you peer sync that it can be a persistent problem. And in > > both > > > > cases, you can end up with a window of incorrect queries. > > > > > > > > The most straightforward way to handle it is to use the cluster state > > > > rather than the cores from the core container when publishing down > > (where > > > > it doesn’t currently use the downnode command) and when waiting to > see > > > the > > > > state. > > > > > > > > > >
