Skip to content

Refactor GoogleBatchTaskHandler.newSubmitRequest for reduced complexity#6687

Merged
pditommaso merged 2 commits intomasterfrom
refactor/google-batch-submit-request
Jan 3, 2026
Merged

Refactor GoogleBatchTaskHandler.newSubmitRequest for reduced complexity#6687
pditommaso merged 2 commits intomasterfrom
refactor/google-batch-submit-request

Conversation

@pditommaso
Copy link
Member

Summary

Refactors the newSubmitRequest method in GoogleBatchTaskHandler from a monolithic ~250-line method into smaller, focused helper methods.

Before

  • Single method with cyclomatic complexity ~40
  • Mixed concerns: compute resources, containers, allocation policies, networking
  • Difficult to test individual pieces
  • Hidden side effects (modifying taskSpec in nested calls)

After

  • Main method reduced to ~40 lines of clear orchestration
  • 8 new helper methods, each with single responsibility:
Method Purpose
buildComputeResource() CPU, memory, boot disk
buildSpotRetryPolicy() Lifecycle policy for spot retry
buildNetworkPolicy() Network/subnet configuration
buildTaskGroup() Task group with array support
buildContainerRunnable() Container + environment
buildInstancePolicyOrTemplate() Instance template or policy
buildAllocationPolicy() Full allocation policy assembly
buildScratchVolume() Scratch disk volume

Key Design Decisions

  1. Static result classes (AllocationPolicyResult, InstancePolicyResult) instead of output parameters or tuples - provides named properties and clear data flow

  2. Explicit volume handling - scratch volume requirement is returned via result class rather than modifying taskSpec as a side effect

  3. Protected visibility - all helpers are protected to allow subclassing/extension

Benefits

  • Reduced cyclomatic complexity: ~40 → ~10 for main method
  • Improved testability: Each helper can be unit tested independently
  • Better maintainability: Clear separation of concerns
  • Explicit data flow: No hidden side effects via result classes
  • Easier debugging: Smaller methods with focused responsibility

Test Plan

  • All existing GoogleBatchTaskHandlerTest tests pass
  • Added unit tests for new helper methods using Spock where blocks:
    • buildComputeResource - 5 test cases for CPU/memory/disk combinations
    • buildSpotRetryPolicy - verifies retry action and exit codes
    • buildNetworkPolicy - 5 test cases for network/subnet/private combinations
    • buildTaskGroup - verifies task spec inclusion
    • buildScratchVolume - verifies device name and mount path
    • buildContainerRunnable - verifies container options, mounts, environment
    • buildContainerRunnable with fusion - verifies --privileged flag

Break down the monolithic newSubmitRequest method (~250 lines) into
smaller, focused helper methods to improve maintainability and testability.

Changes:
- Extract buildComputeResource() for CPU, memory, boot disk config
- Extract buildSpotRetryPolicy() for spot instance retry lifecycle policy
- Extract buildNetworkPolicy() for network/subnet configuration
- Extract buildTaskGroup() for task group with array support
- Extract buildContainerRunnable() for container and environment setup
- Extract buildInstancePolicyOrTemplate() for instance policy/template
- Extract buildAllocationPolicy() for full allocation policy assembly
- Extract buildScratchVolume() for scratch disk volume creation
- Add AllocationPolicyResult and InstancePolicyResult static classes
  to return multiple values without side effects
- Add unit tests for new helper methods using Spock where blocks

Benefits:
- Reduces cyclomatic complexity of newSubmitRequest from ~40 to ~10
- Each helper method is independently unit-testable
- Clear separation of concerns (compute, container, allocation, network)
- Explicit data flow via result classes instead of hidden side effects
- Easier to understand, maintain, and extend

Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
@netlify
Copy link

netlify bot commented Dec 26, 2025

Deploy Preview for nextflow-docs-staging canceled.

Name Link
🔨 Latest commit 909b1fb
🔍 Latest deploy log https://app.netlify.com/projects/nextflow-docs-staging/deploys/69578699f940cb00077c21c4

@pditommaso pditommaso requested a review from jorgee December 26, 2025 18:25
Copy link
Contributor

@jorgee jorgee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes looks good to me

@pditommaso pditommaso merged commit 38c3910 into master Jan 3, 2026
25 checks passed
@pditommaso pditommaso deleted the refactor/google-batch-submit-request branch January 3, 2026 02:37
pditommaso added a commit that referenced this pull request Jan 16, 2026
…ty (#6687)

Break down the monolithic newSubmitRequest method (~250 lines) into
smaller, focused helper methods to improve maintainability and testability.

Changes:
- Extract buildComputeResource() for CPU, memory, boot disk config
- Extract buildSpotRetryPolicy() for spot instance retry lifecycle policy
- Extract buildNetworkPolicy() for network/subnet configuration
- Extract buildTaskGroup() for task group with array support
- Extract buildContainerRunnable() for container and environment setup
- Extract buildInstancePolicyOrTemplate() for instance policy/template
- Extract buildAllocationPolicy() for full allocation policy assembly
- Extract buildScratchVolume() for scratch disk volume creation
- Add AllocationPolicyResult and InstancePolicyResult static classes
  to return multiple values without side effects
- Add unit tests for new helper methods using Spock where blocks

Benefits:
- Reduces cyclomatic complexity of newSubmitRequest from ~40 to ~10
- Each helper method is independently unit-testable
- Clear separation of concerns (compute, container, allocation, network)
- Explicit data flow via result classes instead of hidden side effects
- Easier to understand, maintain, and extend

Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Co-authored-by: Jorge Ejarque <jorgee@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants