Fix artifact staging filenames on Windows#39363
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses an issue where artifact staging would fail on Windows due to invalid characters in environment IDs. By sanitizing these IDs before they are used in file paths, the system now avoids InvalidPathException errors, ensuring consistent behavior across different operating systems. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces sanitization for environment names when creating artifact filenames by replacing invalid characters (such as <>:"/\\|?*) with underscores, and adds a corresponding unit test. The feedback suggests precompiling the regular expression pattern to improve performance and enhancing the unit test to assert that the physical file created is indeed sanitized, ensuring the test is effective across all platforms.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| // all path separators. | ||
| List<String> components = Splitter.onPattern("[^A-Za-z-_.]]").splitToList(path); | ||
| String base = components.get(components.size() - 1); | ||
| String sanitizedEnvironment = environment.replaceAll("[<>:\"/\\\\|?*]", "_"); |
There was a problem hiding this comment.
To avoid compiling the regular expression pattern on every invocation of createFilename, it is highly recommended to precompile the pattern as a private static final Pattern constant at the class level.
For example:
private static final Pattern INVALID_WINDOWS_CHARS = Pattern.compile("[<>:\"/\\\\|?*]");| String sanitizedEnvironment = environment.replaceAll("[<>:\"/\\\\|?*]", "_"); | |
| String sanitizedEnvironment = INVALID_WINDOWS_CHARS.matcher(environment).replaceAll("_"); |
| assertEquals(1, staged.size()); | ||
| checkArtifacts(contentsList, staged.get(environment)); |
There was a problem hiding this comment.
Since : is a valid filename character on Unix-like operating systems (such as Linux and macOS), this test will pass on those platforms even without the sanitization fix. To ensure the test actually verifies the sanitization behavior across all platforms (including CI environments running on Linux), consider asserting that the physical file created in the staging directory contains the sanitized environment string (0_ref_Environment_default) and does not contain the colon (:).
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
4 similar comments
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Assigning reviewers: R: @chamikaramj added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Assigning reviewers: R: @damccorm added as fallback since no labels match configuration Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Thanks for the fix. Both bot review comments sounds reasonable. Please check them. |
There was a problem hiding this comment.
Thanks for the fix, and sorry for the wall of text in my first pass. I've condensed it into a single inline comment on the changed line.
One separate thing, not for this PR: InvalidPathException is unchecked, so it escapes the catch (IOException | InterruptedException) in StoreArtifact.call() and skips totalPendingBytes.setException(). That's #39364.
| // all path separators. | ||
| List<String> components = Splitter.onPattern("[^A-Za-z-_.]]").splitToList(path); | ||
| String base = components.get(components.size() - 1); | ||
| String sanitizedEnvironment = environment.replaceAll("[<>:\"/\\\\|?*]", "_"); |
There was a problem hiding this comment.
base on the line above isn't sanitized, and I think it can carry the same characters this is fixing.
The splitter pattern has a stray ] outside the character class, so it only splits on an invalid char followed by a literal ], and base ends up being the whole path:
path=C:\Users\me\artifact.jar -> base=C:\Users\me\artifact.jar
That branch is taken when roleUrn != STAGING_TO_ARTIFACT_URN and typeUrn == FILE_ARTIFACT_URN, which is the case for Go pipelines (graphx/translate.go:147-152) and for Python pypi_requirements (stager.py:131-137). Linux doesn't notice because LocalFileSystem.create mkdirs the parents, so it just makes nested directories.
Would it make sense to fix the pattern to [^A-Za-z-_.], or to sanitize the composed name instead of just environment? I traced this statically and haven't reproduced it, so worth a second look.
| // all path separators. | ||
| List<String> components = Splitter.onPattern("[^A-Za-z-_.]]").splitToList(path); | ||
| String base = components.get(components.size() - 1); | ||
| String sanitizedEnvironment = environment.replaceAll("[<>:\"/\\\\|?*]", "_"); |
There was a problem hiding this comment.
nit: consider an allowlist such as [^A-Za-z0-9-_.] rather than a denylist. It would match the shape of the splitter just above and of SdkComponents.java:204, and it also covers ASCII control characters 0x00-0x1F, which are invalid on Windows as well. Probably can't occur in an environment id, so feel free to ignore.
There was a problem hiding this comment.
I understand non-ascii unicode file names are acceptible?
There was a problem hiding this comment.
Yes, you're right. Windows accepts Unicode filenames, so the ASCII-only allowlist would unnecessarily replace valid non-ASCII characters and is probably too restrictive for this fix.
The narrower denylist makes more sense here. If covering control characters is worthwhile, they could instead be added explicitly, for example [\x00-\x1F<>:"/\|?*], while preserving Unicode. Thanks for pointing that out.
There was a problem hiding this comment.
Thanks for tracing this. Good catch on the splitter pattern and base potentially carrying invalid filename characters as well.
I agree that an ASCII-only allowlist would be unnecessarily restrictive for valid Unicode filenames. I'll update the fix to preserve Unicode while sanitizing Windows-invalid characters, and I'll also take another look at the splitter issue so that both the environment-derived and artifact-derived parts of the generated filename are safe.
I'll add/update the regression tests accordingly.
| String sanitizedEnvironment = environment.replaceAll("[<>:\"/\\\\|?*]", "_"); | ||
| return clip( | ||
| String.format("%s-%s-%s", idGenerator.getId(), clip(environment, 25), base), 100); | ||
| String.format("%s-%s-%s", idGenerator.getId(), clip(sanitizedEnvironment, 25), base), |
There was a problem hiding this comment.
nit: a trailing . or space is invalid on Windows too, and can still survive here, either from base or from clip(..., 100) landing on one. Low impact, since Windows strips them on both write and read.
Fixes #39336
What is the issue?
Artifact staging can fail on Windows when an environment ID contains characters that are invalid in Windows filenames, such as
:. The environment ID was previously embedded directly into the generated staging filename, causing anInvalidPathExceptionbefore the pipeline could run.What does this PR do?
:to verify that artifact staging succeeds on Windows.Testing
./gradlew :runners:java-fn-execution:test --tests "org.apache.beam.runners.fnexecution.artifact.ArtifactStagingServiceTest"./gradlew :runners:java-fn-execution:spotlessCheck./gradlew :runners:java-fn-execution:checkAll tests and checks pass successfully.