Open igorsantos07 opened 4 years ago
Ok, while still trying to find a way to solve my need (which seems to be a race condition between writing to and deleting the whole debugbar session array), I noticed getStackedData()
does use the storage. I would suggest looping over array_keys($stackedData)
to make it clear you're only using its keys :))
I'll edit the original post to reflect my updated findings.
It seems there's a race condition when you try to use stacked data to debug embedded requests (i.e. iframes).
I can confirm what the doc says about "using the debug bar storage mechanism to store the data and re-open it later can be cumbersome". It doesn't seem easy to debug embedded docs simply using header data because the ID generated is different. Thus, I moved to a less-optimal but still doable solution with stacked data. However, that brings up another issue: the race condition between the main request persisting the session, and the embedded one writing to it.
I guess this could be solved if session was not used whatsoever for stacked information - i.e. Redis storage is able to append information without having to write the entire list (and creating the said race). Or else, if it was possible to easily pass-down the DebugBar request ID - no idea about this without munging embedded URLs, though, but I guess it happens with AJAX requests
AjaxHandler.handle()
?Entirely replacing the session layer could probably work if there were some adjustments on the stack data code - i.e. deleting each used key instead of clearing up the entire object. I think DebugBar should come with a basic session replacer for itself, as it would otherwise be dependent on external implementation in order to solve this race condition.
stackData()
is not really storing the stack in the storage?~ couldn't really double-check this but I guess it's working finesetStackAlwaysUseSessionStorage()
doesn't seem to be documented