[HealthAPI] Deterministic shard availability key order

[madalynbartman]

This PR replaces HashMap with LinkedHashMap for deterministic ordering.

Tested by running gradlew :server:test --tests "ShardsAvailabilityHealthIndicatorServiceTests" --no-daemon, gradlew :server:test --tests "Health" --no-daemon, and gradlew check --no-daemon.

Closes #138043

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[nielsbauman]

buildkite test this

[szybia]

buildkite test this

[szybia]

hi @madalynbartman, thank you for your interest in Elasticsearch!

i have some questions:

1. from a quick test i'm not sure whether this achieves what we're setting out to do, with your changes when making requests to a local 3 node cluster i still seem to get different order based on which node i hit. i think needs more research why this is happening even with your changes
2. i would love to see a test added here to test this behavior

[madalynbartman]

@szybia I added some logic to sort projects by ID and indices by name before processing so they come out in a deterministic order then took a page out of your book and tested on a local three node cluster. Please review the latest commit and let me know if I need to adjust something. Appreciate your feedback and patience!

Was your second point asking me to create a unit test for this? I can give it a shot, but to be honest, Im a bit out of my depth there and might need to learn more about the API before doing so.

[szybia]

@madalynbartman hmmm, i still don't quite think your changes do what i believe we want to do here

i tried this out myself and here's what i came up with: https://github.com/elastic/elasticsearch/compare/main...szybia:elasticsearch:deterministic-shards-health?diff=unified&w

if you agree this solves our problem, maybe you can apply something like my changes into this PR

[madalynbartman]

@szybia Tried it out and it worked perfectly. I agree with that approach, thanks for walking me through it. Pushed those changes

[madalynbartman]

Can I please get another review when you get a chance? @szybia

[szybia]

i believe still a few remnants after your initial approach, unless i'm mistaken 🤔 let me know what you think!

[madalynbartman]

@szybia agreed! Just need the LinkedHashMap in getDetails(). Reverted the others

[madalynbartman]

@szybia Would you mind taking another look when you get a chance?

[Copilot]

Pull request overview

This PR addresses deterministic ordering of shard availability keys in the Health API by replacing HashMap with LinkedHashMap. The change ensures that health indicator details are returned with a predictable key order, which is important for API consistency and testing.

Key Changes:

• Modified ShardsAvailabilityHealthIndicatorService to use LinkedHashMap for deterministic key ordering in health indicator details
• Added comprehensive test coverage to verify the key order matches the expected sequence

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
ShardsAvailabilityHealthIndicatorService.java	Refactored getDetails() method to use LinkedHashMap instead of Map.of() for deterministic key ordering
ShardsAvailabilityHealthIndicatorServiceTests.java	Added test case to verify deterministic ordering of shard availability keys

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[samxbr]

LGTM, we can merge after the change log is added and CI is passed. Thank you for contributing to Elasticsearch!

[madalynbartman]

Added change log

[szybia]

buildkite test this

[szybia]

thank you for contributing to Elasticsearch!