[coldbox 4.3.0] prc scope variable leaking across users

I was hesitant to post this as this app uses a very old version of Coldbox (pretty much all our other apps are 5.x but this one still lags) but in searching for the “why” it’s happening I’m not getting anywhere and when I open up the seemingly pertinent sections of Coldbox 4.3 and the latest 5.x version I’m not seeing anything in files where the below is referenced that would show me that the behavior would definitely be different now. This is an old app for unemployment compensation claim processing that unfortunately has now seen a spike in use.

So, first an image of the issue -

In the right hand body I am pulling claims for a person as described below and then using same query to populate a portion of the left hand nav on same page. Note there are two prior claims shown on the right while there are four on the left nav even though supposedly using the same query result (not rerun query but same query result - passed to nav). The right hand portion is proper but the results on the left nav are for an entirely different person that was being worked on at that time by another user in our claims dept. The details of process are -

Claims recordset built and returned to handler as so -

[in handler event]
var strViewData.rsClaimList = {get claim info from model}

…a couple other items added to strViewData struct.

The view is then called with (view=“blah”, args=strViewData).
This view populates fine.
The layout for this view runs a separate event to build left nav info like so - #runevent(“layout.claimmenu”)#

The layout event builds some nav data based on the user rights of the logged in person (but doesn’t touch any claim specific data).

This then gets sent to views/nav/leftnav.cfm

In leftnav.cfm I have -

<cfif structKeyExists(prc.currentViewArgs,“rsClaimsList”)> <!— is rsClaimsList query in my struct passed to primary view via “args=” ? —>

{ display in left nav menu data }

Again, what’s displaying using this code snippet is a value from an entirely different app user working on a different claim/person.

In shorthand -

add recordset to local struct in handler event
pass local struct to view with “args=strViewData” in event.setview()
use layout that calls new event “layout.claimmenu” to get some nav info based on user (BUT NOT TOUCHING THIS CLAIM RECORD - STRICTLY GENERIC NAV ITEMS BASED ON USER RIGHTS) .
layout event calls nav view for left hand portion of page
nav view cfm checks if we have claim data (rsClaimsList) waiting for us in prc.currentViewArgs via cfif above
If yes loop thru and display using prc.currentViewArgs.rsClaimsList
This rsClaimsList is DIFFERENT in this instance than the one that got built in primary handler in same overall event and is from work being done by some other user who happened to be logged in and working in app at the same time.

Again. I know this is 4.3 but in trying to track down I thought I’d do a Beyond Compare to see if something changed in relevant portion using latest 5.x. I’m just not finding anything that different where currentViewArgs is concerned.

Solution for now.

To alleviate this (I hope) I’ve switched that claims recordset in original claims event to be prc scope directly rather than a local scope passed to view via args=…
In the left nav I now do if structkeyexists(prc,“rsClaimsList”) and go from there.

Still, this doesn’t tell me how that recordset got leaked between logged in users using the other method.

Lastly, I’m wondering if calling new event from layout for nav data (#runevent(“layout.claimmenu”)#) had anything to do with it? Sure seems like wouldn’t but…

Thank you!

screenshot attached

It’s sort of impossible for the actual prc or rc structs to be shared between two users as they are ultimately stored in the requestContext object which is stashed in the “request” scope. That said, I’ve seen many people run into issues like yours due to lack of var scoping or misuse of singletons in their codebase. Without seeing the full codebase, it’s hard to say where your issue is. I can only recommend you track every variable that holds this data and ensure everything is var scoped, including cfquery variables.

The singleton leak detector on ForgeBox may help you find variable that aren’t var scoped plus a simple load test will usually help tease out concurrency bugs.