nick-boss-tech commented on PR #5312: URL: https://github.com/apache/solr/pull/5312#issuecomment-6774366289
🤖 *AI text below* 🤖 *(reviewed by Nick Shanin)* I found one edge case in the cache check: ZooKeeper creation time has millisecond resolution, so a recreated resource can have the same `ctime` and version as the cached one. In that case the old parsed config or schema can still be reused. I put together a small [follow-up](https://github.com/nick-boss-tech/solr/compare/0848e85fad1290ed604f881abb265b060be3075f...1d71a1b3811b1e9c7fe9bcac7ade1c8bc695ecb0) that compares the creation transaction ID (`czxid`) and version instead. On Linux at `1d71a1b3811b1e9c7fe9bcac7ade1c8bc695ecb0`, all 3 `MultipleManagedSchemasTest` tests and `TestCollectionAPI.testConfigCaching` passed without skips. Tidy left the tree clean, and `check -x test` passed with the host's egress-CA truststore configured. With the new test overlaid on the original PR head, the collision test failed at the expected assertion because the old cached object was returned. That collision test uses mocked ZooKeeper stats; the configset recreation test exercises a real ZooKeeper-backed collection. If useful, you can take the tested commits without rewriting your branch: ```sh git switch SOLR-18632-recreated-configset-cache git fetch https://github.com/nick-boss-tech/solr.git solr-18632-submit git merge --ff-only 1d71a1b3811b1e9c7fe9bcac7ade1c8bc695ecb0 ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
