Twig cache configuration is broken

[NoelLH]

Sorry for not making a clear issue about this sooner so that somebody else can have a look – this is the first day I've had chance in all this time. I thought we were close to getting all the great updates @rasmuswinter made (and maybe-passable ones I made) live in November, but then got very very busy with urgent non-Outlandish work (this, hooray!) and with arranging my 2nd and 3rd mid-pandemic house moves. As the latter is still in progress I won't be writing any code this week, but wanted to spell out the remaining issue as far as I understand it and get some of the many issues about the same side effects under control, so we can focus on resolving the root problem(s).

Here's what I found out on 17 November:

after an hour of poking at the weekend I couldn’t work out what’s going on with Twig’s cache. I set up Fargate ephemeral storage for it as it felt more appropriate than throwing stuff inside the Docker volume, but it hit the same error trying to make directories there despite my permission hack attempts. I’m sure it’s something stupid and the right clear/warmup command on entry will sort it

Here's my last attempt to prepare the folder for Twig in the ECS entrypoint.

You'll see in config that locally the setup is a little different, and appears to work, which makes this quite hard to debug, but I'm hoping somebody with relevant experience will be able to see why what I've done fails to translate to the ECS counterpart.

The warmup itself appears to work OK. But here's the log output as a task using that version's image attempts to start (all prior attempts have similar results):

[Tue Dec 22 09:20:36.588017 2020] [php7:notice] [pid 55] [client 172.31.202.210:7026] [critical] Twig\\Error\\RuntimeError \xe2\x80\x93 An exception has been thrown during the rendering of a template ("Unable to write in the cache directory (/mount/ephemeral/twig/31).").\n

Even though we made the parent twig folder and gave it 777 permissions, creating sub-folders on the fly seems to fail – and more interestingly, seems to be necessary even though I expected cache:clear to also do a full Twig cache warm-up.

As a result of the runtime errors, health check fails and new versions of the app simply never roll out. The load balancer sees that its check endpoint returns HTTP 500, refuses to put the new version in service, and kills the task after a while ready for the next try. Consequently the Service served on Staging is still running the app code from 4 October before all the latest fixes on develop.

This is super frustrating as I think we now have all the important stuff living in sensible places that will allow the app to finally perform acceptably, but this silly Twig config thing is blocking the whole app roll-out.

I will be eagerly looking out for any PR that addresses, preferably without turning off template caching, for at least the next few days – and will review as a priority if somebody can make one.

[NoelLH]

I don't think this is a good solution at all, but as a temporary workaround to see if we can roll out and test the other changes on Staging I have merged #369 which turns off Twig template caching completely.