clipCount is already existing (minus deleted) + uploads.length, but the per-file guard inside handleFiles tests clipCount + uploads.length >= SOUNDBOARD_MAX_CLIPS, double-counting the staged uploads — so the editor starts refusing uploads well before 40 clips once anything is staged. Worse, clipCount and uploads are captured from the render closure and setUploads inside the loop does not update them, so the guard evaluates the same stale number for every file in the batch: selecting 60 files in one go uploads all 60 to the media repo and stages them past the cap. The file.size check has the same batch behaviour but is per-file so it still works.
How to trigger
with ~35 clips already in a pack, stage a few uploads and try to add one more (false "Soundboard is full"); or select 60 small files at once on an empty pack (no cap applied).
Suggested fix
track the running count in a local variable inside the loop (let count = clipCount; … count += 1) and drop the extra + uploads.length.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** medium · **Type:** bug · **Confidence:** high
**Location:** `src/app/components/soundboard-pack-view/SoundboardPackEditor.tsx:120-121,177-224`
### Problem
`clipCount` is already `existing (minus deleted) + uploads.length`, but the per-file guard inside `handleFiles` tests `clipCount + uploads.length >= SOUNDBOARD_MAX_CLIPS`, double-counting the staged uploads — so the editor starts refusing uploads well before 40 clips once anything is staged. Worse, `clipCount` and `uploads` are captured from the render closure and `setUploads` inside the loop does not update them, so the guard evaluates the same stale number for every file in the batch: selecting 60 files in one go uploads all 60 to the media repo and stages them past the cap. The `file.size` check has the same batch behaviour but is per-file so it still works.
### How to trigger
with ~35 clips already in a pack, stage a few uploads and try to add one more (false "Soundboard is full"); or select 60 small files at once on an empty pack (no cap applied).
### Suggested fix
track the running count in a local variable inside the loop (`let count = clipCount;` … `count += 1`) and drop the extra `+ uploads.length`.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:51:03 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: medium · Type: bug · Confidence: high
Location:
src/app/components/soundboard-pack-view/SoundboardPackEditor.tsx:120-121,177-224Problem
clipCountis alreadyexisting (minus deleted) + uploads.length, but the per-file guard insidehandleFilestestsclipCount + uploads.length >= SOUNDBOARD_MAX_CLIPS, double-counting the staged uploads — so the editor starts refusing uploads well before 40 clips once anything is staged. Worse,clipCountanduploadsare captured from the render closure andsetUploadsinside the loop does not update them, so the guard evaluates the same stale number for every file in the batch: selecting 60 files in one go uploads all 60 to the media repo and stages them past the cap. Thefile.sizecheck has the same batch behaviour but is per-file so it still works.How to trigger
with ~35 clips already in a pack, stage a few uploads and try to add one more (false "Soundboard is full"); or select 60 small files at once on an empty pack (no cap applied).
Suggested fix
track the running count in a local variable inside the loop (
let count = clipCount;…count += 1) and drop the extra+ uploads.length.Filed from the September 2026 client audit (branch
lotus@4bea4895).