2 some basic change as per requirement
source | link

This looks like a known issue: https://github.com/magento/magento2/issues/17634issue:
This does happen from time to time on the project I'm working on, but I wasn't able to find the steps to reproduce. All I can say is that it happens during a deployment process.
All I could find is that under certain circumstances a file .regenerate is written in the var folder (either at setup upgrade or composer install / upgrade) and if that file is present when running setup:di:compile the cache is disabled and re-enabled when the compilation process is finished.
For some reason, sometimes the cache is not re-enabled.
We took the quick and dirty approach and made the last step of the deployment process php bin/magento cache:enable to be sure. SO basically we hid the dirt under the rug.

You can find the code that disables the cache in here: https://github.com/magento/magento2/blob/2.3-develop/lib/internal/Magento/Framework/Code/GeneratedFiles.php#L69.here
It is wrapped in a TODO: remove statement.

This looks like a known issue: https://github.com/magento/magento2/issues/17634
This does happen from time to time on the project I'm working on, but I wasn't able to find the steps to reproduce. All I can say is that it happens during a deployment process.
All I could find is that under certain circumstances a file .regenerate is written in the var folder (either at setup upgrade or composer install / upgrade) and if that file is present when running setup:di:compile the cache is disabled and re-enabled when the compilation process is finished.
For some reason, sometimes the cache is not re-enabled.
We took the quick and dirty approach and made the last step of the deployment process php bin/magento cache:enable to be sure. SO basically we hid the dirt under the rug.

You can find the code that disables the cache in here: https://github.com/magento/magento2/blob/2.3-develop/lib/internal/Magento/Framework/Code/GeneratedFiles.php#L69.
It is wrapped in a TODO: remove statement.

This looks like a known issue:
This does happen from time to time on the project I'm working on, but I wasn't able to find the steps to reproduce. All I can say is that it happens during a deployment process.
All I could find is that under certain circumstances a file .regenerate is written in the var folder (either at setup upgrade or composer install / upgrade) and if that file is present when running setup:di:compile the cache is disabled and re-enabled when the compilation process is finished.
For some reason, sometimes the cache is not re-enabled.
We took the quick and dirty approach and made the last step of the deployment process php bin/magento cache:enable to be sure. SO basically we hid the dirt under the rug.

You can find the code that disables the cache in here
It is wrapped in a TODO: remove statement.

1
source | link

This looks like a known issue: https://github.com/magento/magento2/issues/17634
This does happen from time to time on the project I'm working on, but I wasn't able to find the steps to reproduce. All I can say is that it happens during a deployment process.
All I could find is that under certain circumstances a file .regenerate is written in the var folder (either at setup upgrade or composer install / upgrade) and if that file is present when running setup:di:compile the cache is disabled and re-enabled when the compilation process is finished.
For some reason, sometimes the cache is not re-enabled.
We took the quick and dirty approach and made the last step of the deployment process php bin/magento cache:enable to be sure. SO basically we hid the dirt under the rug.

You can find the code that disables the cache in here: https://github.com/magento/magento2/blob/2.3-develop/lib/internal/Magento/Framework/Code/GeneratedFiles.php#L69.
It is wrapped in a TODO: remove statement.