mirror of
https://github.com/yusufipk/OpenFrame.git
synced 2026-09-11 09:36:08 +00:00
yusufipek
4ff801738c
A Bunny init asked the quota whether it could store zero bytes, which is a question with only one answer. Nothing an upload was about to consume was visible to the next request, so every init inside the same window read the same total and every one of them passed, and an upload that could never fit was only refused after it had been sent. The client now declares the size up front. It is checked against the account's remaining room before Bunny is asked for anything, and held as a reservation the next init has to see. The declaration is a claim rather than proof, so it is signed into the upload token: the same token already binds the video id, which is what makes the reservation safe to release on a caller's say-so, since releasing it costs them the video it belongs to. The declared size is then written onto the version or asset row and the reservation is dropped in the same transaction, because Bunny reports no size at all for a video until it has finished encoding it. On a half hour of footage that is most of an hour during which the upload did not appear on the uploader's own storage page and did not count against the next upload. Per-video accounting now takes the larger of what Bunny reports and what was declared, so the estimate stands in until the real figure arrives and Bunny's wins once it does. Two smaller things came out of the same reading. The asset route's in-transaction fallback compared against the plan limit, so a caller quoting a reservation that no longer existed was measured against 200 GiB even on a trial worth three. And the guest branch reserves without being able to release early, because a guest grant is bound to our video id and the caller's network context rather than to the Bunny video, which would let the reservation be dropped while the upload it stands for carried on.
42 lines
1.5 KiB
TypeScript
42 lines
1.5 KiB
TypeScript
// The size a client declares before a direct upload starts.
|
|
//
|
|
// Shared because the R2 and Bunny paths have to agree on it: both hand the
|
|
// number to the storage quota before a single byte moves, so a value one of them
|
|
// would accept and the other would not is a hole in whichever is laxer.
|
|
|
|
export type DeclaredUploadSize = { sizeBytes: bigint } | { error: string };
|
|
|
|
/**
|
|
* Reads a declared upload size, refusing anything that is not a whole positive
|
|
* number of bytes within the host's per-file ceiling.
|
|
*
|
|
* The number is the client's word and is treated as such. Overstating it only
|
|
* spends the caller's own quota, and understating it is caught where the bytes
|
|
* land: R2 compares the object against the declaration and deletes it on a
|
|
* mismatch, and Bunny's own storage reporting replaces the estimate once the
|
|
* upload settles. What is not tolerated is an absent or nonsense value, which is
|
|
* what asking for zero bytes effectively was.
|
|
*/
|
|
export function parseDeclaredUploadSize(raw: unknown, maxBytes: bigint): DeclaredUploadSize {
|
|
if (typeof raw !== 'number' && typeof raw !== 'string' && typeof raw !== 'bigint') {
|
|
return { error: 'sizeBytes must be a positive integer' };
|
|
}
|
|
|
|
let sizeBytes: bigint;
|
|
try {
|
|
sizeBytes = BigInt(raw);
|
|
} catch {
|
|
return { error: 'sizeBytes must be a positive integer' };
|
|
}
|
|
|
|
if (sizeBytes <= BigInt(0)) {
|
|
return { error: 'sizeBytes must be a positive integer' };
|
|
}
|
|
|
|
if (sizeBytes > maxBytes) {
|
|
return { error: 'File exceeds the maximum allowed upload size' };
|
|
}
|
|
|
|
return { sizeBytes };
|
|
}
|