fix(payment): return correct result shape from updatePaymentCollections and workflow - #16777
fix(payment): return correct result shape from updatePaymentCollections and workflow#16777coderlucifer wants to merge 2 commits into
Conversation
…ns and workflow The selector overload of updatePaymentCollections checked Array.isArray(data) to decide between single/array result, but data is always an object. Changed to check isString(idOrSelector) to correctly return an array for selector calls. Also normalized the createOrUpdateOrderPaymentCollectionWorkflow to return [] instead of undefined when neither branch executes. Fixes medusajs#16751
🦋 Changeset detectedLatest commit: 34a5a62 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! Initial automated review looks good. This PR fixes two related type-contract violations in the payment module and the order payment-collection workflow. 1. packages/modules/payment/src/services/payment-module.ts: The updatePaymentCollections implementation used Array.isArray(data) to choose between returning a single DTO or an array. Since data is the update payload (always a plain object, never an array), this guard was always false, causing the selector overload to incorrectly return only result[0] instead of the declared PaymentCollectionDTO[]. The fix switches to isString(idOrSelector), which correctly returns a single DTO for the ID overload and a full array for the selector overload. isString is already imported and used earlier in the same method. 2. packages/core/core-flows/src/order/workflows/create-or-update-order-payment-collection.ts: The workflow's final transform could return undefined when neither the create nor the update branch executed. The || [] fallback ensures the result is always PaymentCollectionDTO[] as declared. The PR includes a changeset (patch bump for @medusajs/payment and @medusajs/core-flows, fix(...) format) and two integration tests that directly verify the selector-overload array return and the string-ID single-DTO return against the existing pay-col-id-2 fixture. The fix is narrowly scoped to the reported issue, conventions are followed, and no security or performance concerns were found. Triggered by: new PR opened |
1 participant
What
Fix result type mismatch in
updatePaymentCollectionsselector overload andcreateOrUpdateOrderPaymentCollectionWorkflow.Fixes #16751
Why
The
createOrUpdateOrderPaymentCollectionWorkflowdeclaresPaymentCollectionDTO[]as its result type, but:The update branch returns a single
PaymentCollectionDTOinstead of an array — becauseupdatePaymentCollectionsin the Payment Module checksArray.isArray(data)(the update payload, which is always an object) instead of checking the first argument (idOrSelector). This causes the selector overload to always serializeresult[0]instead of the fullresultarray.The no-op branch returns
undefinedinstead of[]— when neither the create nor update branch executes (e.g., zero pending amount with no existing collection), the transform returnsundefined.This silently breaks any caller relying on the declared array contract (e.g.,
result[0].id).How
packages/modules/payment/src/services/payment-module.ts(L284)Changed the serialization guard from:
isString(idOrSelector)correctly returns a single DTO for the ID overload and an array for the selector overload, matching the declared type signatures.packages/core/core-flows/src/order/workflows/create-or-update-order-payment-collection.ts(L198)Added
|| []fallback:Ensures the workflow always returns
PaymentCollectionDTO[]as declared.Testing
packages/modules/payment/integration-tests/__tests__/services/payment-module/index.spec.ts:PaymentCollectionDTO[]PaymentCollectionDTOresult[0]regardless of call style