[eastagiletracker]

This PR proposes making the CSV importer's variant-axis checks deterministic, which closes known issue 3 in docs/known-issues.md and lets test:csv gate CI again. We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/1129. You can sign in with your GitHub ID to claim ownership of the project.

What this changes

Checks 32 to 34 expected a Size: Small/Medium import to be rejected as an unsupported axis value. On a clean database it succeeds, because seed:pk creates the size axis through createProductAttributesWorkflow, so it carries a product_option_id, and Mercur 2.3's createProductAttributeValuesWorkflow mirrors any new value onto that option. So whether a value can be used depends on the axis, not on the value. If the attribute has a mirrored product option, new values work. If it has none (the attribute was created through the module service), no value on it can ever be used, and the importer correctly refuses those rows. The old checks only passed on databases whose Size values predated the mirroring.

The rejection checks now set up that condition themselves. Each run creates its own unmirrored axis (Fit <stamp>, not filterable) through the module service. A new check guards the precondition (product_option_id is null), the three original assertions run against that axis unchanged, and the axis is deleted in a finally. The Size import stays in as the supported case and now asserts what actually happens: one product, two variants carrying the uploaded sizes, two offers for the seller at the CSV price. The importer's "KNOWN LIMITATION" comment is rewritten to describe the real condition (no logic change). Because the suite is now deterministic, continue-on-error is removed from the CI step. The known-issues entry is moved to a one-line limitation under "Catalogue import", and the assertion counts (229 to 233, CSV 34 to 38) are updated wherever the docs quote them.

How it was verified

Reproduced on main at e02290e against a fresh Postgres 16 + Redis 7, migrated and seeded exactly as ci.yml does:

bun run test:csv
  32. FAIL  Unsupported variant axis value is rejected, not half-imported — ok=true products=1
  33. FAIL  Rejection is row-level and names the offending value
  34. FAIL  Rejected variant product left nothing behind
3 of 34 checks FAILED

With this branch I built a fresh database, ran migrate, seed:pk, seed:commissions and seed:digital, then ran every suite in CI order. test:settlement 34, test:payout 26, test:csv 38, test:shopify 29, test:otp 22, test:confirmation and test:digital all passed. test:csv also passed 38/38 on a second run against the same accumulated database. npx tsc --noEmit in packages/api is clean. The baseline failure set was exactly the three checks above, so nothing new went red.

Proof the tests can fail

• Making ensureVariantAxes treat unmirrored values as usable: the product workflow throws Product has 0 option values but there were 1 provided option values for the variant: Slim. and the suite goes red.
• Creating offers for the first variant only: checks 32 and 34 go red (offers=1).
• Swapping the SKUs between the two variants: check 33 goes red ({"KRT-…-M":["Small"],"KRT-…-S":["Medium"]}).
• Creating the test axis through createProductAttributesWorkflow instead: check 35 goes red (product_option_id=opt_…) and 36 to 38 reproduce the original failure. If the precondition ever drifts, the guard reports it.

How this was managed

We imported your repo's pull requests and history into a board at https://eastagiletracker.com/projects/1129 (11 stories) and tracked this work as https://eastagiletracker.com/projects/1129/stories/1340816.

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.

---

Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com