[Glass] WARequestContextNotFound after seaside-flow call:

Dale Henrichs dale.henrichs at gemtalksystems.com
Thu May 21 08:28:40 PDT 2020


Andreas,

Sorry for not responding yesterday, I must have missed your original 
email ... it seems that you may have found a hole in the unit test 
coverage ... I will look into this today ...

Dale

[1] https://travis-ci.org/github/SeasideSt/Seaside/jobs/687736206

On 5/21/20 1:52 AM, Brodbeck Andreas via Glass 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: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20200521/e5ca97bf/attachment-0001.htm>


More information about the Glass mailing list