Centralize request audit recording, preserve immutable download-task history, and derive hourly statistics and backfills from the same authoritative sources. Add durable user registration facts so admin deletion no longer destroys signup history.
* feat(admin): separate billing configuration
Add dedicated storage egress and downloader credit billing contracts, usecases, RPC wrappers, drawers, generated client updates, and coverage.
Agent-Profile: https://agent-kanban.dev/agents/2673e70e0085f4e0
* fix(billing): preserve not found ordering
Check storage and downloader existence before quota_store gating in dedicated billing usecases, and cover enabled missing-resource requests at usecase and route levels.
Agent-Profile: https://agent-kanban.dev/agents/2673e70e0085f4e0
---------
Co-authored-by: Jordan Park <jordan-park@mails.agent-kanban.dev>
* feat: make forcePathStyle configurable per storage
Previously hardcoded to true, which breaks S3-compatible backends that require
virtual-hosted-style addressing (e.g. Alibaba Cloud OSS). Now configurable via
admin storage settings with a toggle switch, defaulting to true for backwards
compatibility.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
* test: cover storage force path style
---------
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: saltbo <saltbo@foxmail.com>
* feat(avatars): host avatars + team logos on Cloud via SDK 2.4.0; remove public-bucket mode
Host user avatars and org logos on the ZPan Cloud avatar service
(zpan-cloud-sdk ^2.4.0) instead of a public S3/R2 bucket, then remove the
now-dead storages.mode / public-bucket concept entirely (#456 parts 2-3).
- image-upload gateway: upload/delete via SDK uploadAvatar/deleteAvatar against
a bound Cloud client; validate mime (AVATAR_CONTENT_TYPES) + size
(MAX_AVATAR_BYTES) before the call; map cloud error codes to 400/403/413/500;
unbound instance returns 503 cloud_required (delete is a best-effort no-op).
- licensing-cloud: createAvatarUploadClient builds the client with a plain-object
bearer header so both the image content-type and Authorization survive hono's
per-request header merge (a Headers instance would be dropped).
- drop storages.mode (migration via drizzle-kit), StorageRepo.select() no longer
takes a mode, remove StorageMode / Storage.mode / mode schema+audit+UI+i18n and
the PUBLIC_IMAGES bucket + PUBLIC_IMAGES_URL wiring.
Agent-Profile: https://agent-kanban.dev/agents/f759c704c282d88a
* ci(deploy): drop dead PUBLIC_IMAGES R2 provisioning from CF deploy
The Cloud avatar migration removed the PUBLIC_IMAGES binding from
wrangler.toml, so the deploy workflow's R2 public-images steps are dead and
must go too — otherwise every CF deploy keeps re-provisioning a public-read
zpan-public-images bucket (the footgun #456 eliminates) and sets an unused
PUBLIC_IMAGES_URL secret. Removes the bucket-create, managed-public-URL, and
secret steps (steps.r2 was only consumed by the secret step). Also drops a
stale storage-modes line from the v2.0 roadmap.
Agent-Profile: https://agent-kanban.dev/agents/f759c704c282d88a
---------
Co-authored-by: Alex Chen <alex-chen@mails.agent-kanban.dev>
Final piece of the restart→download→upload→seed robustness pass. nextTaskWorkStage
can route a task to uploadExistingResult based on the server checkpoint (upload
progress / runtime phase / download totals), but the engine may not report the
download complete yet — aria2 re-checks on-disk files after a restart (showing
downloaded=0/total=nil transiently), or the download was lost. The old code
panic()'d on that mismatch, which recoverTaskPanic turned into a permanently
failed task (this is what failed Moonfall after it had fully downloaded 7.4GB).
Now uploadExistingResult falls back to downloadThenUpload when the runtime isn't
complete (or has no result). downloadThenUpload re-attaches to the session
download, waits for aria2 to finish re-checking, and uploads on completion — no
data loss, no spurious failure. Test updated to assert resume-not-fail.
isAria2RPCDisconnected called err.Error() unconditionally, so a nil error
panicked (nil pointer deref). findSeed reaches it with a nil error whenever
tellStatus succeeds but the status isn't a seed — which crashed the downloader at
startup while restoring a retained seed from the ledger. Guard nil -> false.
Second restart bug behind the same stuck Moonfall: aria2 auto-seeds a torrent
the instant its download finishes (--seed-time), so a completed-but-not-yet-
uploaded download shows up in ListSeeds. reconcileEngineSeeds runs at startup
BEFORE the task loop marks tasks running, so 'running' was empty and it adopted
that seed as a done seed for managed expiry — skipping the upload entirely. The
task then sat at 'downloading' forever and the file would be deleted when the
seed expired.
Skip seeds whose task is still assigned/unfinished (AssignedTasks: assigned/
downloading/interrupted/uploading) — those belong to the task loop, which will
upload then seed them. Only genuinely orphaned seeds (completed tasks) are
adopted. Confirmed on prod: Moonfall finished (7.4GB on disk) with
result_object_id=null, stuck downloading.
After a downloader restart, the web UI showed a frozen download with 0 speed
even though aria2 was still downloading. Cause: on restart a task comes back as
'interrupted', but shouldAttachExistingAria2Task only attached for
downloading/uploading — so the worker RE-ADDED the magnet. aria2 had already
reloaded that download from its saved session, so the re-add hit error 12
(infohash already registered) and produced a dead duplicate gid. The worker then
polled the dead duplicate (bytes=0, speed=0) instead of the live download;
mergeTaskProgress's max() kept the stale byte count, so the UI froze. The real
download kept going, orphaned and unreported.
Fixes:
- shouldAttachExistingAria2Task also returns true for 'interrupted', so restart
attaches to the session-restored download instead of re-adding.
- findTask skips error/removed entries so it never attaches to a dead duplicate.
Confirmed on prod: Moonfall had two aria2 gids — 29ded179 (live, 6.8GB) and
3203aca6 (error-12 duplicate) — and the server runtime was frozen at the
pre-restart snapshot.
Several magnet tasks sat at 0 bytes / 0 connections forever: their embedded
trackers were dead (coppersurfer.tk, leechers-paradise, etc.) and aria2 had no
other way to find peers, so metadata never downloaded — while still holding a
download slot and blocking the queue.
aria2 startArgs set no BT discovery config at all. Add:
- --bt-tracker fed from the maintained XIU2 TrackersListCollection 'best' list,
fetched live at startup (FetchBtTrackers) with a bundled snapshot fallback, to
supplement each magnet's own (often rotted) announce list,
- explicit --enable-dht / --enable-peer-exchange,
- --dht-file-path in the state dir so the DHT routing table is warm across
restarts instead of bootstrapping cold,
- --bt-load-saved-metadata to reuse fetched metadata.
On restart aria2 reloads the saved session and re-announces these magnets with
the live trackers, so the stuck ones can finally resolve.
Two follow-ups:
- aria2 peers now report progress (0..1) derived from the peer's piece bitfield
(seeder => 1.0), matching qBittorrent. Previously the Peers list showed '—'
for aria2 because the field was never populated.
- The server builder copied the whole repo via 'COPY . .', so a cmd/-only
(downloader) change busted the layer and forced a full vite/tsup rebuild. Copy
only the build inputs + final-stage sources (src, server, shared, public,
index.html, vite.config.ts, tsconfig.json, migrations, scripts) so
downloader-only pushes reuse the cached server image. Verified the builder
stage still builds and produces dist/dist-server/migrations/entrypoint.
aria2's tellStatus only returns the keys it's asked for, but aria2StatusKeys
omitted uploadLength, uploadSpeed, connections and numSeeders — while
aria2Detail reads status.UploadLength/UploadSpeed/Connections/NumSeeders. So the
runtime reported them all as 0: during seeding the Overview showed 0 B/s upload
and 0 B uploaded, even though the Peers list had per-peer upload activity (that
comes from a separate getPeers call). Confirmed on live aria2: the seeding
torrent reported uploadSpeed ~3.26MB/s and uploadLength ~2.5GB when those keys
were requested. Adds the missing keys + a guard test.
Billing was charge-in-arrears: a credit unit was only charged once the
downloader had already reported downloading into it, and the first unit only
after the first progress report — so a no-credit task still pulled bytes before
being blocked, then suspended with no explanation.
- Pre-authorize one unit ahead of the bytes pulled: targetUnits =
min(ceil(downloaded/unit) + 1, ceil(total/unit)). The downloader never fetches
bytes it hasn't paid for, and the cap keeps the lifetime charge at exactly
ceil(total/unit) — same total as before, only billed earlier.
- Charge the first unit on the transition into 'downloading' (zero bytes), so a
task that can't afford a unit is suspended at the gate and pulls nothing. The
worker reads the authoritative status from that transition response and does
not start downloading when it comes back suspended (progress reports stay pure
telemetry; control still flows through the poll).
- On suspend, set runtime.message so the UI shows why (insufficient credits).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Branding's logo/favicon are now encoded as `data:${mime};base64,…` URIs and
stored directly in the `branding_logo_url` / `branding_favicon_url` system
options instead of being uploaded to a `mode='public'` S3 bucket. This removes
branding's dependency on public storage entirely (#456 Part 1).
- uploadBrandingImage encodes the raw file bytes and drops select('public') /
s3.putObject / s3.getPublicUrl; s3 + storages removed from BrandingDeps.
- Per-field raw-byte caps replace the single 2 MiB limit: logo ≤ 256 KB,
favicon ≤ 64 KB; over-cap returns 413 naming the field's limit.
- The 503 "no public storage" path is gone: uploads succeed with no public
storage configured, and the updateBranding route no longer advertises 503
(operationId unchanged; Go OpenAPI client regenerated).
- GET shape unchanged; legacy absolute-URL values keep rendering as-is (no
migration, no backfill, old _system/branding objects untouched).
Out of scope (#456 Parts 2-3): avatar/team-logo upload, storages.mode,
StorageRepo.select.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The progress-report path was making control decisions by string-matching error
bodies — and missed the suspended case entirely, so a billing-suspended task
kept downloading while the UI showed Suspended.
Reporting is now pure telemetry: updateTask just syncs progress/status and a
failed report is logged, never acted on. All stop-control (pause/cancel/suspend)
flows through the existing task poll:
- AssignedControlTasks now also queries 'suspended'; cancelRunning cancels the
running download with errTaskSuspended and leaves the server-owned suspended
status untouched.
- Removed errBillingPaused, the insufficient_credits string-match, and the
isControlledTaskUpdateError/resolveControlledTaskUpdate error-string matching.
pause/cancel already flowed through the poll; the report-path handling was a
redundant, brittle second mechanism.
Worker-only; no server change (status=suspended is already pollable and keeps
assignedDownloaderId). Tests cover the suspended poll cause and the control
status query.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When a retained seed was cleaned up (expiry/ratio/cache/missing), the worker
removed it from aria2, the ledger, and local disk — but never told the server
seeding had ended. The task's last runtime report (phase=seeding,
Seeding.Active=true) stuck, so the dashboard showed completed tasks as
seeding forever. reportRetainedSeedsStopped only ran on worker shutdown, not
on per-seed expiry.
- cleanupRetainedSeed now reports the task runtime as completed/not-seeding
after a seed is cleaned, so the UI clears it. Task status stays completed.
- clearStaleSeedingReports runs once at startup: lists this downloader's
completed tasks the server still marks seeding (new client SeedingTasks),
and reports stopped for any the worker is no longer actually seeding (after
reconciliation), clearing entries left stale by older builds.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two coupled bugs starved aria2 downloads on long-running nodes.
Concurrency: max_concurrent_tasks is the download budget only, but aria2
counts seeding torrents as active downloads, so retained seeds were eating
the shared --max-concurrent-downloads (default 5) and new downloads queued
forever in 'waiting' with no error. Seeding now gets its own budget via a new
Downloader-local config downloader.seed.max_concurrent (default 10); aria2's
--max-concurrent-downloads is set to max_concurrent_tasks + that budget, so
seeds can never consume a download slot. The worker still caps real download
concurrency itself.
Orphan seeds: aria2 was told SeedTime=1000000 (~694 days), so it never
stopped seeding on its own; the worker was the sole authority, and any drift
between aria2's session and the worker's ledger (e.g. across restarts) left
torrents seeding forever, holding slots and disk, never expired. Two fixes:
- aria2 SeedTime is now the configured seed_duration (+ seed-ratio), so aria2
stops seeding on its own even if the worker loses track.
- The worker reconciles on startup and periodically: any torrent the engine
is still seeding but the worker no longer tracks is adopted into the ledger
with an expiry (skipping in-flight/already-tracked tasks), so normal
time/ratio/cache cleanup applies instead of leaking.
Adds SeedLister + aria2 ListSeeds. Tests cover the new config, aria2 args,
seed-time mapping, and orphan adoption (skipping running/tracked tasks).
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three related changes hardening the remote downloader, bundled because the
module-path rename touches every file — splitting would leave a mid-history
commit that doesn't build.
Engine supervision: a managed engine subprocess (aria2c / qbittorrent-nox)
that exits unexpectedly now crashes the worker. watchEngineProcess waits on
the child, logs the exit at error level, and cancels the run context so
`downloader up` returns non-zero; the container (restart: unless-stopped)
then restarts the whole stack. Previously the exit error was discarded and
the worker kept heartbeating as healthy while every task failed against the
dead RPC. A deliberate shutdown kill is told apart from a crash via a
stopping flag.
aria2 GID recovery: waitAria2 re-discovers the live GID via findTask when
aria2 reports 'GID ... is not found' mid-download (e.g. after an aria2
restart) instead of failing the task. Adds isAria2GIDNotFound, which matches
tellStatus's message format that isAria2DownloadNotFound missed.
CLI install: move the entrypoint to the module root (cmd/main.go) and rename
the module github.com/saltbo/zpan/cmd -> github.com/saltbo/zpan so
`go install .` from cmd/ yields a zpan binary. Internal imports shorten to
github.com/saltbo/zpan/internal/...; the Dockerfile builds the module root.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Every endpoint now exposes one monomorphic schema: role/state changes field
values (mask / null / filter), never the shape.
image-hosting/config: drop the `full config | { enabled: false }` union. GET
always returns the full ImageHostingConfig shape carrying `enabled`; not-configured
→ `enabled: false` with every other field null (`createdAt` is now nullable).
`buildResponse` is made total over `row | null` so it is the single producer of
the shape, and `getIhostConfig` no longer returns `| null`.
auth-providers: collapse the admin-config vs public-display union into one
AuthProvider schema (providerId, type, enabled, name, icon, clientId, discoveryUrl,
scopes, clientSecret). Same endpoint, no path split — role changes one value:
admin gets a masked clientSecret, front-of-house gets `clientSecret: null` and the
enabled-only list. The two list usecases collapse into listAuthProviders(deps,
{ isAdmin }); the PUT response and the merged frontend wrapper adopt the same
schema, deleting AuthProviderConfig/PublicAuthProvider entirely.
Regenerated the Go client (union types removed) and updated frontend types/consumers.
Closes#449.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Resolve#448 — one upload entry point and an AIP-164 soft delete.
Upload: POST /objects now returns size-decided upload instructions
{ sessionId, partSize, urls }; the server picks single PutObject (<=5 GiB)
vs 5 GiB-part multipart (>5 GiB) and rejects >5 TiB. The client PUTs each
slice, reads its ETag, then POSTs them to
POST /objects/{id}/uploads/{sid}/completions (returns the live object).
DELETE /objects/{id}/uploads/{sid} aborts and discards the draft.
Trash: matters.status drops 'trashed' (enum is {draft,active}); trash is
tracked by the existing trashedAt timestamp. DELETE /objects/{id} now
soft-deletes; the recycle bin lives under /trash/objects (list roots, get,
restorations, purge). Empty-trash is a frontend loop over roots.
BREAKING CHANGE:
- removes PUT /objects/{id}/status and POST /objects/{id}/uploads
- PUT .../uploads/{sid}/status -> POST .../uploads/{sid}/completions {parts}
- DELETE /objects/{id} flips hard-purge -> soft-delete; permanent purge
moves to DELETE /trash/objects/{id}
- DELETE /trash removed; restore is POST /trash/objects/{id}/restorations
- matters.status enum loses 'trashed' (migration backfills to trashedAt)
The migration swaps the matters_active_name_uniq partial index to exclude
trashed rows (WHERE status='active' AND trashed_at IS NULL). The single-PUT
presign is header-free so the uniform slice uploader's raw PUT matches the
S3 signature. Go downloader client + agent reworked to the unified flow.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* refactor(api)!: unify revoke/cancel on PUT /{resource}/{id}/status (#452)
Retire the misleading DELETE /shares/{token} and PATCH /store/orders/{orderId}
shapes in favor of the existing status-subresource convention already used by
background-jobs and download-tasks.
- Shares: PUT /api/shares/{token}/status {status:'revoked'} -> 200 + the updated
creator ShareView. revokeShare now resolves the share before the UPDATE (the
record is unresolvable once revoked) and builds the view via a composeShareView
helper shared with viewShare; concurrently-revoked tokens now return 404.
Removed the now-dead getCreatorByToken repo port/adapter method.
- Store: PUT /api/store/orders/{orderId}/status {status:'canceled'} -> 200. Only
the local route shape changed; the upstream cloud SDK $patch call is untouched.
- Frontend: deleteShare -> revokeShare and cancelCloudOrder now use .status.$put
via the Hono RPC client; updated the shares route component.
- Regenerated the Go OpenAPI client.
Note: revoking a share whose matter is trashed-but-not-purged now returns 404
(was 204), a consequence of reusing viewShare's resolution path.
Agent-Profile: https://agent-kanban.dev/agents/f759c704c282d88a
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test(spec): rename share delete scenarios to revoke status-subresource
Align spec/shares.feature scenario tags (@shares/revoke,
@shares/revoke-non-creator) with the renamed [spec:] breadcrumbs so
lint:spec traceability passes.
Agent-Profile: https://agent-kanban.dev/agents/f759c704c282d88a
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(shares): keep revoke working for a trashed-but-not-purged matter
revokeShare switched to resolveByToken, which returned matter_trashed for a
soft-deleted (not purged) matter and was short-circuited to 404. Because
trashing a matter does not cascade to its shares, the share stayed active and
still appeared in the owner's list — so the owner could no longer revoke it
(privacy footgun: restoring the file re-exposed a share they believed revoked).
ShareResolution now carries the share/matter/recipient records on the
matter_trashed variant (and splits not_found/revoked into single-literal members
so control-flow narrowing works). Viewer-facing callers still branch on status,
so trashed -> 410 for viewers is unchanged. revokeShare treats matter_trashed as
revocable (ownership check, revokeByToken, revoked creator view), while not_found
and already-revoked still map to 404.
Adds unit coverage (trashed-matter revoke succeeds; non-creator still 403) and a
backend integration test (share a landing matter, trash it, PUT status revoked ->
200 + status:'revoked', DB flips).
Agent-Profile: https://agent-kanban.dev/agents/f759c704c282d88a
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* refactor(api)!: DELETE endpoints return 204 No Content (#443)
Resolves item #4 of #443 — DELETE return-shape inconsistency (8 different
conventions). Standardize every DELETE on 204 No Content with an empty body,
dropping the ack/result bodies: `{id,deleted}`, `{providerId,deleted}`,
`{key,deleted}`, `{id,revoked}`, `{ok:true}`, the download-task tombstone,
license `{deleted,cloud_unbind_error}`, and the entitlement-revoke /
abort-upload-session objects.
Kept (the issue's flagged special case): object-delete and empty-trash still
carry a purge count — the only delete responses with information a caller can't
otherwise derive. Object delete is trimmed from `{id,deleted,purged}` to just
`{ purged: number | false }`; empty-trash keeps `{ purged: number }`.
Backend: 15 DELETE routes → `204: { description }` + `c.body(null, 204)`;
removed the now-dead `deleteDownloaderResponseSchema`.
Frontend: added a `discard()` helper (the 204 counterpart to `unwrap()`); the
unwrap-based delete wrappers now resolve `void`. cancelUpload/deleteObject now
return `{ purged }`. The already-void wrappers (deleteShare, deleteAvatar, …)
were untouched — they never read the body.
OpenAPI document + Go client regenerated (go build clean).
BREAKING CHANGE: all DELETE endpoints now respond 204 with no body. License
unbind no longer returns `cloud_unbind_error`, so a partial cloud-unbind failure
is no longer surfaced in the response body.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(licensing): surface cloud-unbind failure as 502, don't swallow it as 204
The DELETE→204 sweep turned license unbind into an unconditional 204, which
hid a real partial failure: when the best-effort cloud unbind throws, the local
binding is cleared but the cloud side is left dangling. Reporting 204 (success)
in that case swallows the error.
`unbindLicense` now returns a Result — `{ ok: true }` only when the cloud unbind
also succeeds, and a 502 AppError (reason `CLOUD_UNBIND_FAILED`, the cloud error
in `details.metadata`) when it fails. The local binding is still cleared either
way; the handler returns 204 on ok and throws the error otherwise.
DELETE success is still an empty 204 — this only restores fail-fast on the one
endpoint whose failure was a soft body field, never a thrown error.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test(spec): reconcile users.feature with #446 better-auth migration
`pnpm lint:spec` (a CI gate) was red on 11 orphaned `spec/users.feature`
scenarios — leftover from #446, which moved admin user management off our
`/api/users/*` routes onto better-auth's admin plugin and deleted the old
endpoints/tests but not their spec scenarios. Pre-existing on main; surfaced
here as the only failing CI check.
Reconcile the spec with reality:
- Re-link the behaviors that survived (now via better-auth) to the tests that
already cover them: list / admin-only(403) / disable(ban) / delete(remove) /
patch-missing(act-on-missing→404) → admin-users-ba.integration.test.ts;
quota-personal-org → the per-user quota test in users.integration.test.ts.
- Drop scenarios for behavior that no longer exists: batch-toggle (now a
client-side fan-out, no endpoint), invalid-status (ban/unban are explicit),
multi-field filter (better-auth search is single-field, untested), the
unauthenticated 401 guard (better-auth owns it), and the inline
quota-entitlements-in-list (quota is now a per-user sub-resource).
lint:spec: 413 scenarios, all covered.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collapse the two error conventions (string-reason `{ok:false,reason}` outcomes
and thrown domain-error classes) onto one. Usecases now produce typed `AppError`
values via factories (`notFound()`/`quotaExceeded()`/`featureBlocked()`/…);
handlers `throw result.error`; and `jsonError` (renamed from `renderError`) is the
single place that renders any error to an AIP-193 body + access-log line, in
`app.onError`/accessLog.
Why: the previous setup had a string→code mapping (`outcomeError` + the `OUTCOME`
table) living in parallel with a type→code mapping (`mapDomainError`), plus inline
`apiError(c, <status>, …)` calls that hand-wrote the status at every site — exactly
the drift that left the same `quota_exceeded` at 400 in one handler and 422 in the
rest. Now the status/reason live once, in the factory.
- Add `server/usecases/ports/app-error.ts`: `AppError` + factories. Status/reason
are baked in per factory, so no usecase or handler writes an HTTP code or a
magic-string reason. `AppError` also carries optional response headers
(`Retry-After`) via a `rateLimited()` factory.
- Delete `apiError`, `outcomeError`, the `OUTCOME` table, and the dead `ApiError`
class. The 67 inline guard/middleware `apiError` sites became `throw <factory>()`.
- Control-flow outcomes a handler branches on (not just renders) stay discriminated
reasons (e.g. `deleteObject` `not_trashed`); internal shared sub-usecases
(traffic-metering, licensing internals) keep string reasons, mapped at the boundary.
- Regenerate the Go OpenAPI client (saveShare gained a 422 response).
BREAKING CHANGE: POST /shares/{token}/objects quota rejection now returns 422
(was an inconsistent 400); every other quota path already returned 422.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* refactor(api)!: unify errors to AIP-193 + Page<T> pagination, enrich access log (#443)
Settle the API consistency issues from #443 before SDKs ship. Breaking changes
across the error envelope, list envelopes, and the generated Go client.
Errors → AIP-193 google.rpc.Status (https://google.aip.dev/193):
- every error body is now { error: { code, message, status, details:[ErrorInfo] } }
- machine-readable, switchable key is details[0].reason (UPPER_SNAKE); status is the
canonical google.rpc.Code; dynamic context lives in metadata (string→string)
- built once in server/lib/http-errors.ts (buildErrorBody/ApiError/mapDomainError);
inline handlers use apiError(c,status,msg,opts?); thrown errors flow through
app.onError → renderError. Resolves#8 (one casing; no-storage 503 everywhere) and
#9 (resource/maxBytes/conflictingName/licensing fields folded into metadata;
featureGateErrorSchema removed)
Pagination → Page<T> = { items, total, page, pageSize } via pageSchema + integer
pageQuerySchema, applied to every list endpoint. image-hosting/images stays cursor
(the one intentional exception). unreadCount moved out of the notifications list into
/notifications/stats; entitlements drop the redundant orgId; team invitations use items.
Access log: every 4xx/5xx carries reason + full message (set by apiError and
renderError); a thrown domain error logs its mapped status (409, not 500); unhandled
500s log the full cause chain while the client gets a generic message.
Frontend ApiError exposes reason/metadata/canonicalStatus; consumers updated. Go
client regenerated from the new OpenAPI document.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test(api): fix e2e name-conflict assertion + cover AIP-193 error branches
- e2e/name-conflict.spec.ts: assert body.error.details[0].reason (AIP-193) instead
of the removed top-level body.code
- unit-test buildErrorBody, ApiError, and every mapDomainError branch
(server/lib/http-errors.test.ts) and renderError + isHandledError
(server/middleware/error-handler.test.ts)
- integration-test the apiError error-branch guards the refactor touched:
shares, redirect, site/invitations, objects, store/storefront, and the
requirePermission middleware (authz) — restoring patch coverage above target
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test(api): drop ad-hoc [spec:] breadcrumbs from new coverage tests
lint:spec governs spec↔test traceability: a [spec: id] breadcrumb must map to a
documented @id scenario in spec/**/*.feature. The added error-branch coverage
tests are not Gherkin scenarios, so reference no spec id — use plain titles.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(objects): allow the file-manager pageSize (500) on the objects list
The shared pageQuerySchema caps pageSize at 100, but the file manager loads a
whole folder client-side (FILES_PAGE_SIZE=500, transfer dialog 200) — the old
z.string() query param was unbounded. With the cap, GET /api/objects?pageSize=500
returned 400, the file-manager list query errored and retried, and the toolbar /
table never rendered (e2e: responsive @desktop + name-conflict table state). Raise
just this list's ceiling to 1000 (default stays 20); other lists keep the 100 cap.
Regression-tested: GET /api/objects?pageSize=500 → 200.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
saltbo