From 6e53ccc7d4fef131f172495ef3cad090ccc89973 Mon Sep 17 00:00:00 2001 From: Todor Kolev Date: Fri, 14 Aug 2026 10:41:37 +0000 Subject: [PATCH] =?UTF-8?q?fix(ci):=20=D1=81=D0=B2=D0=B5=D1=80=D1=8F=D0=B2?= =?UTF-8?q?=D0=B0=D0=B9=20=D0=BF=D1=81=D0=B5=D0=B2=D0=B4=D0=BE=D0=BD=D0=B8?= =?UTF-8?q?=D0=BC=D0=B8=D1=82=D0=B5=20=D0=B2=20=D1=81=D0=BE=D0=BD=D0=B4?= =?UTF-8?q?=D0=B0=D1=82=D0=B0=20=D0=B7=D0=B0=20=D0=BA=D0=BE=D0=BB=D0=BE?= =?UTF-8?q?=D0=BD=D0=B8=D1=82=D0=B5=20=D0=BD=D0=B0=20=D0=B0=D0=BD=D0=B5?= =?UTF-8?q?=D0=BA=D1=81=D0=B8=D1=82=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Стъпката „Apply amendment restated/suspect columns" от #307 падна на първото си истинско пускане и няма как да мине - нито на тази база, нито на никоя. Заявката именува колоните `has_restated` / `has_treatment` / `has_suspect`, а `read_flag` търси реда по низа, с който е извикана `ensure_column`, тоест `value_restated` / `value_treatment` / `value_suspect`. `Object.hasOwn` връща false за всяка от трите, а сондата чете това като нечетим отговор и излиза с 2, което `case`-ът третира като фатално: ##[error]Could not determine whether amendments.value_restated exists. Понеже стъпката стои преди деплоя на Worker-а, деплоят до stage спира на нея - самият сайт не е засегнат, защото нищо не е било разгърнато (стъпки 12-14 са прескочени), но stage остава на изданието отпреди #307. Поправката е псевдонимите да са самите имена на колоните, плюс коментар защо не могат да бъдат описателни. Проверено срещу истинската база: заявката връща {value_restated: 0, value_treatment: 0, value_suspect: 0}, а сондата дава статус 1 (добави) при липсващи и 0 (има ги) при налични - никога 2. --- .github/workflows/deploy.yml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml index 835e208d..2bdfdf2e 100644 --- a/.github/workflows/deploy.yml +++ b/.github/workflows/deploy.yml @@ -226,12 +226,16 @@ jobs: if: steps.guard.outputs.ok == 'true' run: | node scripts/wrangler-render.mjs apps/web/wrangler.jsonc + # Each alias below MUST be the column name itself: read_flag looks the row up by the very string + # ensure_column is called with. An alias that merely describes the column (has_restated) makes + # `Object.hasOwn(row, key)` false for every column, which the probe treats as an unreadable answer + # and turns into a hard failure — so the step could never succeed, on any database. schema_json="$(pnpm --filter @sigma/web exec wrangler d1 execute "${SIGMA_D1_NAME:-sigma}" \ --config wrangler.deploy.jsonc --remote --yes --json \ --command "SELECT - (SELECT COUNT(*) FROM pragma_table_info('amendments') WHERE name = 'value_restated') AS has_restated, - (SELECT COUNT(*) FROM pragma_table_info('amendments') WHERE name = 'value_treatment') AS has_treatment, - (SELECT COUNT(*) FROM pragma_table_info('amendments') WHERE name = 'value_suspect') AS has_suspect")" + (SELECT COUNT(*) FROM pragma_table_info('amendments') WHERE name = 'value_restated') AS value_restated, + (SELECT COUNT(*) FROM pragma_table_info('amendments') WHERE name = 'value_treatment') AS value_treatment, + (SELECT COUNT(*) FROM pragma_table_info('amendments') WHERE name = 'value_suspect') AS value_suspect")" read_flag() { printf '%s' "$schema_json" | node -e '