trash with more than one id is rejected with a 400; one at a time works

[ergofobe]

imogen trash <id> <id> … is rejected with a 400; the same ids trashed one at a time all
succeed.

$ imogen trash 99588211-… 9f3e624a-… 4784a6ba-… (11 ids)
error: The request did not match what this endpoint expects (400 validation_failed)

$ imogen trash --json 99588211-…
{ "count": 1 }

Eleven separate calls trashed all eleven. Only the multi-id form fails.

Where it is going wrong

AssetSelection in @imogen/shared refuses a body carrying both selectors:

if ((selection.assetIds === undefined) === (selection.query === undefined)) {
  return 'Provide exactly one of assetIds or query'
}

and the comment above it says this is meant to be caught client-side:

a client should learn this before the request leaves, not from a 400: every port checks
the same two rules, and the SDK's own selection helper checks them with this.

So the CLI is sending query alongside assetIds — presumably its filter options
(--type, --album, --favorite, --archived, -Q) building a query object even when
none were given and ids were. That the single-id call succeeds suggests the difference is in
how the argument list is turned into a selection, not in the ids themselves.

Whatever the mechanism, the rule was supposed to be enforced before the request left and was
not — the server's 400 is the first anyone hears of it.

Worth checking while in there

The 400 tells the user nothing. The server returns a details map naming the offending
field, and the message here is the generic envelope sentence — the same gap that made
ergofobe/imogen-android#22 undiagnosable until the client started recording details.
Surfacing it would have made this a ten-second diagnosis instead of a server-log hunt.

Environment

imogen 0.1.2 against imogen-server 0.5.1. Reproduced with 11 valid uuids belonging to
the caller.

Bar

cargo test --locked && cargo fmt --check && cargo clippy --all-targets --locked -- -D warnings && cargo build --release --locked. A test that a multi-id selection serialises to assetIds
only, with no query key, is the one that would have caught this.

[ergofobe]

Triage: the diagnosis in the body does not match any pinned version of the code, and the binary that reported it was not built against a known SDK.

What was checked

• imogen 0.1.2 had no SDK pin. v0.1.2's Cargo.toml resolves imogen-sdk = { path = "../imogen-sdk/rust" } — the unpinned sibling checkout SDK path dependency is an unpinned sibling checkout, so no commit or release records which SDK it was built against #7 closed. Whatever that binary sent on the wire is unrecoverable from this repo.
• Since v0.2.0 (194cbe3, Send filters as AssetSelection queries, chunk id-based bulk calls #6) explicit ids never touch the filter flags. assets::trash returns after AssetSelection::ids(chunk) for each chunk of 500 and only reaches to_filter when ids is empty (src/commands/assets.rs:586-596). One id and eleven ids take the identical path.
• The Rust SDK cannot emit "query": null beside assetIds. AssetSelection carries #[serde(skip_serializing_if = "Option::is_none")] on all three fields, and assets.trash runs selection.validate() — the same two rules as assetSelectionProblem — before the request leaves (imogen-sdk/rust/src/models.rs:440-469, rust/src/assets.rs:175). That was already true at the SDK commit the first pinned CLI used.

So on v0.2.2 the body { "assetIds": [ …11 uuids… ] } is the only thing this command can send, and the server's own AssetSelection schema (z.array(z.uuid()).min(1).max(1000)) accepts it. Nothing found explains a multi-id 400 that a single-id call avoids.

What is confirmed

The second half holds: report() in src/main.rs:58-70 prints only the anyhow chain. The SDK exposes the server's details map through Error::details() (imogen-sdk/rust/src/error.rs:74), and the CLI never reads it — so a validation_failed reaches the terminal as the generic envelope sentence, both in prose and under --json.

Asked

Please re-run the multi-id form on v0.2.2 (imogen --version should say 0.2.2). If it still 400s, the server's details map is what would name the field; it is in the server log, or reachable with curl against POST /api/v1/assets/trash using the same body. If it does not reproduce, the surviving defect is the unread details map, and this issue can be re-scoped to that.

Left untriaged until one or the other is known.

[ergofobe]

Triage, 2026-09-08. Two additions to the comment above.

The stated diagnosis does not hold at 0.1.2 either. v0.1.2 (e35dbe8, 27 Aug 00:45) called ctx.select(ids, query, None) which returns the ids untouched when any are given (src/context.rs:81), and the Rust SDK of that morning (imogen-sdk 854a608, before AssetSelection existed) serialised trash as json!({ "assetIds": asset_ids }) and nothing else (rust/src/assets.rs:176-184). So there is no version of this CLI or its SDK that sends query beside assetIds, one id or eleven. Whatever the server refused, it was not that.

The binary on the reporting machine is still 0.1.2, built 27 Aug 00:59, the day before 194cbe3 (#6) rewrote the selection path and v0.2.0 pinned the SDK. The ask above stands: reinstall, then re-run the multi-id form on imogen --version = 0.2.2.

The confirmed half, the unread details map, is now its own issue: #17. Once that lands a 400 will name the field on its own, which is the fastest way to settle this one. Left untriaged pending the re-run.

[ergofobe]

Revalidated on current CLI

Upgraded loki from imogen 0.1.2 → imogen 0.2.2 and re-ran the multi-id trash case against imogen-server 0.5.1 (https://imogen.ergophobia.org).

$ imogen trash --json <id> <id> <id>
{"count": 3}

Exit 0 — no 400 validation_failed. Immediate restore of the same three ids also returned {"count": 3}; none left in trash afterward.

In the v0.2.2 tree, multi-id trash goes through AssetSelection::ids only (chunks of 500); the filter/query path is separate, so the dual-selector body that triggered the server rule does not appear on this path anymore. Likely fixed in an earlier 0.2.x relative to the 0.1.2 report (v0.2.2 release notes are an SDK pin only).

Fine to close from our side — verified fixed on 0.2.2.

[ergofobe]

Closing as completed: the multi-id form succeeds on imogen 0.2.2 per the comment above, and no pinned version of the code sends the dual-selector body the report diagnosed. The selection rewrite in 194cbe3 (#6, v0.2.0) is the change that separated the id and filter paths. The surviving defect, the unread details map, is tracked in #17.