[Seaside] [Glass] WARequestContextNotFound after seaside-flow call:

[Jupiter Jones]

Hi Andreas,

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:

Cheers,

Phil

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 <glass at lists.gemtalksystems.com> 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.
> 
> Cheers, Andreas
> 
>> Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>>:
>> 
>> Hi all
>> 
>> 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
>> 
>> Steps:
>> 
>> 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.
>> 
>> My observations:
>> 
>> --- 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?
>> 
>> Thanks!
>> 
>> Cheers, Andreas
>> 
>> 
>> -----------------------------------------
>> Brot? www.brotrezept.ch <http://www.brotrezept.ch/>!
>> 
>> Andreas Brodbeck
>> Software-Macher
>> mindclue GmbH
>> Dipl. El.-Ing. ETH
>> 
>> +41 55 622 26 24
>> www.mindclue.ch <http://www.mindclue.ch/>
>> -----------------------------------------
>> 
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> 
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20200521/cc5c2847/attachment.html>