Sanitize labels in AWS batch #6211
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for nextflow-docs-staging canceled.
|
edmundmiller
force-pushed
the
sanitize-labels
branch
from
32540d2 to
4d70df3
Compare
adamrtalbot
reviewed
Jun 23, 2025
There was a problem hiding this comment.
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 |
edmundmiller
force-pushed
the
sanitize-labels
branch
2 times, most recently
from
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 <edmund.miller@seqera.io>
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 <edmund.miller@seqera.io>
…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 <noreply@anthropic.com> Signed-off-by: Edmund Miller <edmund.miller@seqera.io>
…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 <noreply@anthropic.com> Co-authored-by: adamrtalbot <adamrtalbot@users.noreply.github.com> Signed-off-by: Edmund Miller <edmund.miller@seqera.io>
edmundmiller
force-pushed
the
sanitize-labels
branch
from
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 |
|
I see your point. It's also not fun to point people to add a custom sanitize function to their config. What if we added it behind a config option for each executor(that had the feature)? We could leave it off by default. |
…ation
Add optional configuration flag `aws.batch.sanitizeTags` to control AWS Batch
tag sanitization behavior. This allows users to opt-in to automatic sanitization
of resource labels to ensure compliance with AWS Batch naming requirements.
Key changes:
- Add sanitizeTags boolean config option to AwsBatchConfig (default: false)
- Add sanitizeTags() accessor method to AwsOptions
- Update AwsBatchTaskHandler to conditionally apply sanitization based on config
- Add comprehensive tests for enabled, disabled, and default behavior
- Maintain backward compatibility - sanitization is disabled by default
Users can enable sanitization with:
```
aws {
batch {
sanitizeTags = true
}
}
```
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
More than yet another option it would be better to report a warning if the label is not matching AWS constraints and skip it (when strict mode is enabled throw an error) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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".