This afternoon one of our production apps suddenly...
# cfml-general
d
This afternoon one of our production apps suddenly started throwing this exception, a lot, on a template that's used by most pages: Element EXECUTIONMODE is undefined in THISTAG. No files had changed on that server since mid-day yesterday, and the app is in constant use, mostly without problems. It smelled to me like a template got corrupted in memory, so I restarted the CF service (cf 2018 win), and that fixed it. Has anyone run into such a thing? Any ideas on prevention?
a
Questions: • can you post the call stack for the error? • all custom tags, or one? • are your custom tags web browsable (they shouldn't be)? • could you actually replicate it, or was this just something in error logs? • was the problem occurring right up to the moment you did the server restart,a nd then it def stopped as a result of that? Or had it possibly already stopped, and the restart was not intrinsically part of the remedial action? It looks like something was able to browse custom tag files directly; that's when one would normally get that error. However as you say... if a CF server restart made it go away, then poss just CF getting confused. I've not heard of this happening though, and no-one has talked about it in a way that google is aware of though...
d
Thanks for jumping in Adam. Call stack cliffnotes version: 1. Application.cfc.onRequestStart() 2. User.cfc.hasThisKindOfAccess() 3. User.cfc.initPermissions() 4. hiringManagerFunctions.cfc.checkAccess() From there the stack make no sense, methods are on the stack that don't appear to have been invoked by the code, for example from a line that's a cfif involving simple strings. The line that according to the stack calls the actual custom tag doesn't do any such thing, it calls a small method that does a simple query. As you can see from the above, most of the stack is method calls; only the last two stack items are that custom tag. I tried browsing directly to that custom tag, and it did throw that same error. I'll investigate locking those down on principle, but I have no reason to think that was the original problem. The call stack in the original error is totally different, in the direct call case it's just onRequestStart() then the custom tag. We devs didn't repro the error, just saw tons of error emails. The page being hit is used constantly, normally without problems, form and url scopes were empty, no reason we could see why it was suddenly sideways. The error emails kept coming right up until I restarted cf. Doing that was more or less a hail mary, "server seems lost in space, let's try a restart". Errors stopped immediately, no sign of that since, thankfully.