We have been trying to track down a strange bug fo...
# box-products
b
We have been trying to track down a strange bug for a while and I believe it is Coldbox that is causing it. We are using Coldbox with a Legacy application based on this example repo: https://github.com/bdw429s/coldbox-legacy-app-demo It has been in place for years but occasionally we get errors where session variables that are supposed to exist don't, it seems like any session variables we set ourselves get wiped out. I created a repo that seems to reproduce the error we are having. https://github.com/Yamaha32088/ColdboxSessionError You will need a Redis instance for this to work. The steps to reproduce after booting up the server would be to make requests to the
test.cfm
page and you will notice that every once in a while the variable
trackingId
disappears, it seems to be random. Sometimes it will exists for several sequential requests and then it will disappear. If however you comment out line 59 inside of
Application.cfc
the variables seem to be kept every request.
d
I'm probably slipping some sort of gear, but how can sessions be maintained without cookies?
b
They are not supposed to be maintained in this case.
The session only exists as long as the request lives
d
But you're seeing that part way through the request, sometimes your explicitly set session vars don't exist? Can you tell if the whole session scope is empty, or if it's only some particular vars that are gone? Any chance this gets triggered when some other request hit that same session? Just guessing here, but is this about simulating sessionless bot requests?
b
Yes the session variables that are set inside of
onRequestStart
and
onSessionStart
get lost part way through the request. It will happen regardless if there are several concurrent requests or just a single request. When the problem occurs the session scope looks like a brand new session before any of our session variables were set. The CFID is exactly the same though. It is like the session is getting completely reset part way through the request with the initial session variables from when the session was first created.
d
Are they there if you check them immediately after they get set?
b
Yes
From what I can tell it looks like Coldbox is calling
application action='update' mappings='#newMappings#';
inside of LuceeMappingHelper.cfc and they are lost after that call is made
They aren't lost every time though
It also seems like it is calling
application action='update' mappings='#newMappings#';
on every single request which seems bad in my opinion
even though part of it was fixed in this ticket https://luceeserver.atlassian.net/browse/LDEV-2555
I've created this ticket since it seems to be related to Lucee https://luceeserver.atlassian.net/browse/LDEV-4408
I would think you would be able to compare mappings in Coldbox and only execute the
application action='update'
function if the mappings are different, Is there a reason it has to execute on every request?