Metadata advertises a "large" thumbnail that 404s when you actually request it

GET /images/{id} is the API's own promise of what's downloadable: it returns a thumbnails dict whose keys become the size= values a client is supposed to pass to GET /images/{id}/thumbnail. Right now, for every single successfully processed image, that promise is broken for one of the three advertised sizes: the URL the API itself hands back either 422s (because the size name isn't one the download endpoint's validator recognizes) or, if a client instead asks for the size name it expects based on the public API contract, 404s (because no file was ever saved under that name). Either way, one third of every gallery/thumbnail grid built against this API silently breaks with a broken-image icon, and it will look for all the world like a client bug rather than a server-side contract violation -- which is exactly the kind of cross-team "it's not on my side" debugging loop that burns a day of two engineers' time before anyone thinks to grep both sides of the API.

app/processing.py's THUMBNAIL_SIZES dict -- which drives what the background pipeline actually generates and saves -- no longer has an entry named "large". app/schemas.py's ThumbnailSize enum -- which is what GET /images/{id}/thumbnail?size=...'s Query(...) parameter validates incoming requests against -- still only knows small, medium, large. The two are supposed to name the exact same three tiers and no longer do.

cd fastapi/image_service && source .venv/bin/activate python3 - <<'PY' from fastapi.testclient import TestClient from app.dependencies import Settings from app.main import create_app import io from PIL import Image

img = Image.new("RGB", (300, 300), (255, 0, 0)) buf = io.BytesIO(); img.save(buf, format="PNG")

settings = Settings(upload_dir="/tmp/t06/u", database_url="sqlite:////tmp/t06/db.sqlite3") client = TestClient(create_app(settings)) image_id = client.post("/images", files={"file": ("a.png", buf.getvalue(), "image/png")}).json()["id"]

meta = client.get(f"/images/{image_id}").json() print("advertised thumbnail keys:", sorted(meta["thumbnails"].keys())) print("GET .../thumbnail?size=large ->", client.get(f"/images/{image_id}/thumbnail", params={"size": "large"}).status_code) PY

-> advertised thumbnail keys: ['medium', 'small', 'xlarge'] ... and ?size=large -> 404 THUMBNAIL_NOT_FOUND

This is a two-file contract, not a single function: nothing in app/main.py needed to change for this to break, because run_thumbnail_pipeline correctly and generically builds record.thumbnails from whatever keys generate_thumbnails() (driven by THUMBNAIL_SIZES) happens to produce. The bug is entirely in the fact that two independently-maintained lists of "the three size names" (one in processing.py, one in schemas.py) drifted apart. Reading either file in isolation looks completely correct -- you only find this by comparing them.

Compare THUMBNAIL_SIZES in app/processing.py against ThumbnailSize in app/schemas.py, name by name. Decide which file has the "wrong" name (one of them doesn't match the other two, and doesn't match the README's own endpoint table either) and fix that side -- not both, and not by adding a fourth name to paper over the mismatch.