[Glass] WARequestContextNotFound after seaside-flow call:

Thu May 21 07:55:53 PDT 2020

Hi Andreas,

Would it be possible to provide a repeatable scenario so I can take a look?
Perhaps report it via https://github.com/SeasideSt/Seaside/issues <https://github.com/SeasideSt/Seaside/issues> and give a pointer to it here (to remind me)?

The fact that Processor activeProcess changes reminds me of https://github.com/GsDevKit/Seaside31/issues/71 <https://github.com/GsDevKit/Seaside31/issues/71> (mind this is an issue in the ‘old’ Seaside 3.1 repo for Gemstone, the current version is on the https://github.com/SeasideSt/Seaside/ <https://github.com/SeasideSt/Seaside/> repo).

And indeed we moved the implementation of WADynamicVariable to GRDynamicVariable in Grease etc…but afaik call/answer should work as before.
So, a repeatable case would be helpful to dive into this.

best
Johan

> On 21 May 2020, at 14:29, Brodbeck Andreas via Glass <glass at lists.gemtalksystems.com> wrote:
> 
> Hi Phil
> 
> In the meantime I figured out, that the problem was introduced between Seaside v3.2.5 and v3.3.0. call:/answer works OK with Seaside v3.2.5
> 
> They have changed the platform specific implementation of WADynamicVariable (which WACurrentRequestContext is a subclass of). On GemStone this is now a subclass of GemStone's own DynamicVariable class, which in turn uses "Processor activeProcess environment at:" to get the value of the dynamic variable.
> 
> I managed to figure out, that the "Processor activeProcess" changes after call:/answer and therefore the environment is blank and the current request context is gone, obviously. I don't know at which point the activeProcess is changed. But my guess is somewhere around GemServer?
> 
> I keep investigating. Looking forward for hints from GemStone staff! ;-)
> 
> Cheers, Andreas 
> 
>> Am 21.05.2020 um 13:54 schrieb Jupiter Jones <jupiter.jones at mail.com <mailto:jupiter.jones at mail.com>>:
>> 
>> 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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20200521/f9e49035/attachment-0001.htm>