I've talked about parts of this before, with no real resolution, and it's still happening, so here I go again, thoughts are most welcome. Fairly often, when code gets promoted to production, one or both of two errors start happening on that server: • Element EXECUTIONMODE is undefined in THISTAG, in one particular template that's used a lot, and wasn't among the newly updated files • Multiple seemingly random pages that also weren't just updated start crashing because they can't find that same template Clearing the template cache fixes it. Has anyone else seen this? Any idea how to make it not happen?

For our production workflow, we have our template cache set to always cache templates. Then once we've deployed, we flush our template cache. This tends to avoid deployment issues that can occur when a template is requested at the same time it's in the process of being updated.

That's what we do too, but a) sometimes people forget, and b) doesn't explain why the errors keep happening once they start. Is this really a recommended best practice?

Take the new approach that tosses everything in the garbage every new deployment and recreates the server in the deployment fresh and clean and identical to every other environment.

this rocks, it marks the template cache as being potentially dirty https://docs.lucee.org/reference/functions/inspecttemplates.html

@zackster I like it! But, we're ACF.

We also do what Patrick says. When we deploy our code, it goes into a new directory. Once all the code has been deployed, the original folder is renamed/removed and then the new folder takes its place. You could certainly do this with symlinks too.

That is one part of it but I am referring to tossing the entire CF installation and installing fresh in a new VM/docker container so the entire installation is identical and brand new along with your new code base.

@Dave Merrill to answer your question: I don't think there's anything you can do in your code or CF server config to fix this. It's just CF getting confused because [reasons]. If you could repro it: I'd raise a bug. Pretty sure I have seen this before too, but... not completely sure. That said... clearing yer template & trusted cache should be a required part of your deployment anyhow (as others have said), so that will likely remove the issue anyhow. As for "sometimes people forget"... well there's a different problem right there. It shouldn't be something someone needs to remember to do. It should be part of your deployment process.

Agree, and we've called it out as a thing that's needed with CF 2018. But last night someone (my boss actually) promoted one new report, and didn't think he needed to jiggle that handle just for that. He was wrong 🙂

Def doesn't make a great deal of sense, no.

Re rebuilding the whole app directory from scratch, for this app, that's roughly 6.5G, 30k files. That'd be an awful lot of thrash to refresh reality after promoting a single new cfm file.

~230kB of code per file? Erm... that's quite some app you have there. Or maybe a faulty calculator... 😉

Hah! lemme check that 🙂

But yeah, point taken that it's a pain in the butt. I'd def time how long it takes to blow-away the trusted cache, and then to recompile. You could maybe warm files in the core of the app, and leave outliers to recompile on the fly as they're called? The added overhead per req would not be so much then perhaps. I've not been in this sorta situation before... earlier gig the app was not so big that it was a problem to recompile everything. But we had servers in a load so could cycle them out whilst we warmed them, etc. Current app is not big enough to worry about: also not public-facing, and not very high traffic either.

Turns out the bulk of it by size is error dump files going back to 2013, some really big. And no we don't need to clone that stuff if we were trying to go with a rebuild-the-world strategy, but I'm not going to refactor that today 🙂

Ha! It's good we discussed this angle of attack eh?

I'm still not going to build out infrastructure to support rebuilding the world every time we promote a file, at least not now. But you're right it's good to know where the bulk of all those files is coming from.