fixMissingThumbnails assumes every file is a JPEG #17

New Issue

clawbot · 2026-08-09T03:46:29+02:00

clawbot commented

2026-08-09 03:46:29 +02:00

Problem

fixMissingThumbnails (src/thumbnails.ts) calls jpeg.decode on whatever bytes it
downloaded, regardless of the file's actual type. A PNG, HEIC, or video file throws inside the
decoder and is recorded as a failure with an opaque message, so the user is told thumbnail
repair failed without being told the real reason is "this is not a JPEG and quak cannot
generate a thumbnail for it".

Ente libraries contain plenty of non-JPEG files. This is not a correctness bug so much as a
capability gap being reported as an error.

Definition of done

fixMissingThumbnails checks the file type before attempting to decode, and reports
unsupported types with a distinct, self-explanatory reason rather than a decoder stack
trace.
ThumbnailFixResult distinguishes "failed" from "skipped, unsupported type", and the CLI's
--json output reflects that distinction.
The README documents which file types thumbnail repair supports.
Tests cover: a JPEG repaired successfully (unchanged behaviour), a PNG reported as
unsupported rather than failed, and a mixed run reporting both categories.
make check green.

Not a 1.0.0 blocker

Deliberately outside the 1.0.0 milestone — the current behaviour is unhelpful but not
incorrect, and the helper subcommands are explicitly secondary to the backup path.

## Problem `fixMissingThumbnails` (`src/thumbnails.ts`) calls `jpeg.decode` on whatever bytes it downloaded, regardless of the file's actual type. A PNG, HEIC, or video file throws inside the decoder and is recorded as a failure with an opaque message, so the user is told thumbnail repair failed without being told the real reason is "this is not a JPEG and quak cannot generate a thumbnail for it". Ente libraries contain plenty of non-JPEG files. This is not a correctness bug so much as a capability gap being reported as an error. ## Definition of done 1. `fixMissingThumbnails` checks the file type before attempting to decode, and reports unsupported types with a distinct, self-explanatory reason rather than a decoder stack trace. 2. `ThumbnailFixResult` distinguishes "failed" from "skipped, unsupported type", and the CLI's `--json` output reflects that distinction. 3. The README documents which file types thumbnail repair supports. 4. Tests cover: a JPEG repaired successfully (unchanged behaviour), a PNG reported as unsupported rather than failed, and a mixed run reporting both categories. 5. `make check` green. ## Not a 1.0.0 blocker Deliberately outside the `1.0.0` milestone — the current behaviour is unhelpful but not incorrect, and the helper subcommands are explicitly secondary to the backup path.

clawbot self-assigned this 2026-08-09 03:46:29 +02:00

clawbot referenced this issue

2026-08-09 03:47:27 +02:00

Tag v1.0.0 #15

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/quak#17

fixMissingThumbnails assumes every file is a JPEG #17

Problem

Definition of done

Not a 1.0.0 blocker

`fixMissingThumbnails` assumes every file is a JPEG #17