Modify createClassDefinition to include application mode

[Genaker]

Disable runtime code generation in production mode

Description

This patch stops Magento from generating Interceptors, Factories, and Proxies at runtime when running in production mode.

In production, all generated classes must be created beforehand by bin/magento setup:di:compile. If they are missing (for example after generated/code is cleared during deployment), Magento should fail with a clear error instead of generating them on the fly.

Changes

• DefinitionFactory: Registers the Generator Autoloader only when the application mode is not production.
• ObjectManagerFactory: Passes the application mode from deployment config into createClassDefinition().

Behaviour

Mode	Generator Autoloader	Runtime generation
developer	Registered	Yes
default	Registered	Yes
production	Not registered	No

Requirements

• Run bin/magento setup:di:compile during deployment before serving traffic.
• Ensure generated/code is populated before going live.

Resolved issues:

1. resolves [Issue] Modify createClassDefinition to include application mode #40571: Modify createClassDefinition to include application mode

[m2-assistant]

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

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email psirt@adobe.com.

[engcom-Hotel]

@magento create issue

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email psirt@adobe.com.

[ihor-sviziev]

@engcom-Hotel is there a chance that Product Owner can accept this change?
I think it is good feature especially for read-only environments.
For my perspective, it can be made configurable by some config flag, and disabled by default in order to make it backward compatible

[Genaker]

Hi Ihor, I agree that this is a valuable feature, especially for read-only environments. There are many similar issues where writable env files, config files, and cache poisoning—caused by old data during deployment from the maintenance page, cron, or message queues—create significant challenges. Making this configurable with a flag and disabled by default seems like a solid approach to maintain backward compatibility while addressing these risks. Best regards, Yegor Shytikov

…

On Tue, Mar 3, 2026 at 1:26 PM Ihor Sviziev ***@***.***> wrote: ***@***.**** commented on this pull request. @engcom-Hotel <https://github.com/engcom-Hotel> is there a chance that Product Owner can accept this change? I think it is good feature especially for read-only environments. For my perspective, it can be made configurable by some config flag, and disabled by default in order to make it backward compatible — Reply to this email directly, view it on GitHub <#40567 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGJNZQFUECZOWGLWT2URL34O5EZLAVCNFSM6AAAAACWES3SNGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQOBVGEZDQMJWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[engcom-Hotel]

Hi @Genaker @ihor-sviziev,

I agree with your point. Since the PR is already marked as a feature request, we will send an email to the PO for approval whenever we pick this up.

Thank you

[ihor-sviziev]

@Genaker I believe this change can improve performance. Did you notice any improvements after your changes? If it does, I guess it can be a good point to accept this change for PO