Active scan + image traffic was going to bloat Storage fast — every
delivered case has tens of MB of STL hanging around forever. Now closing
a case via 'Teslim Aldım' fires a background archive sweep that deletes
the binary from the bucket but keeps the job_files row, so audit
('kim, ne, ne zaman yükledi') is preserved.
- DB: job_files.archivedAt datetime (nullable).
- archiveJobFiles(jobId) (lib/appwrite/job-file-archive.ts):
lists rows, storage.deleteFile each, stamps archivedAt on the row.
All in try/catch so partial Storage failures don't roll back the
'delivered' transition.
- markDeliveredAction fires it as 'void archiveJobFiles(jobId)' — same
fire-and-forget pattern as audit/notifications/finance sync.
UI / API
- Job detail file row dims to 60% opacity, shows 'Arşivlendi
{tarih}' inline, and disables both the download dialog trigger and
the STL viewer button.
- /api/jobs/[jobId]/files/[fileId]/download returns 410 Gone with a
Turkish message when archivedAt is set — direct-URL hot links can't
fish the file back either.
Clinics upload intraoral scans as raw STL/PLY/OBJ and labs need to see
what was captured before accepting the case. Built a tooth-level 3D
preview that runs entirely in the browser — no server-side rendering,
no extra service, just three.js + react-three-fiber driven off the
existing download proxy.
Component (src/components/stl-viewer.tsx)
- Detects format from the filename (.stl / .ply / .obj).
- fetch() → ArrayBuffer → STLLoader / PLYLoader / OBJLoader.parse.
- OBJ comes back as a Group; merge the child meshes into a single
BufferGeometry (positions concat) so all three formats render
through the same mesh path.
- Scene: dark background, ambient + two directional lights, a
light-grey standard material, drei <Bounds> for auto-fit framing,
OrbitControls with damping. A 'Sığdır' button in the corner re-fits
the camera by remounting Bounds.
- Cleanup: geometry.dispose() on unmount, fetch cancellation guard,
inline error/loading states.
Wiring (job-files-panel.tsx)
- VIEWABLE_RE = /\.(stl|ply|obj)$/i. Only those rows get the new
eye-icon button.
- STLViewer is loaded via next/dynamic with ssr:false so three.js
(~500KB minified) only enters the bundle when the dialog actually
opens. Mounting is also gated on viewerOpen, so closing the dialog
frees the WebGL context.
- Dialog is a tall (85vh) wide (max-w-5xl) shell with the filename
+ size in the header and the canvas filling the rest.
Deps added: three, @react-three/fiber, @react-three/drei (+ types).
Lab side reported that after accepting a job / advancing a step the
button kept its 'Yükleniyor' state and the page didn't reflect the new
status until they hit refresh. Two issues stacked on top of each other:
1. The button forms were passing the action through an extra
startTransition wrap — 'action={(fd) => startTransition(() => action(fd))}'.
With React 19 + useActionState this is unnecessary; useActionState
already manages its own transition. The double transition can leave
the dispatch's pending flag wedged in some race orderings, which
matches what the user saw.
2. revalidatePath() on the server invalidates the RSC cache but does not
trigger client navigation. So even after the action returned, the
page kept rendering the stale Job snapshot — and since the buttons
are conditional on job.status, the now-stale 'pending' status meant
the button stayed visible.
Fix in JobActionsPanel and the four sibling components (connections
delete row, pending inbound, pending outbound, file row delete):
- Removed the startTransition wrap; forms point at 'action' directly.
- Added useRouter() and call router.refresh() in the same useEffect
branch where the success toast fires. This forces the Server
Component tree to re-fetch, picks up the new job.status, and the
actions panel rerenders into whatever button is next in the flow.
- Cleaned the now-unused useTransition imports.
Net effect: tap 'İşleme Al' → spinner appears, ~400ms later the toast
hits and the row updates in place to 'Sonraki Aşama' without any
manual refresh.
Files were grabbed via a plain anchor with the 'download' attribute, so
clicking the icon just spawned a silent browser download — nothing in
the UI moved, and users (especially labs receiving scans) couldn't tell
whether the click registered.
Wrapped the download button in a confirm dialog that mirrors the existing
delete flow: title 'Dosya indirilsin mi?', filename + size in the body,
Vazgeç / İndir buttons. The 'İndir' button programmatically clicks a
hidden anchor pointing at the /api/.../download proxy and surfaces a
'İndirme başladı.' toast with the filename so there's a clear visual ack
even before the OS download tray pops.
XHR's upload.progress event only tracks browser→server byte transfer. It
fires 100% the moment the multipart body has been pushed, but at that
point our route handler hasn't even started streaming the files into
Appwrite Storage yet. A 200MB upload completes the network phase fast,
then sits 30-60 seconds while the server does sequential storage.createFile
+ tablesDB.createRow per file. The UI was stuck on '100%' the whole time,
making it look frozen.
Switched the form to a discriminated phase state:
idle → uploading (real bytes %) → processing (full bar + spinner)
→ idle (success/fail)
Listening on xhr.upload's own load event flips us to 'processing' the
instant the body is done. The outer xhr.load fires when the route handler
responds with JSON — that's when we toast + router.refresh().
User now sees: bar fills, then 'Sunucu Appwrite'a yazıyor — büyük dosyalar
30-60 sn sürebilir' message until the response comes back. No more
mystery wait.
Cluster: Appwrite container _APP_STORAGE_LIMIT 30000000 → 209715200
(200MB) in /root/services/appwrite/.env on kovaksoft-coolify, then
docker compose up -d to roll the worker pool with the new value.
Backup of the .env left at .env.bak.<date>.
Bucket: job-files maximumFileSize updated to 209715200 via Appwrite MCP
(storage_update_bucket).
App: MAX_FILE_BYTES in both the upload API route and the original server
action raised to 200MB. Client-side panel guard relaxed accordingly —
one large file is now allowed to fill the entire batch (the 200MB
proxy/serverActions cap is the bottleneck, not the per-file rule).
Error copy updated.
isletmem and any other tenants on the cluster also get the new limit,
which is the desired behaviour — old 30MB ceiling was a relic of an
Appwrite default that no DLS workflow can actually live with.
- next.config: serverActions.bodySizeLimit + experimental.proxyClientMaxBodySize
bumped from 500mb back down to 200mb. Batch ceiling (client side) is 180mb
to stay comfortably under the proxy cap.
- New POST /api/jobs/[jobId]/files endpoint replaces the server action for
upload. Same auth/permissions/rollback semantics, but Returns JSON so the
client can read the response. Server action is retained for delete only.
- JobFilesPanel switched from useActionState to XMLHttpRequest.upload —
xhr.upload.onprogress feeds a Progress bar (real bytes, not a fake
ticker). Cancel button aborts the in-flight request. Successful upload
triggers router.refresh() to repopulate the file list.
Server actions can't expose upload progress (no streaming feedback in the
RSC protocol yet), so any progress UX needs to go through fetch/XHR
against a route handler. Trade-off accepted.
The previous attempt put 'middlewareClientMaxBodySize' at the top level of
NextConfig — Next 16.1 rejected it as an unrecognised key. Inspecting the
shipped config schema (node_modules/next/dist/server/config-schema.js)
revealed the option lives under experimental and was renamed to
'proxyClientMaxBodySize' when middleware.ts → proxy.ts; the old name is
still accepted but deprecated. Switched to the new name and confirmed Next
now lists it in the Experiments banner at boot.
While we were at it the cap was bumped to 500MB (was 100MB) so batch
uploads have headroom over the 30MB-per-file bucket limit. Added a
client-side pre-flight in JobFilesPanel: rejects individual files >30MB
and total batches >400MB *before* hitting the server, with inline error
messaging instead of a cryptic 'Unexpected end of form' bounce.
Also raised serverActions.bodySizeLimit to 500mb to match.
kovakmedya