Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WX-1468] Implement returnCodes runtime attribute #7389

Merged
merged 28 commits into from
Apr 11, 2024
Merged

[WX-1468] Implement returnCodes runtime attribute #7389

merged 28 commits into from
Apr 11, 2024

Conversation

rsaperst
Copy link
Contributor

Implemented the returnCodes runtime attribute, which is new in WDL 1.1.

@jgainerdewar
Copy link
Contributor

This is fantastic work! Which makes me feel terrible saying: I hadn't realized until reviewing the spec just now that the new returnCodes actually means exactly the same thing as the existing continueOnReturnCode, with the addition of *. Would it be possible to modify the existing continueOnReturnCode handling to include the runtime attribute returnCodes rather than creating a parallel method for controlling the same thing?

@rsaperst rsaperst marked this pull request as ready for review March 21, 2024 13:48
@rsaperst rsaperst requested a review from a team as a code owner March 21, 2024 13:48
@rsaperst
Copy link
Contributor Author

This is fantastic work! Which makes me feel terrible saying: I hadn't realized until reviewing the spec just now that the new returnCodes actually means exactly the same thing as the existing continueOnReturnCode, with the addition of *. Would it be possible to modify the existing continueOnReturnCode handling to include the runtime attribute returnCodes rather than creating a parallel method for controlling the same thing?

I abstracted out the duplicated code between returnCodes and continueOnReturnCode to a new trait ReturnCode (which is very creatively named :) ). I think this is the best solution to avoid code duplication while also supporting both returnCodes and continueOnReturnCode`, but let me know if there is anything else I should modify to decrease parallelism.

Copy link
Contributor

@jgainerdewar jgainerdewar left a comment

Choose a reason for hiding this comment

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

This is a big improvement, but I think we can go even farther in collapsing these two concepts.

* `continueOnReturnCode` will be used.
*/
lazy val returnCode: ReturnCode =
if (returnCodes.isInstanceOf[ReturnCodeSet] && returnCodes.equals(ReturnCodeSet(Set(0)))) continueOnReturnCode
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like this is checking whether we have the default value for returnCodes and falling back to continueOnReturnCode if we do. What if someone included the default value in their WDL? Can we insert the default after we choose which attribute to use?

If not, we could build the default check into ReturnCode, so we can call something like returnCodes.isDefault?

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, just for fun, a more idiomatic Scala way to write this is:

returnCodes match {
  case ReturnCodeSet(Set(0)) => continueOnReturnCode
  case _ => returnCodes
}

* @param returnCode Return code from the process / script.
* @return True if the call is a success.
*/
override def continueFor(returnCode: Int): Boolean = super.continueFor(returnCode)
Copy link
Contributor

Choose a reason for hiding this comment

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

This method looks like a no-op, since it overrides the super method and then calls it.

instance.withDefault(configDefaultWdlValue(runtimeConfig) getOrElse WomInteger(0))
def configDefaultWdlValue(runtimeConfig: Option[Config]): Option[WomValue] =
instance.configDefaultWomValue(runtimeConfig)
}

class ContinueOnReturnCodeValidation extends RuntimeAttributesValidation[ContinueOnReturnCode] {
class ContinueOnReturnCodeValidation extends ReturnCodeValidation {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would love to see if we can collapse all the return code stuff into this validation, and have this be the last thing in the code path that's aware of the two different attributes. We could even continue calling it ContinueOnReturnCode to minimize the diff. This validation can look at both keys and make a decision about what ContinueOnReturnCode object to build. We can turn the * into a ContinueOnReturnCodeFlag(true), which seems to have the same meaning.

@rsaperst
Copy link
Contributor Author

This is a big improvement, but I think we can go even farther in collapsing these two concepts.

I believe that all of the comments here should be addressed in my most recent refactor which groups continueOnReturnCode and returnCodes together as much as I think they can be, let me know if there's any better way that I can refactor or improve the PR!

Copy link
Contributor

@jgainerdewar jgainerdewar left a comment

Choose a reason for hiding this comment

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

Love that this is mostly test changes at this point! Very nice!

@@ -96,6 +96,14 @@ jobs:
- uses: ./.github/set_up_cromwell_action #This github action will set up git-secrets, caching, java, and sbt.
with:
cromwell_repo_token: ${{ secrets.BROADBOT_GITHUB_TOKEN }}
# If a build step fails, activate SSH and idle for 30 minutes.
- name: Setup tmate session
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we take this out before merging, or is it meant to be permanent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this will be removed before merging (its still in for debugging right now)

Copy link
Collaborator

@aednichols aednichols left a comment

Choose a reason for hiding this comment

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

I really like the new direction. Always worth it to put in extra effort to get less code.

I do have one comment about reducing duplication (ironic, I know, in light of the biscayne vs. cascades thing...) but this looks good and very close!

Copy link
Contributor

@jgainerdewar jgainerdewar left a comment

Choose a reason for hiding this comment

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

This is shaping up really well! I think getFinalRuntimeAttributes could use a pass of Scala-ification, I left a few comments but probably a good topic for mob time tomorrow.

@rsaperst rsaperst merged commit 3cf06bf into develop Apr 11, 2024
32 checks passed
@rsaperst rsaperst deleted the wx1468 branch April 11, 2024 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants