Skip to content

Conversation

@pditommaso
Copy link
Member

Summary

  • Refactored getExitCode() method in GoogleBatchTaskHandler from functional stream-based style to imperative for-loop to fix IntelliJ syntax errors with lambda expressions in Groovy
  • Added StatusEvent import to support the refactored code
  • Added comprehensive unit test using Spock data-driven where clause covering 8 scenarios
  • Added detailed inline comments explaining the logic flow

Changes

GoogleBatchTaskHandler.groovy

  • Replaced stream/filter/max/map chain with explicit for-loop iteration
  • Added comments explaining:
    • Why events are iterated (not guaranteed chronological order)
    • How the latest event is found (by comparing timestamps)
    • Fallback behavior when no exit code found from API

GoogleBatchTaskHandlerTest.groovy

  • Added helper methods makeStatusEventWithTime() and makeTaskStatusWithEvents()
  • Added data-driven test should get exit code from latest task execution event with 8 test cases:
    • null task status - fallback to file
    • empty events list - fallback to file
    • single event with exit code - returns exit code
    • single event with non-zero exit code - returns exit code
    • event without task execution - fallback to file
    • multiple events - returns latest by timestamp
    • multiple events out of order - correctly finds latest
    • mixed events (with/without execution) - filters correctly

Test plan

  • Unit tests pass: ./gradlew :plugins:nf-google:test --tests GoogleBatchTaskHandlerTest
  • New test covers all edge cases for exit code retrieval

🤖 Generated with Claude Code

@netlify
Copy link

netlify bot commented Dec 11, 2025

Deploy Preview for nextflow-docs-staging canceled.

Name Link
🔨 Latest commit 96d903e
🔍 Latest deploy log https://app.netlify.com/projects/nextflow-docs-staging/deploys/693bf4bafef79100073ef7f1

- Change getExitCode visibility from private to protected for testability
- Replace functional stream-based implementation with imperative for-loop
  to fix IntelliJ syntax errors with lambda expressions in Groovy
- Add StatusEvent import to support the refactored code
- Add comprehensive unit test using Spock data-driven where clause
  covering 8 scenarios including null status, empty events, single/multiple
  events, out-of-order timestamps, and mixed events
- Add detailed comments explaining the logic flow

Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
@pditommaso pditommaso force-pushed the refactor-getexitcode-imperative branch from 707d226 to faf54a5 Compare December 11, 2025 08:54
@pditommaso pditommaso requested a review from jorgee December 11, 2025 14:44
@pditommaso
Copy link
Member Author

This was rewritten because intellij was reporting (false positive) compilation errors, still annoying tho.

@bentsherman
Copy link
Member

Do the errors prevent you from building?

@pditommaso
Copy link
Member Author

obviously no, tests were passing

@bentsherman
Copy link
Member

I wonder if the errors go away by replacing the lambdas with closures. Even though it's not desirable, I think Groovy is compiling lambdas the same way as closures anyway, so you might as well use the closure if it removes the error

@pditommaso
Copy link
Member Author

Likely yes, however it's not worth spending more time on this (and i also find a bit more readable the imperative approach)

pditommaso and others added 2 commits December 12, 2025 11:51
…atchTaskHandler.groovy [ci fast]

Co-authored-by: Jorge Ejarque <jorgee@users.noreply.github.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
@pditommaso pditommaso merged commit addd59e into master Dec 12, 2025
11 checks passed
@pditommaso pditommaso deleted the refactor-getexitcode-imperative branch December 12, 2025 11:26
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.

4 participants