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 > <https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC3-rev-749712b71940c9f96d824c533f32f5c56dcd3924> > > > > 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 > <https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC3-rev-749712b71940c9f96d824c533f32f5c56dcd3924> > > > > 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 > <https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC3-rev-749712b71940c9f96d824c533f32f5c56dcd3924/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] > > > > > > >
