Sort offers by price within availability groups in _get_job_plan

[megheaiulian]

Summary

Fixes #3839

_get_job_plan() sorted offers only by availability (not offer.availability.is_available()), preserving the input order from heapq.merge. Since backend offers are not guaranteed to be price-sorted (gpuhunt explicitly documents its results as "not strictly sorted by the price"), cheap offers from one backend (e.g., Vast.ai at $0.37) could be buried behind expensive offers from another backend (e.g., RunPod at $0.98).

This was the root cause of #3839: dstack apply showed RunPod offers ($0.98+) before cheaper Vast.ai offers ($0.37+), while dstack offer correctly sorted by price because it uses get_backend_offers_in_run_candidate_fleets() which explicitly sorts by price.

Changes

• plan.py:835: Add offer.price as secondary sort key so that within each availability group, offers are sorted cheapest-first:

  # Before:
  job_offers.sort(key=lambda offer: not offer.availability.is_available())
  # After:
  job_offers.sort(key=lambda offer: (not offer.availability.is_available(), offer.price))

• test_plan.py: Add TestGetJobPlan with 5 tests:

  • test_sorts_available_offers_by_price — available offers sorted by price even when input is out of order
  • test_sorts_not_available_offers_by_price — NOT_AVAILABLE offers also sorted by price
  • test_sorts_mixed_availability_by_availability_then_price — available group sorted by price, then NOT_AVAILABLE group sorted by price (inputs in reverse price order to verify sort, not just stable order)
  • test_sorts_unsorted_multi_backend_offers_by_price — reproduces the bug: RunPod offers ($0.98, $1.49) before Vast.ai ($0.37, $1.22) in input, verifying price sort produces correct order
  • test_instance_offers_and_backend_offers_sorted_by_availability_then_price — expensive IDLE pool instance ($0.98) sorts after cheap AVAILABLE backend offer ($0.37)

How to test

dstack apply -f service.yaml --max-offers 300

Before: RunPod offers ($0.98+) appear before cheaper Vast.ai offers ($0.37+)
After: All offers sorted by price ascending within availability groups

[jvstme]

If I'm not mistaken, sorting here:

• Only affects the run plan shown in dstack apply, but doesn't affect the actual provisioning order.
• Can shuffle the available instance_offers (representing idle instances) and backend_offers (representing new instances to be provisioned), which is not expected — idle instances should always come first regardless of the price, as dstack prefers reusing them over provisioning new ones.

Anyways, I'm not sure if we want to sort by price in the first place, please see my issue comment