-
Notifications
You must be signed in to change notification settings - Fork 717
Sanitize labels in AWS batch #6211
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
base: master
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for nextflow-docs-staging canceled.
|
32540d2
to
4d70df3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will let better Groovy wizards comment on the code, but I think this is a worthwhile feature to make it "just work". From my perspective I want to know:
- If a user puts an invalid label in, how do they know it was dropped?
- Are there weird situations where a label is bypassed?
plugins/nf-amazon/src/main/nextflow/cloud/aws/batch/AwsBatchTaskHandler.groovy
Outdated
Show resolved
Hide resolved
plugins/nf-amazon/src/main/nextflow/cloud/aws/batch/AwsBatchTaskHandler.groovy
Outdated
Show resolved
Hide resolved
plugins/nf-amazon/src/main/nextflow/cloud/aws/batch/AwsBatchTaskHandler.groovy
Outdated
Show resolved
Hide resolved
plugins/nf-amazon/src/main/nextflow/cloud/aws/batch/AwsBatchTaskHandler.groovy
Outdated
Show resolved
Hide resolved
Let's address the comments please |
a3ccb8f
to
ddb6d36
Compare
…TaskHandler. Added methods to sanitize individual labels and a map of labels to comply with AWS constraints. Updated tests to verify sanitization functionality. Signed-off-by: Edmund Miller <[email protected]>
Refined expected outputs for labels with brackets, unicode characters, and special characters to ensure compliance with AWS constraints. Adjusted test cases for length truncation and null handling to reflect accurate sanitization behavior. Signed-off-by: Edmund Miller <[email protected]>
…ging Address PR feedback by enhancing the label sanitization logic with better user experience and code maintainability: - Add warning logs when labels are dropped due to null values - Add warning logs when labels are dropped after failed sanitization - Add warning logs when labels are modified during sanitization - Simplify sanitizeAwsBatchLabel method using method chaining and ternary operator - Follow codebase patterns for length truncation (similar to AbstractGridExecutor) - Improve code readability while maintaining all existing functionality Resolves silent label dropping issue and provides clear feedback to users when resource labels are modified or removed during AWS Batch job submission. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]> Signed-off-by: Edmund Miller <[email protected]>
…tization Add thorough test coverage for null value scenarios specifically addressing the PR comment: "when the item is "item": null is the aws tag silently dropped?" New test coverage includes: - Null values in various combinations (single, multiple, all null) - Null keys handling (actual null keys, not string "null") - Mixed null keys and values scenarios - Verification that logging occurs (not silent dropping) - Edge cases with empty strings that become null after sanitization Tests verify both functional behavior (correct dropping) and UX improvement (explicit logging instead of silent dropping). 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]> Co-authored-by: adamrtalbot <[email protected]> Signed-off-by: Edmund Miller <[email protected]>
ddb6d36
to
9f5c2ea
Compare
Thinking more about this, not sure this should be done. A label string can be an identifier used by an external system reference some resources. If the label is changed silently will result likely in an inconsistent or an error hard to troubleshoot. I think it's better to hard fail in this case |
This should prevent errors such as nf-core/hic#224.
I think this goes with the Nextflow ethos to keep the user from thinking about the nuances of different executors.
But I could also see this not being "expected".