Repository navigation
Discover executable bundles by footer, not by execute bit - #74227
Merged
Merged
Conversation
An object-store Dag bundle such as S3DagBundle has no concept of file permissions, so a Go bundle synced through one always loses the execute bit a build produced. ExecutableCoordinator required that bit to scan a candidate at all, so those bundles were unreachable, with no path short of a side-channel init container to restore it. The scanner now considers every regular file and relies on the existing footer-magic and binary_sha256 checks to identify a bundle. A file that matches the requested dag_id is marked executable, mirroring its read bits, before it is launched. Co-Authored-By: Claude <noreply@anthropic.com>
jason810496
requested review from
amoghrajesh,
ashb and
uranusjr
as code owners
October 5, 2026 10:11
boring-cyborg
Bot
added
area:coordinator
guan404ming
reviewed
Oct 5, 2026
guan404ming
left a comment
guan404ming
left a comment
Member
There was a problem hiding this comment.
Looks nice, just left some comments!
…as skipped An already-executable bundle whose mode is not exactly the 'read implies execute' pattern this function produces (0o744, say) was rewritten anyway, which could fail on a mount where chmod itself is refused even though the file already runs fine. Check os.access first and return early. Mark executable only after the candidate has fully passed schema validation, not before, so a bundle that gets rejected is never touched. A chmod failure is now recorded in the same 'rejected' list the metadata checks already use, so it surfaces in the raised error instead of being indistinguishable from no match at all. Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
jason810496
commented
Oct 6, 2026
jason810496
left a comment
jason810496
left a comment
Member
Author
There was a problem hiding this comment.
Thanks for the review, they're all valid concerns, I just addressed them in the latest commits.
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
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.
Unblocks serving a Go executable bundle from an object-store Dag bundle, needed for the native Go Dag work in the lang-SDK e2e stack (related: #73847).
Why
ExecutableCoordinatoronly scanned files that already had the execute bit set. An object-store Dag bundle such asS3DagBundlehas no concept of file permissions, so a Go bundle synced through one always lost the execute bit a build produced, and was never found.The only workaround was a side-channel init container that re-stages the bundle with a forced chmod outside the normal Dag-bundle path.
How
binary_sha256checks, so non-bundle files are ignored exactly as before.dag_idis marked executable, mirroring its read bits, right before it is launched.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5.5) following the guidelines