fix(medusa): Correct MedusaRequest query type

[NicolasGorga]

Summary

What — What changes are introduced in this PR?

Updates MedusaRequest generics in /store/currencies get endpoints.

Why — Why are these changes relevant or necessary?

To align the body and query types to what is actually expected.

How — How have these changes been implemented?

Corrected MedusaRequest generics adding undefined as the first type parameter so the already passed type is correctly mapped to query instead of body.

Testing — How have these changes been tested, or how can the reviewer test the feature?

---

Examples

Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.

// Example usage

---

Checklist

Please ensure the following before requesting a review:

• I have added a changeset for this PR
  • Every non-breaking change should be marked as a patch
  • To add a changeset, run yarn changeset and follow the prompts
• The changes are covered by relevant tests
• I have verified the code works as intended locally
• I have linked the related issue(s) if applicable

---

Additional Context

Add any additional context, related issues, or references that might help the reviewer understand this PR.

closes ENTSUP-279

[cursor]

You have run out of free Bugbot PR reviews for this billing cycle. This will reset on December 17.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[changeset-bot]

🦋 Changeset detected

Latest commit: 39aeddf

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 74 packages

Name	Type
@medusajs/medusa	Patch
@medusajs/test-utils	Patch
@medusajs/medusa-oas-cli	Patch
integration-tests-http	Patch
@medusajs/analytics	Patch
@medusajs/api-key	Patch
@medusajs/auth	Patch
@medusajs/caching	Patch
@medusajs/cart	Patch
@medusajs/currency	Patch
@medusajs/customer	Patch
@medusajs/file	Patch
@medusajs/fulfillment	Patch
@medusajs/index	Patch
@medusajs/inventory	Patch
@medusajs/link-modules	Patch
@medusajs/locking	Patch
@medusajs/notification	Patch
@medusajs/order	Patch
@medusajs/payment	Patch
@medusajs/pricing	Patch
@medusajs/product	Patch
@medusajs/promotion	Patch
@medusajs/region	Patch
@medusajs/sales-channel	Patch
@medusajs/settings	Patch
@medusajs/stock-location	Patch
@medusajs/store	Patch
@medusajs/tax	Patch
@medusajs/user	Patch
@medusajs/workflow-engine-inmemory	Patch
@medusajs/workflow-engine-redis	Patch
@medusajs/draft-order	Patch
@medusajs/oas-github-ci	Patch
@medusajs/cache-inmemory	Patch
@medusajs/cache-redis	Patch
@medusajs/event-bus-local	Patch
@medusajs/event-bus-redis	Patch
@medusajs/analytics-local	Patch
@medusajs/analytics-posthog	Patch
@medusajs/auth-emailpass	Patch
@medusajs/auth-github	Patch
@medusajs/auth-google	Patch
@medusajs/caching-redis	Patch
@medusajs/file-local	Patch
@medusajs/file-s3	Patch
@medusajs/fulfillment-manual	Patch
@medusajs/locking-postgres	Patch
@medusajs/locking-redis	Patch
@medusajs/notification-local	Patch
@medusajs/notification-sendgrid	Patch
@medusajs/payment-stripe	Patch
@medusajs/core-flows	Patch
@medusajs/framework	Patch
@medusajs/js-sdk	Patch
@medusajs/modules-sdk	Patch
@medusajs/orchestration	Patch
@medusajs/types	Patch
@medusajs/utils	Patch
@medusajs/workflows-sdk	Patch
@medusajs/cli	Patch
@medusajs/deps	Patch
@medusajs/telemetry	Patch
@medusajs/admin-bundler	Patch
@medusajs/admin-sdk	Patch
@medusajs/admin-shared	Patch
@medusajs/admin-vite-plugin	Patch
@medusajs/dashboard	Patch
@medusajs/icons	Patch
@medusajs/toolbox	Patch
@medusajs/ui-preset	Patch
create-medusa-app	Patch
medusa-dev-cli	Patch
@medusajs/ui	Patch

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

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

8 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
api-reference	Ignored			Nov 27, 2025 4:34pm
api-reference-v2	Ignored	Preview		Nov 27, 2025 4:34pm
cloud-docs	Ignored	Preview		Nov 27, 2025 4:34pm
docs-ui	Ignored	Preview		Nov 27, 2025 4:34pm
docs-v2	Ignored	Preview		Nov 27, 2025 4:34pm
medusa-docs	Ignored	Preview		Nov 27, 2025 4:34pm
resources-docs	Ignored	Preview		Nov 27, 2025 4:34pm
user-guide	Ignored	Preview		Nov 27, 2025 4:34pm

[olivermrbl]

pretty sure we have done this all over the place; are you sure this is correct? if so, maybe we need to update more places

[NicolasGorga]

pretty sure we have done this all over the place; are you sure this is correct? if so, maybe we need to update more places

