SOLR-18098: force an FS directory factory in IndexFetcherPacketProtocolTest

[serhiy-bzhezytskyy]

IndexFetcherPacketProtocolTest fails deterministically on main with seed 6FA33BD8BF6D0D4C:

IndexFetcherPacketProtocolTest > testSingleByte FAILED
    java.lang.AssertionError: fetchPackets return code mismatch expected:<0> but was:<1>

The test stages a file into the index directory and reads it back through the replication fetch path. When the randomized directory factory is an ephemeral (RAM) one like ByteBuffersDirectory, the staged file is not visible to the fetch path, so the server side throws NoSuchFileException, no bytes are sent, and fetchPackets returns a non-zero code. With an FS-backed factory (the default random pick most of the time) it passes, which is why it looks flaky.

This is the same reason TestReplicationHandler forces an FS factory via useFactory(null) in its tests — replication reads real files from the index dir. The SOLR-18098 test just didn't do the same.

Fix: call useFactory(null) in @BeforeClass (and resetFactory() in @AfterClass).

Verified: the previously failing seed 6FA33BD8BF6D0D4C now passes, along with several other random seeds.

[gerlowskija]

Hey @serhiy-bzhezytskyy - thanks for the PR!

I merged a fix to main yesterday that was intended to address the failures in this test. Do you know whether you had that locally in your testing?

I guess I'm trying to figure out whether this is fixing the same issue as the already merged #4624 , or whether it's totally separate and still needed even with #4624 merged?

[serhiy-bzhezytskyy]

You're right — this is the same issue and #4624 supersedes it. I branched from main on 07-14, before #4624 merged (07-15), so I still reproduced the flake locally, which is what sent me down this path.

I just pulled current main (with #4624) and ran the previously-failing seed:

./gradlew :solr:core:test --tests "org.apache.solr.handler.IndexFetcherPacketProtocolTest" -Ptests.seed=6FA33BD8BF6D0D4C

→ passes now. Your fix (using DirContext.REPLICATION so the test's write and the sender's read hit the same unwrapped delegate) is the more general fix — mine just forced an FS factory to sidestep it. Closing this as superseded. Thanks!