#40235 - Conditionally process collectTotal for CartItemPrices GraphQl based on params in the request

[senthilengg]

Description (*)

1. Added condition to check whether collectTotals must be processed if not retrieve from the DB values
2. Update the discount amount retrieval from extension attributes to child discount amount, since the extension attribute values are only set during collectTotals

Fixed Issues

1. Fixes Cart Query >> CartItemPrices GraphQl Performance Optimisation #40235

Manual testing scenarios (*)

1. GraphQl cart API should tested with CartItemPrices
2. Make sure Simple+Bundle , configurable+bundle and all product types in cart

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @senthilengg. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[senthilengg]

@magento run all tests

[florinel-chis]

why would this be merged or approved? it's a breaking change. especially for any company that has tests and contract testing.

[senthilengg]

why would this be merged or approved? it's a breaking change. especially for any company that has tests and contract testing.

@florinel-chis This PR will not be merged until I fix the automated tests. OOB Magento itself doesn’t have test script for CartItemPrices so I have to write from scratch.

[senthilengg]

@magento run Static Tests, Unit Tests, WebApi Tests

[senthilengg]

@magento run Static Tests

[senthilengg]

@magento run all tests

[senthilengg]

It’s ready for review. Unit testing is abnormally slow and failing. But as per unit test report it’s passed without any failure. Other functional b2b and EE doesn’t seems to be related.

[florinel-chis]

This should not be approved, nor merged. This has not been properly reviewed. Does not describe the problem it solves, what is the impact and so on. If you want to optimise this - then a caching approach that is aware of the last modified date of the cart is a far better way to handle this. Doing all kinds of random "optimisations" is the root of breaking changes. the fact that unit tests pass or the quality gates that are in place pass, does not mean this is a good idea. This kind of MRs should not go and all changes should have an architecture review process.

[senthilengg]

@florinel-chis read the bug ticket details and then you might be able to relate what’s been fixed here.

In a nutshell this PR avoid collectTotals process for every cart query, you may aware collectTotals trigger rule validation which is a heavy process and create performance issues for the quotes that require more than 5 products and 100’s of rule to identify the valid rules to apply. This PR ensures using the previously processed totals from DB instead of reprocess it every time during the request process and thus reduce load time.

If you can elaborate your caching idea in a separate ticket then the community can collaborate on that one, incase if you have a better approach to avoid processing collectTotals then propose that too.

[florinel-chis]

Where is that issue? (Again, this proposed approach and PR should not be merged nor approved).