fix(deploy, v1.3): enable CORS on RustFS so browsers can fetch presigned URLs - #8623
Merged
mengw15 merged 1 commit intoSep 21, 2026
Conversation
…Ls (apache#8562) ### What changes were proposed in this PR? Set `RUSTFS_CORS_ALLOWED_ORIGINS=*` on the rustfs service (single-node compose, K8s chart via `extraEnv`, dev compose). The dataset file preview fetches presigned URLs directly from the browser, which is cross-origin. MinIO sent CORS headers by default; RustFS sends none unless this variable is set (the old reflective default was removed as CVE-2026-46685), so the preview shows a loading state and does not render the content. Wildcard mode never allows credentialed requests, and presigned requests carry no cookies, so this restores MinIO's behavior without loosening anything; deployments that want an allow-list can override it with their GUI origin. ### Any related issues, documentation, discussions? Fixes apache#8557. ### How was this PR tested? Tested on single-node deployment. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Fable 5 (Claude Code) (backported from commit af6e0fd) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Contributor
Automated Reviewer SuggestionsBased on the
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release/v1.3 #8623 +/- ##
===============================================
Coverage 94.06% 94.06%
Complexity 4808 4808
===============================================
Files 1194 1194
Lines 48601 48601
Branches 5860 5860
===============================================
Hits 45718 45718
Misses 1429 1429
Partials 1454 1454
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This was referenced Sep 21, 2026
mengw15
deleted the
backport/8562-enable-cors-on-rustfs-so-browsers-can-fe-v1.3
branch
September 21, 2026 20:51
renovate-bot
pushed a commit
to renovate-bot/apache-_-texera
that referenced
this pull request
Sep 21, 2026
…pache#8626) ### What changes were proposed in this PR? `Direct Backport Push` cherry-picks a cleanly-applying fix onto the release branch and pushes it. Every one of those pushes has been rejected since 2026-07-24: `release/*` is covered by the Merge Queue ruleset, which requires a pull request of everyone. apache#8379 tried to exempt the Actions app from it; GitHub refuses to create that bypass, and apache#8624 reverts it. ASF policy points the same way — an automated service must not push to a branch subject to official release without prior authorization from Infrastructure. Both outcomes now open a pull request. The conflicted one is unchanged: a draft, assigned to its author. A clean one opens **ready for review and assigned to nobody**, because there is no code for anyone to write on it. What a clean backport still needs is its checks started, and that is the part worth stating plainly. GitHub creates no workflow run for anything `GITHUB_TOKEN` does, so a bot-opened pull request has none — and nothing will arrive on its own: | action on a pull request with no checks | starts the three required contexts | | --- | --- | | push any commit to the branch | yes (`synchronize`) | | close and reopen it | yes (`reopened`) | | mark it ready for review | **no** — none of the three workflows listens for `ready_for_review` | | add or remove a label | only `Required Checks` | | "Re-run all jobs" | no — with no run there is nothing to re-run | A conflicted backport never had this problem: its author pushes a resolution, and that push brings CI with it. A clean one has nobody to push anything. So the comment the conflict path already posts for its instructions now says, for a clean backport, the one action that works — and says that marking it ready for review is not it. That leaves the release manager three ordinary buttons: reopen, approve, and auto-merge if they would rather not come back when the checks finish. The approval is not automated and should not be: the `release/*` label on the original PR records the decision, and this is the look at the tree that actually lands. Nothing here depends on a token's pull-request scope, on an Actions bypass, or on a close/reopen the workflow performs itself. Those are the paths that can only be proven in production, and that fail quietly when they are wrong — which is how apache#8432, apache#8494 and apache#8562 were lost. `push_entries` is now always empty, leaving `push-backports` unreachable. Removing it is left to a separate change, so that this one is a behaviour change and that one is a pure deletion. ### Any related issues, documentation, discussions? Closes apache#8377. apache#8378 proposed the same routing with the workflow performing the close/reopen itself and arming auto-merge; this drops both in favour of the release manager's own click, and is closed in favour of this. ### How was this PR tested? The routing was driven locally against a stubbed `github-script` environment. With the pre-merge preflight green, both targets come out as pull-request entries carrying `clean: "true"` and `push_entries` empty; with it neutral, `clean: "false"`; with no completed signal, neither target is acted on, as before. Restoring the old `pushEntries.push` turns that check red, so it is not vacuous. The workflow parses, and all four inline `github-script` bodies pass `node --check`. That a bot-opened pull request starts with no checks is what this repository already shows: apache#8584 — bot-opened, one commit, nobody pushed to it — carries no check runs at all, while apache#8553, opened the same way, has the full set after a commit was pushed. That `ready_for_review` does not start them is in the triggers: `required-checks.yml` lists `opened`/`reopened`/`synchronize`/`labeled`/`unlabeled`, `check-header.yml` takes the bare `pull_request:` defaults, and `lint-pr.yml` lists `opened`/`edited`/`reopened`/`synchronize`. Not provable before merge: that a human reopen produces the three contexts on a backport PR. apache#8619 to apache#8623 — five backports into `release/v1.3` opened by hand this week — show that the contexts do appear and pass on a pull request into a release branch; the reopen path shares everything with them but the event that starts the run. ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (claude-opus-5)
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
3 participants
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.
What changes were proposed in this PR?
Backport of #8562 to
release/v1.3: a clean cherry-pick of its squash commit, no adaptations — five added lines across the single-node compose file, the dev compose file and the Helm chart'sextraEnv.This branch needs it because #8550 already made RustFS the default object store here. RustFS sends no CORS headers unless
RUSTFS_CORS_ALLOWED_ORIGINSis set (its reflective default was removed as CVE-2026-46685), while MinIO sent them by default — so without this change a v1.3 deployment renders no dataset file preview: the browser's cross-origin fetch of the presigned URL is blocked and the preview stays in its loading state.Opened manually by the v1.3 release manager: the automated fast path cherry-picked this cleanly and then pushed it straight to
release/v1.3, where the Merge Queue ruleset rejected the push (GH013, run 35305278774). The Actions-app bypass meant to unblock that path (#8379) was never created — asfyaml rejects anIntegrationbypass actor — and the failing job's notification 403s for want ofpull-requests: write, so the loss left neither a backport PR nor a comment on #8562. Therelease/v1.2backport did get a PR (#8585, merged) only because it took the other code path. See #8377.Source: af6e0fd
Any related issues, documentation, discussions?
Backport of #8562. Originally linked #8557.
How was this PR tested?
The change is identical to #8562 (configuration only, no application code); the backport tree is verified byte-identical to cherry-picking the squash commit onto
release/v1.3. Release-branch CI runs the full matrix on this PR, including the integration jobs that provision RustFS.Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (claude-opus-5)