b700a4a01825194e1dd147e93501a5035f58884c
CI / test (push) Has been cancelled
After re-cropping an image, the renderer regenerates the .bin and advances the asset's rendered_at, but the device's 304 short-circuit still matched on (image_id, orientation) only — so the device kept serving the old upside-down/stale bytes from its local cache despite the server having freshly-rendered correct ones. Adds device.current_rendered_at, populated whenever a 200 response is served, and tightens the 304 condition to require all three (image id, orientation, rendered_at) to match. The asset lookup now happens before the 304 check so its rendered_at is in scope for the comparison. No firmware change — this is server-side cache logic. Existing devices get null current_rendered_at after the migration; their next poll falls through 304 and re-fetches once, then the cache is in sync. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Description
pictureFrame web app — Symfony + Vue SPA
Languages
Python
42.9%
PHP
20%
HTML
12.5%
TypeScript
11.7%
Vue
7.6%
Other
5.3%