Summary

This PR unifies exit code handling behavior across all cloud provider executors (AWS Batch, Azure Batch, Google Batch, and Kubernetes). Previously, different executors had inconsistent approaches to obtaining task exit codes, which led to issues like missing Fusion exit codes (#6481) and unnecessary I/O overhead (#6445).

Changes

Unified Exit Code Strategy

All cloud providers now follow a consistent two-step approach:

1. Primary: Get exit code from the scheduler/cloud API
2. Fallback: Read .exitcode file only when API returns null (not when it returns 0)

Fixes by Provider

Benefits

• Correct exit codes: Fusion exit codes (174/175) and other scheduler-reported failures are now properly captured from Google Batch API
• Reduced I/O: Eliminates unnecessary .exitcode file reads for successful tasks (exit code 0)
• Better scalability: Particularly beneficial for workloads with many fine-grained jobs
• Lower storage costs: Reduces remote file storage access (S3, Azure Blob, GCS)
• Consistent behavior: All cloud executors now behave the same way

Closes

• Nextflow doesn't capture Fusion exit codes from Google Batch API #6481 - Nextflow doesn't capture Fusion exit codes from Google Batch API
• Optimize exit code handling by relying on scheduler status for successful executions #6445 - Optimize exit code handling by relying on scheduler status for successful executions

Test Coverage

Added comprehensive unit tests for all affected handlers verifying:

• Exit code from API is used when available
• Fallback to .exitcode file when API returns null
• No fallback when API returns 0 (success)
• Error exit codes (non-zero) are correctly captured