Exclude disabled categories from the GraphQL route query

[thai2301]

Description (*)

The GraphQL route query returns a valid result (type CATEGORY, a relative URL) for a category that has been disabled, instead of returning null. This is a security/data exposure issue: a category the merchant explicitly disabled is still reachable and resolvable through the storefront GraphQL API.

Root cause: Magento\CatalogUrlRewriteGraphQl\Model\DataProvider\UrlRewrite\CatalogTreeDataProvider::getData() loads the category tree and only checks whether the category exists at all, never whether it is active. The analogous ProductDataProvider::getData() already rejects disabled products the same way (Status::STATUS_ENABLED check, since 2.4.9), but no equivalent check was ever added on the category side.

Fix: use the CategoryRepository that was already injected into CatalogTreeDataProvider (but previously unused) to load the category and check getIsActive() before resolving the tree, throwing GraphQlNoSuchEntityException if the category is disabled - matching the product behavior and the route query's documented contract.

Related Pull Requests

N/A

Fixed Issues (if relevant)

1. Fixes [GraphQL] route query ignoring whether a category is disabled #40987

Manual testing scenarios (*)

1. Create a new category, keep it enabled, note its URL key.
2. Disable the category.
3. Run the GraphQL query:

query route {
  route(url: "your-url-key") {
    type
    relative_url
  }
}

4. Before the fix: the category is returned (type: CATEGORY, a relative URL). After the fix: route returns null.
5. Repeat with the category re-enabled and confirm it resolves normally as before.

Questions or comments

Unit test added: Magento\CatalogUrlRewriteGraphQl\Test\Unit\Model\DataProvider\UrlRewrite\CatalogTreeDataProviderTest (verified against the Magento2 coding standard and passing locally under PHPUnit 12).

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)
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @thai2301. 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.

[thai2301]

@magento run Unit Tests, Static Tests, WebAPI Tests

[thai2301]

Updated with latest 2.4-develop.