fix(core-flows): cascade custom links when deleting product variants - #16733
fix(core-flows): cascade custom links when deleting product variants#16733brunoocal wants to merge 3 commits into
Conversation
Process product_variant_id alongside legacy variant_id when deleting variants. The existing compensation restores both link types. Verified with four PostgreSQL integration cases, strict fixture typechecking and targeted lint.
🦋 Changeset detectedLatest commit: b367b15 The changes in this PR will be included in the next version bump. This PR includes changesets to release 83 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks for the contribution! A few items need to be addressed before this can move forward: The contributor targets a real, confirmed bug where deleteProductVariantsWorkflow only passed the legacy variant_id key to removeRemoteLinkStep, leaving custom links registered with ProductModule.linkable.productVariant (which generate a product_variant_id key) un-deleted. The fix passes both keys in a single call, which is correct given how removeRemoteLinkStep groups and forwards them to link.delete. The compensation path in removeRemoteLinkStep receives the full grouped object and so will restore both key types, which is also correct. The integration tests are comprehensive: they exercise direct link delete/restore, cascade deletion via the workflow (including the native price-set link), compensation after a downstream failure, and inventory-only deletion. Tests are placed in integration-tests/modules/ following existing patterns and use the pre-existing brand module fixture. PR template is complete, a patch changeset targeting @medusajs/core-flows is included, and the fix is narrowly scoped to the stated issue. The linked issue (#16732) carries the help-wanted label. One required change: the changeset message body does not follow Medusa's required format.
Triggered by: new PR opened |
|
Thanks for the contribution! Initial automated review looks good. The contributor fixes a real bug where deleteProductVariantsWorkflow only passed the legacy variant_id key to removeRemoteLinkStep, leaving custom links registered via ProductModule.linkable.productVariant (which generate a product_variant_id key) un-deleted on variant deletion. The fix adds product_variant_id alongside variant_id in the single removeRemoteLinkStep call; both keys are forwarded by the step and its compensation, so native links (price set, inventory) and descriptor-generated custom links are both handled correctly. The previously flagged changeset format issue has been resolved: the message now reads fix(@medusajs/core-flows): cascade custom links on product-variant deletion, which follows the required format. The four integration tests are comprehensive — they cover direct link delete/restore, cascade deletion via the workflow (including the native price-set link), compensation after a downstream step failure, and exclusive-inventory deletion. Tests are placed in integration-tests/modules/ following existing patterns and use the shared brand module fixture. The changeset targets @medusajs/core-flows as a patch, a linked and confirmed issue is present, and the diff is narrowly scoped to the stated problem. Triggered by: new commit pushed |
Summary
What
Deleting a variant through
deleteProductVariantsWorkflownow cascades to custom records linked withProductModule.linkable.productVariantanddeleteCascade: true.Closes #16732.
Why
The standard descriptor generates
product_variant_id, but the workflow only passed the legacyvariant_idtoremoveRemoteLinkStep. Variants and native price sets were deleted while custom linked records remained active. The issue includes a standalone reproduction using unmodified 2.20.1 packages.How
Pass both
variant_idandproduct_variant_idin the existing step call. Keeping the legacy key preserves native price and inventory links. The existing compensation receives both keys and restores both link types. No link schema changes or changes to the general Link service are needed.Testing
Four integration cases use real Medusa services and a disposable PostgreSQL instance:
Link.deleteandLink.restorework with the standard custom link.Before the fix: 2 passed, 2 failed. With the fix: 4 passed, exit code 0. Jest exited naturally without
forceExitor retries. No internal modules are mocked.The core-flows build, strict typechecking of the new test and fixture, and targeted ESLint checks passed. The complete monorepo test suite was not run.
With the monorepo dependencies built and
DB_HOST=localhost,DB_PORT,DB_USERNAMEandDB_PASSWORDconfigured for a disposable PostgreSQL instance:cd integration-tests/modules node ../../node_modules/jest/bin/jest.js --config ./jest.config.js --runInBand --runTestsByPath __tests__/link-modules/product-variant-cascade.spec.tsExample
This existing standard link now cascades when the native variant-deletion workflow runs:
Checklist
@medusajs/core-flows.Additional context
This change covers individual variant deletion. Parent-product deletion uses another workflow and is not changed here. The tests exercise the workflow directly, not the HTTP endpoint or separate server/worker processes.
The test runner prints
Connection Error: Connection ended unexpectedlyboth before and after the fix. These warnings were not suppressed, and all four patched tests complete with exit code 0.Created with GPT-6 Astra in Codex.