tracker issue : CF-4204468

select a category, or use search below
(searches all categories and all time range)
Title:

HTTP request erases on-the-fly app mappings on other requests until getApplicationMetadata() is called

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Bradley W. / ()

Created: 05/30/2019

Components: Language

Versions: 2018

Failure Type: Data Corruption

Found In Build/Fixed In Build: Update 3 / CF2016U12,CF2018U5

Priority/Frequency: Normal / Unknown

Locale/System: English / Platforms All

Vote Count: 13

Problem Description:
This is related to https://tracker.adobe.com/#/view/CF-4204404 but I'm creating another ticket since the repro case is a little different here. 

In ColdBox, we use on-the-fly CF mappings for every module that is loaded, but we've had so many issues related to these CF mappings "disappearing" during requests.  I have nailed down a repro case that does not use ColdBox, demonstrating the issue.  Basically, on-the-fly CF mappings will simply disappear as soon as the server gets another HTTP request while the first HTTP request is running.  Calling getApplicationMetadata() prior to trying to using the mapping will make it magically reappear.  

There is one caveat-- this behavior only happens if there is at least one "this.mappings" defined in the Application.cfc.  This issue causes very hard to track errors in ColdBox where mappings will simply not be found, often times during reinitting the framework.  An HTTP request's CF mappings should not be affected by another HTTP request coming in.

Steps to Reproduce:
Unzip the attached file and run "server start" in the folder in CommandBox.  This will spin up an Adobe 2018 server.  The index.cfm will automatically load and you can read the output on the screen and cross reference that to the code to see what is happening.

Actual Result:
Unrelated HTTP requests delete CF mappings on running requests.

Expected Result:
Unrelated HTTP requests should not delete CF mappings on running requests.

Any Workarounds:
Call getApplicationMetadata() EVERY SINGLE TIME you use a CF Mapping, which in reality only narrows the race condition window, it doesn't eliminate it.  Another workaround is to create this.mappings for every single module, which defeats the purpose of ColdBox adding them for you.

Attachments:

Comments:

We have a client that is perplexed with this issue in Adobe 2016. Please make sure the fix is retroactive.
Vote by Luis M.
30853 | May 30, 2019 01:56:59 PM GMT
Another something worth noting is that this specific issue seems to only appear when running the repro case directly in the web root (as in {{webRoot}}/index.cfm). If you run the repro case in a subdirectory of the web root (as in {{webRoot}}/mapping_bug_repro/index.cfm), the problem mentioned in CF-4204404 is still present, but the mapping then seems to persist even after the HTTP request is made. It seems there is a difference in how mappings are treated in the web root vs in subdirectories.
Comment by Jason F.
30852 | May 30, 2019 04:09:43 PM GMT