DI Compilation Breaks a Factory in Production
A custom module defines a virtual type for a logger channel and a factory for a service class. In developer mode everything works. After deploying to production and running setup:di:compile, requests fail with a class-not-found error for Vendor\Module\ServiceFactory. The service class constructor takes a scalar $limit argument supplied via di.xml. The module's di.xml is in etc/ (not etc/frontend/). The deploy pipeline runs di:compile before setup:upgrade, and the generated code directory is cleared by a later step in the pipeline.
1. Explain why the factory class cannot be found in production but exists in developer mode.
Read the worked answer
In developer mode, Magento generates factories and proxies on demand at runtime, so a missing generated ServiceFactory is created lazily and the request succeeds. In production, runtime generation is disabled; the class must exist in generated/code from setup:di:compile. If di:compile ran before the module's di.xml was in place, or the generated directory was cleared by a later pipeline step, the factory class is never present and autoloading fails.
The pipeline order is suspect: di:compile before setup:upgrade can compile against an incomplete configuration if the module's setup hasn't registered, and a subsequent step that clears generated/code removes the compiled artifacts. Both leave the factory absent.
2. Give the corrected deployment sequence and the di.xml change needed for the scalar argument.
Read the worked answer
Correct sequence: deploy code, run setup:upgrade, then setup:di:compile, then setup:static-content:deploy, then set production mode, then flush caches. Never clear generated/code after di:compile without recompiling. Move di:compile after setup:upgrade so configuration is complete.
For the scalar $limit, declare it in di.xml under the service's arguments as <argument name="limit" xsi:type="number">50</argument>, or expose it via a virtual type if it varies by context. Because the di.xml is in global etc/, the argument applies in all areas; if the service is only used in the frontend, move it to etc/frontend/di.xml. After fixing, run di:compile and confirm generated/code/Vendor/Module/ServiceFactory.php exists before going live.