fix: video/audio Accept-Ranges header never sent, breaking seek in Electron#41575
fix: video/audio Accept-Ranges header never sent, breaking seek in Electron#41575iamtanishqjain wants to merge 1 commit into
Conversation
…ectron The ufs file server only set Accept-Ranges: bytes inside an unreachable else branch (req.headers is always an object for real HTTP requests), so the header was never actually sent. Electron/Chromium's media pipeline needs Accept-Ranges advertised up front to enable seeking; without it, seeking silently fails while playback still works. Range/206 handling itself was already correct - this only fixes the missing advertisement header. Fixes RocketChat#39946 Related to RocketChat#19786 / RocketChat#19866
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
🦋 Changeset detectedLatest commit: 7596f29 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
WalkthroughThe UFS handler now always includes ChangesUFS range response headers
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/meteor/server/ufs/ufs-server.ts (1)
154-154: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRemove the implementation comment.
The header assignment is self-explanatory. As per coding guidelines, “Avoid code comments in the implementation.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/meteor/server/ufs/ufs-server.ts` at line 154, Remove the implementation comment above the Range-support header assignment in the relevant UFS server code, leaving the self-explanatory header assignment unchanged.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@apps/meteor/server/ufs/ufs-server.ts`:
- Line 154: Remove the implementation comment above the Range-support header
assignment in the relevant UFS server code, leaving the self-explanatory header
assignment unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 00b44e47-c24a-49b4-b1b9-b9b43a631228
📒 Files selected for processing (3)
.changeset/fix-desktop-video-seek-accept-ranges.mdapps/meteor/server/ufs/ufs-server.spec.tsapps/meteor/server/ufs/ufs-server.ts
📜 Review details
⏰ Context from checks skipped due to timeout. (1)
- GitHub Check: cubic · AI code reviewer
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation
Files:
apps/meteor/server/ufs/ufs-server.spec.tsapps/meteor/server/ufs/ufs-server.ts
**/*.spec.ts
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.spec.ts: Use descriptive test names that clearly communicate expected behavior in Playwright tests
Use.spec.tsextension for test files (e.g.,login.spec.ts)
Files:
apps/meteor/server/ufs/ufs-server.spec.ts
🧠 Learnings (6)
📚 Learning: 2026-03-16T21:50:37.589Z
Learnt from: amitb0ra
Repo: RocketChat/Rocket.Chat PR: 39676
File: .changeset/migrate-users-register-openapi.md:3-3
Timestamp: 2026-03-16T21:50:37.589Z
Learning: For changes related to OpenAPI migrations in Rocket.Chat/OpenAPI, when removing endpoint types and validators from rocket.chat/rest-typings (e.g., UserRegisterParamsPOST, /v1/users.register) document this as a minor changeset (not breaking) per RocketChat/Rocket.Chat-Open-API#150 Rule 7. Note that the endpoint type is re-exposed via a module augmentation .d.ts in the consuming package (e.g., packages/web-ui-registration/src/users-register.d.ts). In reviews, ensure the changeset clearly states: this is a non-breaking change, the major version should not be bumped, and the changeset reflects a minor version bump. Do not treat this as a breaking change during OpenAPI migrations.
Applied to files:
.changeset/fix-desktop-video-seek-accept-ranges.md
📚 Learning: 2026-02-24T19:22:48.358Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/omnichannel/omnichannel-send-pdf-transcript.spec.ts:66-67
Timestamp: 2026-02-24T19:22:48.358Z
Learning: In Playwright end-to-end tests (e.g., under apps/meteor/tests/e2e/...), prefer locating elements by translated text (getByText) and ARIA roles (getByRole) over data-qa attributes. If translation values change, update the corresponding test locators accordingly. Never use data-qa locators. This guideline applies to all Playwright e2e test specs in the repository and helps keep tests robust to UI text changes and accessible semantics.
Applied to files:
apps/meteor/server/ufs/ufs-server.spec.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
Applied to files:
apps/meteor/server/ufs/ufs-server.spec.tsapps/meteor/server/ufs/ufs-server.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
Applied to files:
apps/meteor/server/ufs/ufs-server.spec.tsapps/meteor/server/ufs/ufs-server.ts
📚 Learning: 2026-03-06T18:10:15.268Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 39397
File: packages/gazzodown/src/code/CodeBlock.spec.tsx:47-68
Timestamp: 2026-03-06T18:10:15.268Z
Learning: In tests (especially those using testing-library/dom/jsdom) for Rocket.Chat components, the HTML <code> element has an implicit ARIA role of 'code'. Therefore, screen.getByRole('code') or screen.findByRole('code') will locate <code> elements even without a role attribute. Do not flag findByRole('code') as invalid in reviews; prefer using the implicit role instead of adding role="code" unless necessary for accessibility.
Applied to files:
apps/meteor/server/ufs/ufs-server.spec.ts
📚 Learning: 2026-05-06T12:21:44.083Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 40256
File: apps/meteor/client/components/CreateDiscussion/CreateDiscussion.tsx:121-149
Timestamp: 2026-05-06T12:21:44.083Z
Learning: Field wrappers in rocket.chat/fuselage-forms (Field, FieldLabel, FieldRow, FieldError, FieldHint) auto-create htmlFor/id associations, aria-describedby, and role="alert" for errors. Do not manually set htmlFor, id, aria-describedby, or role attributes when using these wrappers. This automatic wiring does not apply to plain rocket.chat/fuselage components, which require explicit ID wiring per the accessibility docs. In code reviews, prefer using fuselage-forms wrappers for form fields and verify there is no unnecessary manual ID/aria wiring in files that use these wrappers. If a component uses plain fuselage components, ensure proper id wiring as per docs.
Applied to files:
apps/meteor/server/ufs/ufs-server.spec.tsapps/meteor/server/ufs/ufs-server.ts
🔇 Additional comments (2)
apps/meteor/server/ufs/ufs-server.spec.ts (1)
1-112: LGTM!.changeset/fix-desktop-video-seek-accept-ranges.md (1)
1-5: LGTM!
Proposed changes (including videos or screenshots)
The
ufsfile server (apps/meteor/server/ufs/ufs-server.ts) is supposed to advertiseAccept-Ranges: byteson every response so clients know they can issue byte-rangerequests to seek within an uploaded file. That header was only being set inside the
elsebranch ofif (typeof req.headers === 'object')— a branch that is unreachablefor real HTTP requests, since Node's
http.IncomingMessage.headersis always an object.As a result,
Accept-Ranges: byteswas never actually sent, on any request, regardlessof auth method.
Range/206 parsing itself was already correct — a Range request still got a 206 with a
correct Content-Range. The bug is that the header advertising Range support up front was
silently missing.
This looks like the same underlying symptom class as #19786/#19866, but that earlier fix
was purely client-side (
preload='metadata'on<video>/<audio>), which is stillpresent and unregressed. This PR targets a separate, previously-unnoticed server-side gap.
Caveat / what I could NOT verify: I do not have a working local dev environment
(Meteor/MongoDB/Electron) to reproduce the Electron-specific symptom end-to-end. This
fix is proven with a request-handler-level unit test showing 206 + Content-Range +
Accept-Ranges are all correctly returned. I could not run live curl requests against a
running server comparing cookie vs X-Auth-Token/X-User-Id vs rc_token/rc_uid auth paths,
so I can't rule out that the Electron symptom in #39946 has an additional cause on the
Electron/Rocket.Chat.Electron side. If seeking is still broken after this fix, the next
step is checking whether Electron's net stack strips or ignores
Accept-Ranges/Rangeheaders on its custom protocol handler.
Issue(s)
Fixes #39946
Related to #19786 / #19866
Steps to test or reproduce
curl -I <file-url>on develop — noteAccept-Rangesis absent.Accept-Ranges: bytesis present.curl -H "Range: bytes=0-1023" <file-url>— 206 + Content-Range, unchanged by this fix (already worked).apps/meteor/server/ufs/ufs-server.spec.ts— asserts both cases against the real registered request handler.Summary by CodeRabbit
Bug Fixes
Tests