I'm positive. Included fixes to all the incorrect usages.

[adrien2p]

I think it is fine, I am just wondering if it would make sense to do something like this

export interface AuthenticatedMedusaRequest<
  BodyOrQueryFields = unknown,
  QueryFields extends Record<string, unknown> = {}
> extends MedusaRequest<
    {} extends QueryFields ? undefined : BodyOrQueryFields,
    {} extends QueryFields
      ? BodyOrQueryFields & Record<string, unknown>
      : QueryFields
  > {
  auth_context: AuthContext
  publishable_key_context?: PublishableKeyContext
}

export interface MedusaRequest<
  Body = unknown,
  QueryFields extends Record<string, unknown> = {}
> extends Request<
    { [key: string]: string },
    any,
    {} extends QueryFields ? Body : undefined
  > {
  validatedBody: {} extends QueryFields ? undefined : Body
  validatedQuery: {} extends QueryFields
    ? RequestQueryFields
    : RequestQueryFields & QueryFields
//...

Here we would allow for

• single template args -> query fields
• both -> body, fields

Let me know if that makes sense guys (cc @olivermrbl)

[NicolasGorga]

I think it is fine, I am just wondering if it would make sense to do something like this

export interface AuthenticatedMedusaRequest<
  BodyOrQueryFields = unknown,
  QueryFields extends Record<string, unknown> = {}
> extends MedusaRequest<
    {} extends QueryFields ? undefined : BodyOrQueryFields,
    {} extends QueryFields
      ? BodyOrQueryFields & Record<string, unknown>
      : QueryFields
  > {
  auth_context: AuthContext
  publishable_key_context?: PublishableKeyContext
}

export interface MedusaRequest<
  Body = unknown,
  QueryFields extends Record<string, unknown> = {}
> extends Request<
    { [key: string]: string },
    any,
    {} extends QueryFields ? Body : undefined
  > {
  validatedBody: {} extends QueryFields ? undefined : Body
  validatedQuery: {} extends QueryFields
    ? RequestQueryFields
    : RequestQueryFields & QueryFields
//...

Here we would allow for

• single template args -> query fields
• both -> body, fields

Let me know if that makes sense guys (cc @olivermrbl)

I like this since I think users might not consistently understand that they should put undefined as the first type parameter for requests without a body. Additionally, it is more convenient not to have to do this in these cases and simply specify the query parameter type. Let me know wyt Oli, and I'll proceed with the update.

[NicolasGorga]

Hey @adrien2p I've updated the types with your suggestion, with a small correction on the MedusaRequest type if you could check?

Also, if you could help me know how we could handle the following error when building in packages/core/framework/src

src/http/utils/validate-body.ts:31:7 - error TS2322: Type 'ZodRawShape' is not assignable to type 'undefined'.

31       req.validatedBody = await zodValidator(schema, req.body)
         ~~~~~~~~~~~~~~~~~


Found 1 error.

This happens when not providing any types. QueryFields is the default value, which treats the Body param as the query one and evaluates to undefined.

[olivermrbl]

Neat

didn't see the discussion, I think adrien's suggestion makes sense to incorporate if its feasible

[NicolasGorga]

Yes, added the changes to the type as per Adrien suggestion, though that introduces the issue I mentioned in my last comment when we don't pass the types and use defaults, while try to assign to validatedBody, since in these cases it is treated as undefined (as per the "if only one type provided, we assume no body and only query"). I will wait for his input :)

[adrien2p]

Yes, added the changes to the type as per Adrien suggestion, though that introduces the issue I mentioned in my last comment when we don't pass the types and use defaults, while try to assign to validatedBody, since in these cases it is treated as undefined (as per the "if only one type provided, we assume no body and only query"). I will wait for his input :)

Yeah I ve suggeted undefined but it can be a record or unknown or something like that, the main idea is to route the correct template args to the correct location 👍

[NicolasGorga]

I am still having build issues, thinking of how to solve this with the changes we did

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[medusa-os-bot]

Thank you for working on this!

After reviewing this PR, there are a few things that need to be addressed before we can move forward:

Required changes:

• The build error in packages/core/framework/src/http/utils/validate-body.ts mentioned in the comments (Nov 27) is unresolved. req.validatedBody = await zodValidator(schema, req.body) fails to compile because the updated types make validatedBody typed as undefined in the default (no-type-args) case. This needs to be resolved before the PR can be merged.
• The "Testing" section of the PR template is empty — please describe how the fix can be verified.

Concern:
The adrien2p conditional-type approach (single param → query type) adds complexity and has the known assignment issue above. If that approach is proving difficult to stabilise, the simpler alternative — keeping the two-param signature and updating call sites to pass undefined as the first arg — would still correctly fix the type mapping and avoid the build error entirely. Either approach is fine, but the current state has an open build failure that blocks merging.