FulfillmentModuleService.cancelFulfillment calls the shipped/delivered guard via a hardcoded class reference, breaking subclass overrides

[connyg]

Bug/Design gap

cancelFulfillment() in the Fulfillment module service calls its own
cancellation guard via a hardcoded self-reference to the base class
rather than a polymorphic this.constructor call:

medusa/packages/modules/fulfillment/src/services/fulfillment-module-service.ts

Line 1900 in bda24b9

FulfillmentModuleService.canCancelFulfillmentOrThrow(fulfillment)

async cancelFulfillment(id: string, sharedContext = {}) {
  const fulfillment = await this.fulfillmentService_.retrieve(id, {}, sharedContext)
  FulfillmentModuleService.canCancelFulfillmentOrThrow(fulfillment)  // <-- hardcoded
  ...
}

This breaks the standard JS/TS subclassing pattern: a consumer following
Medusa's own documented "extend a module" approach (subclass the core
module's service, register it via medusa-config.ts in place of the
built-in module) who overrides canCancelFulfillmentOrThrow on their
subclass finds it's silently ignored — the base class's own static
method still runs, because the call is bound to FulfillmentModuleService
by name, not this.constructor.

Why this matters

The guard (shipped_at/delivered_at → throw, unconditionally) makes
sense for physical fulfillment, but is a real obstacle for non-physical
fulfillment providers (e.g. digital products, tickets, licenses) where
"shipped"/"delivered" timestamps may get set (intentionally or by an
admin mis-click) without there being any real, physical, irreversible
world-state behind them. There's currently no supported extension point
to relax or customize this rule per fulfillment provider/type — the only
way to change it is to fully reimplement cancelFulfillment(), including
reaching into private (_-suffixed) fields (fulfillmentService_,
fulfillmentProviderService_, baseRepository_) that aren't part of any
documented/stable API.

Suggested fix

Minimal, behavior-preserving for the base class:

async cancelFulfillment(id: string, sharedContext = {}) {
  const fulfillment = await this.fulfillmentService_.retrieve(id, {}, sharedContext)
  ;(this.constructor as typeof FulfillmentModuleService).canCancelFulfillmentOrThrow(fulfillment)
  ...
}

This alone would make the documented module-override pattern actually
work for this guard. A further improvement worth considering: let a
fulfillment provider declare something like handlesPhysicalGoods: false
(returned from getFulfillmentOptions() or a new provider capability),
and have the core guard consult it — so digital/non-physical providers
don't need a full module override at all.

Reproduction

1. Create a fulfillment via a manual-based provider for a
   non-physical/digital order.
2. Call the admin "mark as delivered" action on it (or hit
   markFulfillmentAsDeliveredWorkflow directly).
3. Attempt to cancel the fulfillment (or the order, which needs all
   fulfillments canceled first) → MedusaError, "Fulfillment with id ... already delivered", with no supported way to relax this per
   provider/type without a full module-service override touching
   private fields.

Environment

Medusa v2.19.0

[medusa-os-bot]

Thanks for reporting this! We've labeled it as a bug and will investigate.

Confirmed bug in FulfillmentModuleService.cancelFulfillment (line 1900 of packages/modules/fulfillment/src/services/fulfillment-module-service.ts). The shipped/delivered cancellation guard is called via a hardcoded static reference to FulfillmentModuleService.canCancelFulfillmentOrThrow rather than through this.constructor, which breaks the polymorphic dispatch. Any subclass overriding this guard (e.g. to allow cancellation of digital/non-physical fulfillments that were marked delivered) will have its override silently ignored. The one-line fix is to replace FulfillmentModuleService.canCancelFulfillmentOrThrow(fulfillment) with (this.constructor as typeof FulfillmentModuleService).canCancelFulfillmentOrThrow(fulfillment). Reported on v2.19.0. The fix location and correct code are both identified in the report, making this a good candidate for a community contribution.