football2801
b700a4a018
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>
28 lines
765 B
PHP
28 lines
765 B
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace DoctrineMigrations;
|
|
|
|
use Doctrine\DBAL\Schema\Schema;
|
|
use Doctrine\Migrations\AbstractMigration;
|
|
|
|
final class Version20260507230000 extends AbstractMigration
|
|
{
|
|
public function getDescription(): string
|
|
{
|
|
return 'Add device.current_rendered_at so 304 cache check can detect re-renders';
|
|
}
|
|
|
|
public function up(Schema $schema): void
|
|
{
|
|
$this->addSql('ALTER TABLE device ADD current_rendered_at TIMESTAMP(0) WITHOUT TIME ZONE DEFAULT NULL');
|
|
$this->addSql("COMMENT ON COLUMN device.current_rendered_at IS '(DC2Type:datetime_immutable)'");
|
|
}
|
|
|
|
public function down(Schema $schema): void
|
|
{
|
|
$this->addSql('ALTER TABLE device DROP COLUMN current_rendered_at');
|
|
}
|
|
}
|