GameCult/Ratatoskr
Watch
9
0
Fork
You've already forked Ratatoskr
 0
Code Issues Pull requests Projects Releases 3 Packages Wiki Activity Actions

Files desk: refuse files over the server's upload cap before sending #157

Merged
void merged 2 commits from void/files-desk-cut5 into dev 2026-11-14 01:47:42 +00:00
Conversation 0 Commits 2 Files changed 5 +180 -12
void commented 2026-11-14 01:45:51 +00:00
Member
Copy link

Follow-up ratatoskr:follow_up:chat-mind-20261114T014146289Z-t0, Files desk cut 5 (the "client refuses a larger file before sending" rule of docs/commons-files-desk.md, Option A, upload rules).

  • splitBySize / createShareController: files larger than the server's m.upload.size (read from MediaConfig, wired in ShareSet through maxBytes) are named in the note (Too large for this server (limit 50 MB): film.mp4) and dropped from the pick before any upload or album root. A pick of only such files sends nothing and creates no root. A file of exactly the cap goes. No stated cap, or a file with no size, refuses nothing.
  • Over-cap files are not kept for retry (a retry cannot help them); failed small files still are.
  • The cap is read live from the server, not hard-coded; Eureka's 50 MiB is only the doc's example.

Tests (consumer side, through the controller a person taps Send on): note text, what is sent, what stays picked, the exact-cap edge, an all-refused pick, the room not left busy, no-cap, fractional cap; ShareSet wiring of m.upload.size. Mutations checked: > to >= fails the edge test, a dropped cap fails seven.

Does not depend on Eureka's remaining answers or Meta's Q-M. Behind fileZoneShare.enabled like the rest of sharing.

Untested: against a real homeserver (the server's own M_TOO_LARGE refusal still has its sentence for files whose size the client could not read).

🤖 Generated with Claude Code

Follow-up `ratatoskr:follow_up:chat-mind-20261114T014146289Z-t0`, Files desk cut 5 (the "client refuses a larger file before sending" rule of `docs/commons-files-desk.md`, Option A, upload rules). - `splitBySize` / `createShareController`: files larger than the server's `m.upload.size` (read from `MediaConfig`, wired in `ShareSet` through `maxBytes`) are named in the note (`Too large for this server (limit 50 MB): film.mp4`) and dropped from the pick before any upload or album root. A pick of only such files sends nothing and creates no root. A file of exactly the cap goes. No stated cap, or a file with no size, refuses nothing. - Over-cap files are not kept for retry (a retry cannot help them); failed small files still are. - The cap is read live from the server, not hard-coded; Eureka's 50 MiB is only the doc's example. Tests (consumer side, through the controller a person taps Send on): note text, what is sent, what stays picked, the exact-cap edge, an all-refused pick, the room not left busy, no-cap, fractional cap; `ShareSet` wiring of `m.upload.size`. Mutations checked: `>` to `>=` fails the edge test, a dropped cap fails seven. Does not depend on Eureka's remaining answers or Meta's Q-M. Behind `fileZoneShare.enabled` like the rest of sharing. Untested: against a real homeserver (the server's own M_TOO_LARGE refusal still has its sentence for files whose size the client could not read). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Files desk: refuse files over the server's upload cap before sending
Some checks failed
Build pull request / Build pull request (pull_request) Has been cancelled
Details
65d7e7a46a 
A file larger than m.upload.size is named in the note and dropped from the pick before any
upload or album root; a pick of only such files sends nothing. No stated cap or no file size
refuses nothing.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Size refusal: a failed run still names the refused files; a cap that is not a positive number is no cap
All checks were successful
Build pull request / Build pull request (pull_request) Successful in 3m59s
Details
907635917e 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
void merged commit 398b172e21 into dev 2026-11-14 01:47:42 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
GameCult/Ratatoskr!157
No description provided.