Thanks David ... I've raised this JIRA: https://issues.apache.org/jira/browse/SOLR-18615
There are some fix proposals in there. Let me know what you think. From: [email protected] At: 11/02/26 10:29:52 UTC-5:00To: [email protected] Cc: Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A ) Subject: Re: [VOTE] Release Solr 10.1.0 RC3 Thanks for the analysis Luke. Yeah, I thought we had a cache-buster (I was involved with that long ago maybe) but we can't prevent/mandate a contributor adding/modifying URLs remembers to use it. A person (not bot/test) only identifies the mistake later, and its detection depends on their browser's cache. On Mon, Nov 2, 2026 at 9:51 AM Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A) via dev <[email protected]> wrote: I just ran into this on one of the nodes. A hard browser reload clears it. It can occur if you've opened the admin page from the previous version which causes a bad cached value from overlaying conflicting banners. I may raise a JIRA for this unless someone beats me to it. From Claude: - solr/webapp/web/index.html:71 loads libs/solr/index.js, the generated v2 API client, without the ?_=${version} cache-buster. Every other script and stylesheet on that page has it. - That tag came in with SOLR-17062 in 2023, after SOLR-15621 had added cache-busters to everything else. It was harmless until now because the old UI barely used the client. - In 10.1, SOLR-15752 moved the UI's startup calls onto that client: SystemV2.getNodeSystemInfo, CoresV2.getAllCoreStatus, and CollectionsV2/AliasesV2. The System API (/api/node/system, SOLR-16458) isn't in 10.0 at all. - Static files are served with etags=false and no Cache-Control (solr/server/etc/webdefault.xml), so browsers can reuse a cached copy without checking the server. - So a browser that last loaded the UI from an older Solr at the same host and port gets the new 10.1 app.js with the old cached client. new solrApi.SystemApi() then throws, MainController fails, and Angular never evaluates its ng-show flags. Every hidden banner then shows its raw text. From: [email protected] At: 10/26/26 12:09:37 UTC-4:00To: [email protected] Subject: Re: [VOTE] Release Solr 10.1.0 RC3 The problem with assets I mentioned earlier in the thread is no longer occurring. I'm not sure what the issue was, but the assets are working for me now. Joel Bernstein http://joelsolr.blogspot.com/ On Thu, Oct 22, 2026 at 6:16 AM Andrzej Białecki <[email protected]> wrote: > Please vote for release candidate 3 for Solr 10.1.0 > > The artifacts can be downloaded from: > > https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC3-rev-749712b71940c9f9 6d824c533f32f5c56dcd3924 > > You can run the smoke tester directly with this command: > > python3 -u dev-tools/scripts/smokeTestRelease.py \ > > https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC3-rev-749712b71940c9f9 6d824c533f32f5c56dcd3924 > > You can build a release-candidate of the official docker images (full & > slim) using the following command: > > SOLR_DOWNLOAD_SERVER= > https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC3-rev-749712b71940c9f9 6d824c533f32f5c56dcd3924/solr > && \ > docker build > $SOLR_DOWNLOAD_SERVER/10.1.0/docker/Dockerfile.official-full \ > --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \ > -t solr-rc:10.1.0-3 && \ > docker build > $SOLR_DOWNLOAD_SERVER/10.1.0/docker/Dockerfile.official-slim \ > --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \ > -t solr-rc:10.1.0-3-slim > > The vote will be open for at least 72 hours (not counting the weekend) > i.e. until 2026-10-27 11:00 UTC. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Here is my +1 > ---- > > Cheers, > Andrzej > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
