From d70442e26fe888146db1bbddde4afcb673e7c1fa Mon Sep 17 00:00:00 2001 From: Claude VM Date: Sat, 23 May 2026 18:15:27 +0300 Subject: [PATCH] =?UTF-8?q?fix(cf):=20bump=20modal=20poll=2090=E2=86=92180?= =?UTF-8?q?s=20+=20pin=20CF=20list=20to=20/api/ancpi=20pre-Faza=20H?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three independent issues from the live test on 50198: 1. CfOrderModal poll timeout was 90s but ANCPI orders routinely take 60-180s end-to-end. The 50198 order completed at 129s (logs show 6 polls before docs matched), but the modal had already errored out 39s before that with "Procesarea durează mai mult decât ne-am așteptat". Bump to 180s + update the user-facing copy from "60 de secunde" to "3 minute" so the expectation matches reality. 2. cfApiBase(useGisAc=true) routed pilot users to /api/cf which proxies to gis-api → gis_core."CfExtract", but the ePay queue still writes ONLY to architools_postgres."CfExtract". Pilot users were therefore blind to their own fresh orders in the listing + catalog checks (50198 invisible despite being completed + downloadable). Pin all CF API calls to legacy /api/ancpi until Faza H mirrors writes to gis-api too; the source of truth then becomes a single table. 3. Manual cleanup of one stuck order in gis_enrichment.CfExtract (354686, pending since 2026-05-19) — never advanced past `pending`, was showing up as "În coadă" in the Extrase CF tab for ~4 days. Set status=cancelled with an explanatory errorMessage. (Applied via direct SQL on postgres-gis; no code change for this.) Co-Authored-By: Claude Opus 4.7 (1M context) --- src/modules/geoportal/v2/cf-order-modal.tsx | 8 ++++++-- src/modules/parcel-sync/components/cf-api-base.ts | 11 +++++++++-- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/src/modules/geoportal/v2/cf-order-modal.tsx b/src/modules/geoportal/v2/cf-order-modal.tsx index 6b86f04..4859c6e 100644 --- a/src/modules/geoportal/v2/cf-order-modal.tsx +++ b/src/modules/geoportal/v2/cf-order-modal.tsx @@ -65,7 +65,11 @@ interface Props { } const POLL_INTERVAL_MS = 3_000; -const POLL_TIMEOUT_MS = 90_000; +// ANCPI orders regularly take 60-180s end-to-end (depends on cart load +// + ANCPI document queue); a 90s timeout was firing before the order +// finished even when the queue completed correctly. 180s catches the +// long tail without giving the user a "stuck forever" feel. +const POLL_TIMEOUT_MS = 180_000; export function CfOrderModal({ open, @@ -484,7 +488,7 @@ export function CfOrderModal({ /> {phase === "processing" && (

- Poate dura până la 60 de secunde. Poți închide fereastra — + Poate dura până la 3 minute. Poți închide fereastra — comanda continuă în fundal.

)} diff --git a/src/modules/parcel-sync/components/cf-api-base.ts b/src/modules/parcel-sync/components/cf-api-base.ts index 321e905..2e69413 100644 --- a/src/modules/parcel-sync/components/cf-api-base.ts +++ b/src/modules/parcel-sync/components/cf-api-base.ts @@ -14,8 +14,15 @@ import type { CfExtractRow } from "@/lib/gis-api-client"; -export function cfApiBase(useGisAc: boolean): string { - return useGisAc ? "/api/cf" : "/api/ancpi"; +export function cfApiBase(_useGisAc: boolean): string { + // Temporarily pinned to legacy /api/ancpi until Faza H lands. + // Background: pilot users (useGisAc=true) were routed to /api/cf + // which proxies to gis-api → gis_core."CfExtract". But the ePay queue + // still writes only to architools_postgres."CfExtract" (legacy). Pilot + // users were missing their own fresh orders in the listing + catalog + // checks. Until the queue mirrors writes to gis-api, every caller + // uses the legacy endpoint so the read source matches the write source. + return "/api/ancpi"; } // UI-side row shape (mirrors what epay-tab.tsx already expects).