Skip to content

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 348858c
🔍 Latest deploy log https://app.netlify.com/projects/nextflow-docs-staging/deploys/694ed2e85ae4150008063a8d
@pditommaso pditommaso requested a review from jorgee December 26, 2025 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants