Error in AbstractFlashScope: key does't exists due to race conditions

Description

coldbox\system\web\flash\AbstractFlashScope.cfc:

MESSAGE: key [NAME] doesn't exist (existing keysostalcode)

88: for(x=1; x lte scopeKeysLen; x++){
89: // check if purging and remove
90: if( structKeyExists(scope, scopeKeys[x]) AND scope[ scopeKeys[x] ].autoPurge ){
91: structDelete(scope, scopeKeys[x]);
92: }

In most cases it happens where multiple ajax request are started simultaneously. Maybe some locking needs to be employed to ensure only one thread does the purge at a time.

Activity

Show:
Luis Majano
March 8, 2016, 1:21 AM

Oops it auto resolved. Can you just check this Henry in 4.0

Brad Wood
September 19, 2017, 5:38 PM
Edited

This is being reported by on Slack as still happening in ColdBox 4.3. Looking at the code it seems the inflateFlash() method needs to provide locking to ensure consistency. It stands to reason that two threads on the same session hitting the server at the same time would both try to inflate the same flash to their rc, and the first one to get there would cause the second thread to throw errors once it started wiping out the flash scope variable while the other thread was still trying to read them. This code has several places where it checks if the flash exists and then proceeds to use it even though the flash scope could have been removed in the meantime. Also, the code several times gets a list of keys in the flash scope first and then loops over them to process, but the keys can be removed in the meantime. I think we need to add locking to the entire inflateFlash() function so it can't be run more than once for the same user. The main trick is how we name the lock since the concrete flash provider gets to decide how it uniquely identifies the flash storage meaning we can't assume it's tied to the session scope. Furthermore, we can't easily push the locking down to the concrete classes as much of the logic that needs to be kep threadsafe is in the abstract class so the locking needs to encompass that as well.

Brad Wood
September 19, 2017, 5:40 PM

Note, my suggestions above would not address 's concerns which is that he does not want the next request that happens to come into the framework that "grab" the flash scope. Not sure how to handle that since the flash storage isn't really sware of the event that's being redirected to (or if it's even part of an event redirection).

Luis Majano
November 8, 2019, 5:18 PM

Feels good to close such an old ticket! Sorry on the delay on this.

Samuel W. Knowlton
November 8, 2019, 6:14 PM

We’ve patched this into 5.6.2 locally. Thanks for the quick turnaround (for us!)

Assignee

Luis Majano

Reporter

Jamie Salvatori

Labels

None

Components

Fix versions

Affects versions

Priority

Major
Configure