TK-11384: scope stagingColorFor() to the vendor on shared catalog tables

7e0039b0adfc5453cdb7789e8064d8f155980ea6 · 2026-09-10 12:59:40 -0700 · Steve Abrams

stagingColorFor() ran `SELECT color_name FROM ${table} WHERE mfr_sku = … LIMIT 1` with no
vendor filter and no ORDER BY. For the 29 vendors whose catalog_table is the shared
`vendor_catalog` — a table holding 157 distinct vendor_codes, in which 11,640 mfr_sku
values are used by more than one vendor — that returned whichever row the seq scan reached
first, i.e. potentially another vendor's colour.

Demonstrated, not inferred. mfr 5016840 exists as schumacher "sage green" and backdrop
"Seaglass Wallcovering". Before this change, asking for Backdrop returned Schumacher's
row; after it, Backdrop correctly returns "Seaglass Wallcovering" (Schumacher resolves to
its own private schumacher_catalog and is unaffected).

Matters because com.steve.dw-rotation-activator is loaded and runs hourly with --commit.
Impact today was bounded — the value feeds one placeholder-colour test and only one
mfr_sku fleet-wide could flip a verdict — but the query was wrong regardless, and the
blast radius grows with every shared-table vendor added.

Follows this module's fail-open doctrine: a shared table it cannot scope returns null, so
the gate fails OPEN on that dimension rather than reading another vendor's row. Added
ORDER BY color_name for determinism.

NOT changed, flagged for follow-up: reusedMfrSet() still COALESCEs down to
shopify_products.mfr_sku, the column proven polluted with descriptive name strings under
TK-11384. Correcting that alters gate verdicts on an hourly --commit job and wants its own
review.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Files touched

M lib/mfr-gate-resolve.js

Diff

commit 7e0039b0adfc5453cdb7789e8064d8f155980ea6
Author: Steve Abrams <steve@designerwallcoverings.com>
Date:   Thu Sep 10 12:59:40 2026 -0700

    TK-11384: scope stagingColorFor() to the vendor on shared catalog tables
    
    stagingColorFor() ran `SELECT color_name FROM ${table} WHERE mfr_sku = … LIMIT 1` with no
    vendor filter and no ORDER BY. For the 29 vendors whose catalog_table is the shared
    `vendor_catalog` — a table holding 157 distinct vendor_codes, in which 11,640 mfr_sku
    values are used by more than one vendor — that returned whichever row the seq scan reached
    first, i.e. potentially another vendor's colour.
    
    Demonstrated, not inferred. mfr 5016840 exists as schumacher "sage green" and backdrop
    "Seaglass Wallcovering". Before this change, asking for Backdrop returned Schumacher's
    row; after it, Backdrop correctly returns "Seaglass Wallcovering" (Schumacher resolves to
    its own private schumacher_catalog and is unaffected).
    
    Matters because com.steve.dw-rotation-activator is loaded and runs hourly with --commit.
    Impact today was bounded — the value feeds one placeholder-colour test and only one
    mfr_sku fleet-wide could flip a verdict — but the query was wrong regardless, and the
    blast radius grows with every shared-table vendor added.
    
    Follows this module's fail-open doctrine: a shared table it cannot scope returns null, so
    the gate fails OPEN on that dimension rather than reading another vendor's row. Added
    ORDER BY color_name for determinism.
    
    NOT changed, flagged for follow-up: reusedMfrSet() still COALESCEs down to
    shopify_products.mfr_sku, the column proven polluted with descriptive name strings under
    TK-11384. Correcting that alters gate verdicts on an hourly --commit job and wants its own
    review.
    
    Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 lib/mfr-gate-resolve.js | Bin 3815 -> 6328 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/lib/mfr-gate-resolve.js b/lib/mfr-gate-resolve.js
index 22bc88b..cf9a289 100644
Binary files a/lib/mfr-gate-resolve.js and b/lib/mfr-gate-resolve.js differ

← 0bd5974 Record verified 462-product loading and unresolved Google ch · back to Dw Rotation Activator · fix: remove a NUL byte I introduced in 7e0039b's cache key 1e149c4 →