mirror of
https://github.com/yusufipk/OpenFrame.git
synced 2026-09-11 09:36:08 +00:00
Two reasons the number on the storage page could read as nothing. The per-user Bunny figure was computed inside a two minute cache. The declared size lands on the row in the same transaction that deletes the reservation, so for up to two minutes an upload that had just succeeded counted as nothing: usage fell back towards zero and the next upload was measured against a total that ignored the one before it. The call to Bunny stays cached, because it is the slow half and its answer is the same for everybody. The join against our own rows is now read fresh, per user, on every check. A failed call to Bunny returned an empty map before it had looked at a single row, so an account with gigabytes of declared uploads read as empty whenever Bunny was unreachable. Bunny's figure being gone is not a reason to forget the sizes we wrote down ourselves. The rule for which of the two numbers to charge is unchanged, and the comment above it now says why rather than guessing. What Bunny reports mid-encode is partial: storageSize counts what has been written so far and climbs as each rendition lands. A six minute cut uploaded at 2.5 GB read as 475 MB halfway through and settled above 3 GB once it finished, because Bunny keeps the original alongside every rendition. Taking the larger of the declared size and Bunny's is right at every point on that curve; taking Bunny's whenever it is non-zero would hand most of the quota back in the middle of an encode. The settings card also claimed a 200 GB limit while showing a 3 GB one, and told a trial account to delete files or contact support.
48 lines
1.6 KiB
TypeScript
48 lines
1.6 KiB
TypeScript
import { auth } from '@/lib/auth';
|
|
import { apiErrors, successResponse, withCacheControl } from '@/lib/api-response';
|
|
import { getStorageContextForUser, getUserStorageInfo } from '@/lib/storage-quota';
|
|
import { hasBillingAccess } from '@/lib/billing';
|
|
import { db } from '@/lib/db';
|
|
|
|
// GET /api/settings/storage
|
|
export async function GET() {
|
|
const session = await auth();
|
|
if (!session?.user?.id) {
|
|
return apiErrors.unauthorized();
|
|
}
|
|
|
|
// Only users with active billing (or on a self-hosted instance where billing
|
|
// is disabled) should be able to enumerate their storage breakdown.
|
|
const user = await db.user.findUnique({
|
|
where: { id: session.user.id },
|
|
select: {
|
|
subscriptionStatus: true,
|
|
trialEndsAt: true,
|
|
stripeCurrentPeriodEnd: true,
|
|
billingAccessEndedAt: true,
|
|
},
|
|
});
|
|
|
|
if (!user || !hasBillingAccess(user)) {
|
|
return apiErrors.forbidden();
|
|
}
|
|
|
|
const [info, storage] = await Promise.all([
|
|
getUserStorageInfo(session.user.id),
|
|
getStorageContextForUser(session.user.id),
|
|
]);
|
|
|
|
const response = successResponse({
|
|
usedBytes: info.usedBytes.toString(),
|
|
limitBytes: info.limitBytes.toString(),
|
|
percentage: info.percentage,
|
|
// Which ceiling this is, so the card can name it and say what to do about it.
|
|
// A trial has 3 GB because it has not subscribed; deleting files is the wrong
|
|
// advice there, and "200 GB limit" was the wrong caption.
|
|
isPaid: storage.isPaid,
|
|
});
|
|
|
|
// Cache for 60s — stale data is acceptable for a usage meter
|
|
return withCacheControl(response, 'private, max-age=60');
|
|
}
|