Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active order returns null when combined with other queries #2097

Closed
StampixSMO opened this issue Mar 23, 2023 · 3 comments
Closed

Active order returns null when combined with other queries #2097

StampixSMO opened this issue Mar 23, 2023 · 3 comments
Assignees
Labels
Milestone

Comments

@StampixSMO
Copy link
Contributor

Describe the bug
When requesting multiple queries from the server, one of which is the activeOrder, the active order returns null.

To Reproduce
Steps to reproduce the behavior:

  1. Make sure you have an active order
  2. Run this query
    query test {
    	activeOrder {
    		id
    	}
    	activeChannel {
    		id
    	}
    }

Expected behavior
Active order not to be null.

Environment (please complete the following information):

  • @vendure/core version: 1.9.3
  • Nodejs version: 16
  • Database (mysql/postgres etc): postgres

Additional context

If you remove the activeChannel query, the active order gets returned properly.

@Job-madi
Copy link

Hey @michaelbromley, could I be assigned to this issue?

@michaelbromley michaelbromley moved this from 📅 Planned to 🏗 In progress in Vendure OS Roadmap Sep 17, 2024
@michaelbromley
Copy link
Member

I spent some time investigating this issue (I even live streamed the debugging session here https://www.youtube.com/live/f0srTEUqr5Y?si=VQT78GlA7KXXQ60U&t=361)

The root cause is that the AuthGuard.canActivate executes for both resolvers, activeOrder and activeChannel in a non-deterministic order.

For any given query field there are 3 relevant steps as relates to this issue:

  1. AuthGuard.canActivate runs for that field
  2. Inside that method, we create a RequestContext object. Part of that is determining the state of the authorizedAsOwnerOnly property. This differs depending on whether the target field's resolver has an @Allow(Permission.Owner) decorator.
  3. The newly-created RequestContext object gets attached to the req object so it can be picked up by the @Ctx() decorator in the resolver.

Step 3 is where the bug arises. There are 2 possible sequences, and which one occurs is non-deterministic:

happy path

  1. AuthGuard runs for the activeOrder query. authorizedAsOwnerOnly gets set to true
  2. Resolver executes for activeOrder. authorizedAsOwnerOnly === true and the order gets returned.
  3. AuthGuard runs for activeChannel. authorizedAsOwnerOnly gets set to false (because it does not have the Permission.Owner decorator)
  4. Resolver executes for activeChannel

error path

  1. AuthGuard runs for the activeOrder query. authorizedAsOwnerOnly gets set to true
  2. AuthGuard runs for activeChannel. authorizedAsOwnerOnly gets set to false
  3. Resolver executes for activeOrder. authorizedAsOwnerOnly === false (it was last set in the activeChannel auth guard) and no order is returned
  4. Resolver executes for activeChannel

I am currently exploring alternative approaches to how we store the RequestContext and make it available to resolvers & controller methods.

@casperiv0
Copy link
Contributor

Thank you, Michael!

@michaelbromley michaelbromley moved this from 🏗 In progress to 🔖 Ready in Vendure OS Roadmap Sep 20, 2024
@dlhck dlhck added this to the v3.0.4 milestone Sep 27, 2024
@michaelbromley michaelbromley moved this from 💯 Ready to 🚀 Shipped in Vendure OS Roadmap Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

5 participants