Use 'FIXED' path type in DedicatedClusterSnapshotRestoreIT

[andrross]

If HASHED_PREFIX or HASHED_INFIX is used in this test then it frequently fails. @ashking94 Can you take a look here? I'm guessing there might be a bug with snapshot cleanup for the new remote store path types. This is really more of a short-term work-around to avoid the new path types for this particular test case, but it does seem to resolve the flakiness of the test.

Related Issues

Resolves #15806

Check List

• Functionality includes testing.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[andrross]

For posterity here are three seeds that reliably fail without this change:

./gradlew ':server:internalClusterTest' --tests "org.opensearch.snapshots.DedicatedClusterSnapshotRestoreIT.testSnapshotWithStuckNode" -Dtests.seed=8529B1DD622216C1

./gradlew ':server:internalClusterTest' --tests "org.opensearch.snapshots.DedicatedClusterSnapshotRestoreIT.testSnapshotWithStuckNode" -Dtests.seed=AE568A72925374C5

./gradlew ':server:internalClusterTest' --tests "org.opensearch.snapshots.DedicatedClusterSnapshotRestoreIT.testSnapshotWithStuckNode" -Dtests.seed=97C1E518CA9406A4

[andrross]

I ran this test in a loop for about an hour choosing a different seed every time and saw no failures. Without this change the same scenario will usually fail in less than a minute.

[github-actions]

❌ Gradle check result for aebac93: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[ashking94]

Sure, @andrross. Let me take a look at this.

[andrross]

@ashking94 FYI, I was later able to trace this down to a specific commit: #15806 (comment) I think @gbbafna is also looking at this. In the short term I think we can still merge this PR to reduce/remove the flakiness.

[github-actions]

❌ Gradle check result for 850ecd7: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[ashking94]

@ashking94 FYI, I was later able to trace this down to a specific commit: #15806 (comment) I think @gbbafna is also looking at this. In the short term I think we can still merge this PR to reduce/remove the flakiness.

Makes sense, approved.

[ashking94]

Restarted the PR build.

[github-actions]

❌ Gradle check result for 850ecd7: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 850ecd7: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

✅ Gradle check result for 850ecd7: SUCCESS

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.45%. Comparing base (cbaddd3) to head (850ecd7).
Report is 25 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #17996      +/-   ##
============================================
- Coverage     72.51%   72.45%   -0.06%     
+ Complexity    67108    67052      -56     
============================================
  Files          5475     5478       +3     
  Lines        309916   310034     +118     
  Branches      45060    45066       +6     
============================================
- Hits         224725   224631      -94     
- Misses        66895    67031     +136     
- Partials      18296    18372      +76     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.