skypilot icon indicating copy to clipboard operation
skypilot copied to clipboard

[Core] Add User Specific Exit Codes for Retry

Open lloyd-brown opened this issue 1 month ago • 6 comments

This PR adds support for users to specify particular exit codes that when encountered should cause the job to be automatically recovered.

# This YAML will cause the job to be restarted if the application exits with code 29
resources:
  cpus: 2+
  job_recovery:
    recover_on_exit_codes: [29]

Semantics

  • User specifies the exit codes they want to result in automatic recov
  • If the user jobs exits with a code in exit code in recovery_on_exit_codes we will attempt to restart the job.
  • What about the interaction between recovery_on_exit_codes and max_restarts_on_errors ?
    • If either setting would dictate that we restart the job then we restart the job
    • Why? Because max_restarts_on_errors allows a user to quickly support restarting on user code errors without thinking about which errors might be thrown during the application’s execution. Retaining this required these two settings to be distinct.

Approach

  • We updated the schema for resources: job_recovery: to add a new field recovery_on_exit_codes which accepts a list of exit codes
  • These get populated in the job_recovery dict in the resource for the task
  • When our jobs complete we instrument our CodeGen to update the metadata of the job with the exit codes
  • Then the jobs controller upon job failure will get the exit code by querying the database for the metadata and pulling out the exit code entry from the dictionary
  • It passes the exit codes to the strategy executor which has been updated to check the exit codes to see if they match those specified by the user when making the restart decisions
    • The strategy executor is imbued with the user specified exit codes by parsing the job_recovery dictionary fro the task resources

I've added a smoke test checking this functionality, a unit test to catch any errors in parsing the job_recovery, and docs changes describing the new feature.

Tested (run the relevant ones):

  • [ ] Code formatting: install pre-commit (auto-check on commit) or bash format.sh
  • [ ] Any manual or new tests for this PR (please specify below)
  • [ ] All smoke tests: /smoke-test (CI) or pytest tests/test_smoke.py (local)
  • [ ] Relevant individual tests: /smoke-test -k test_name (CI) or pytest tests/test_smoke.py::test_name (local)
  • [ ] Backward compatibility: /quicktest-core (CI) or pytest tests/smoke_tests/test_backward_compat.py (local)

lloyd-brown avatar Dec 16 '25 22:12 lloyd-brown

Summary of Changes

Hello @lloyd-brown, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the job recovery system by allowing users to define specific exit codes that, when encountered, will automatically trigger a job restart. This provides a more robust and flexible mechanism for handling transient failures, such as network timeouts or specific hardware issues, by ensuring recovery attempts are made for known recoverable error conditions, independent of the general restart limits. The changes involve updates to the job schema, controller logic, and documentation, along with new tests to validate the feature.

Highlights

  • User-Specific Exit Code Recovery: Introduced a new "recover_on_exit_codes" field in "resources.job_recovery" to allow users to specify a list of exit codes that should always trigger job recovery.
  • Flexible Recovery Logic: Jobs will now be restarted if their exit code matches any in "recover_on_exit_codes", overriding the "max_restarts_on_errors" limit for those specific codes. For other non-zero exit codes, "max_restarts_on_errors" still applies.
  • Exit Code Persistence: Job exit codes are now saved to job metadata, enabling the job controller to retrieve and utilize them for informed recovery decisions.
  • Enhanced Documentation & Testing: Updated user documentation to explain the new feature, and added both a smoke test and a unit test to ensure correct functionality and parsing.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

[^1]: Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

gemini-code-assist[bot] avatar Dec 16 '25 22:12 gemini-code-assist[bot]

/smoke-test -k test_managed_jobs_exit_code_recovery /smoke-test -k test_managed_jobs_exit_code_recovery --jobs-consolidation

lloyd-brown avatar Dec 16 '25 22:12 lloyd-brown

/smoke-test -k test_managed_jobs_exit_code_recovery /smoke-test -k test_managed_jobs_exit_code_recovery --jobs-consolidation

lloyd-brown avatar Dec 16 '25 22:12 lloyd-brown

/smoke-test

lloyd-brown avatar Dec 16 '25 23:12 lloyd-brown

/smoke-test -k test_managed_jobs_exit_code_recovery /smoke-test -k test_managed_jobs_exit_code_recovery --jobs-consolidation /smoke-test -k test_managed_jobs_exit_code_recovery --grpc /smoke-test -k test_managed_jobs_exit_code_recovery --jobs-consolidation --grpc

lloyd-brown avatar Dec 17 '25 02:12 lloyd-brown

Only failing test is also failing on master.

lloyd-brown avatar Dec 17 '25 19:12 lloyd-brown

/smoke-test -k test_managed_jobs_exit_code_recovery /smoke-test -k test_managed_jobs_exit_code_recovery --jobs-consolidation /smoke-test -k test_managed_jobs_exit_code_recovery --grpc /smoke-test -k test_managed_jobs_exit_code_recovery --jobs-consolidation --grpc

lloyd-brown avatar Dec 18 '25 03:12 lloyd-brown

/smoke-test

lloyd-brown avatar Dec 18 '25 03:12 lloyd-brown

/smoke-test

lloyd-brown avatar Dec 18 '25 03:12 lloyd-brown

/smoke-test

lloyd-brown avatar Dec 18 '25 03:12 lloyd-brown

/quicktest-core /quicktest-core --base-branch releases/0.10.5

Michaelvll avatar Dec 18 '25 04:12 Michaelvll