minor: Prioritize load of unavailable segment

[kfaraz]

Description

If a segment becomes unavailable after it has been added to the load queue of a historical, it might remain stuck in the queue while other segments are being loaded. Ideally, all unavailable segments should be prioritized.

Changes

• Simplify book-keeping in ServerHolder by getting rid of method simplify() and treat REPLICATE and LOAD actions as distinct
• In StrategicSegmentAssigner.updateReplicasInTier(), check if an unavailable segment needs to be prioritized and change all in-flight REPLICATE actions on that segment to LOAD.
• Update LoadQueuePeon.getSegmentsInQueue to return a List instead of a Set and verify the result in Coordinator simulations

Pending

Handle the same change for updateReplicasInTierPartial.

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[FrankChen021]

Severity	Findings
P0	0
P1	1
P2	2
P3	0
Total	3

Reviewed 12 of 12 changed files.

---

This is an automated review by Codex GPT-5.6-Luna(max)

[FrankChen021]

[P1] Rebuild status after reprioritization

segmentStatus is built before this loop converts REPLICATE actions to LOAD. If a tier has a queued replicate surplus, the later surplus branch still looks in the snapshot's REPLICATE list while the LOAD list is empty, so it can cancel neither action and leave excess loads queued. Rebuild the status after reprioritization or reconcile the affected servers directly before surplus cancellation.

[kfaraz]

Moved the load prioritization to after the cancellation of REPLICATE/LOAD operations.
Any remaining REPLICATE operations after the cancellation will get prioritized.

[FrankChen021]

Verified on the current head: surplus REPLICATE/LOAD cancellation now runs before the unavailable-segment reprioritization loop. Canceled replicas are skipped by the action check, while remaining REPLICATE operations can be promoted. I reviewed 12 of 12 changed files and found no remaining issues.

[FrankChen021]

[P2] Include REPLICATE in loading segments

By preserving REPLICATE here, getLoadingSegments() still filters for exact LOAD at line 353. TierSegmentBalancer uses that accessor to prioritize cheap moves, so queued replica loads are omitted from the prioritized set. Make the accessor use action.isLoad() or otherwise include REPLICATE.

[kfaraz]

fixed.

[FrankChen021]

Verified on the current head: ServerHolder now keeps REPLICATE distinct, and getLoadingSegments() includes both LOAD and REPLICATE. The queued replica is therefore visible to the loading-segment path used by the balancer. I reviewed 12 of 12 changed files and found no remaining issues.

[FrankChen021]

[P2] Preserve queue budget when replacing REPLICATE

prioritizeLoadOfUnavailableSegment first cancels REPLICATE, then queues the same segment as LOAD through startOperation. startOperation increments totalAssignmentsInRun for every load, while cancellation does not decrement it; replacing one queue slot therefore consumes an extra per-run budget and can make isLoadQueueFull() reject unrelated loads. Preserve the replacement's existing slot and accounting.

[kfaraz]

Can be ignored for now since it is basically a dead branch which is effective only when maxSegmentsInLoadQueue != 0.

[FrankChen021]

The queue-cap concern still applies for the supported nonzero-cap configuration. SegmentLoadingConfig.create uses maxSegmentsInNodeLoadingQueue when smart loading is disabled (the configured default for that mode is 500), and ServerHolder initializes maxAssignmentsInRun as the cap minus the existing load queue. prioritizeLoadOfUnavailableSegment cancels one queued REPLICATE and then calls startOperation(LOAD), which increments totalAssignmentsInRun; replacing an item without changing queue length therefore consumes a new slot and can make isLoadQueueFull() reject an unrelated load while capacity remains. Please preserve the replacement's existing slot/accounting, or otherwise avoid charging this conversion as a new queued segment.

Reviewed 12 of 12 changed files.

[FrankChen021]

I reviewed the current head and verified both follow-up fixes: REPLICATE is preserved through ServerHolder and surfaced by getLoadingSegments(), and reprioritization runs after surplus cancellation. I found no additional correctness, edge-case, concurrency, security, compatibility, integration, or missing-test issues in the current change.

Reviewed 12 of 12 changed files.

---

This is an automated review by Codex GPT-5.6-Luna(max)