Re: [Glass] WARequestContextNotFound after seaside-flow call:
I use call:onAnswer: a lot and just changed a couple of them to call: just to see… and had the same issue.
Seaside is installed from the main Seaside repo on Github in GemStone 3.5.1.
Without a debugger it’s not easy to pinpoint but a quick look at the log and the various call: methods, it does look like there’s something going on with GRPlatform current seasideSuspendFlowDo:
Had the same issue with #wait: …as would be expected if the issue is in GRPlatform current seasideSuspendFlowDo:
PS Copied this message to the Seaside list just in case someone there has seen this before.
On 21 May 2020, at 6:52 pm, Brodbeck Andreas via Glass <[hidden email]> wrote:
Additional astonishing observation: In a plain installation without any code from mine the WAFlowFunctionalTest fails! (GemStone 3.4.5, latest Seaside, latest GsDevKit, Platform Linux)
(I previously reported "all tests green" but that did not include the functional tests ...)
Since this would be a bug at the heart of seaside, I doubt my observations. I will investigate some more.
Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <[hidden email]>:
I have a stubborn "bug" or other creature which I can not catch after days of trying my best... Before I will eventually file a bug report, may I ask you if this problem sounds familiar to someone?
Bug summary: Exception WARequestContextNotFound after seaside's call/answer
1. I have a seaside application running in GemStone 3.4.5, latest Seaside, latest GsDevKit. 2. From the main seaside UI-component I simply open another seaside component with seaside's call: method. 3. I press the "close" UI-button, which calls seaside's answer method of that component. 4. I get a WARequestContextNotFound exception.
--- Bug DOES NOT show up, if I use call:onAnswer: instead of call:. So it probably narrows down to the usage of GRPlatform current seasideSuspendFlowDo:, since that is what call: is using to suspend the flow with continuations.
--- Seaside's error handling will in turn fail itself because it also relies on calling current requestContext itself. Only a simple text based stack is placed on GemStone's ObjectLog. And the browser just shows a simple "Internal Error:"
--- WACurrentRequestContext is a WADynamicVariable and as such uses the environment dictionary of the active GsProcess (via something like this: Processor activeProcess environment at: WACurrentRequestContext). With stupid pseudo debugging (since I can't get a real debugger to work) I figured out, that after call:/answer the GsProcess changes and starts with an empty environment, therefore missing the WACurrentRequestContext.
--- Seaside tests all green
I'm really exhausted. Any clues or similar experiences?