[Glass] "502 Bad Gateway" when rendering on an ajax callback

[Mariano Martinez Peck via Glass]

mmmm that could is surrounded with an error handler:

 do: [ :err |
          Transcript
            cr;
            show: 'Error creating WAWalkback: ' , err description. "error
depends upon whether we're using #call:onAnswer: or #call:"


I do a

 grep -r "Error creating WAWalkback" *.log

and I get plenty of entries like this one:

FastCGI_server-9013.log:--transcript--'Error creating WAWalkback:
WAGsInvalidCallbackContext: You can only #call: and #answer: from within a
callback or a Task.'

wtf....



On Fri, Jun 12, 2015 at 10:31 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Just in case it was not clear what I meant...here is attached an example
> of when I properly get the error that happened in a rendering phase but
> with a normal request (not ajax).  A rendering problem (via #replaceWith:
> for example from an ajax #script:) yields a "502 Bad Gateway" from nginx...
>
> Maybe the problem could be around WARemoteDebuggingWalkbackErrorHandler >>
> open:
>
>    self requestContext request isXmlHttpRequest
>             ifTrue: [
>               wb logContinuation: anException description.
>               *(self requestContext responseGenerator internalError:
> anException)*
> *                respond* ]
>
>
> ?
>
> Thanks in advance,
>
>
> On Fri, Jun 12, 2015 at 8:50 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> Hi guys,
>>
>> I am not sure if the problem I have now started with Seaside 3.1.4.1 or
>> not... but I think it does because I don't remember seeing this before. The
>> thing is... when I have an error in a callback of a normal request, then I
>> guess the normal walkback screen with Remote Debug, Full Stack, etc. If I
>> have an error at the RENDERING phase of seaside, then I get the error
>> dialog embedded in the screen in the component that throw the error.
>>
>> My problem is now with ajax. It seems that if I have an error at the ajax
>> callabck, then I get an "502 Bad Gateway". Even worst, if the error was in
>> seaside rendering phase (called from the #script:  via a #replaceWith: or
>> similar), then the whole screen is with the nginx "502 Bad Gateway".  Here
>> I would expect the same as the normal request...that is, the component that
>> go an error get rendered with the error description.
>>
>> The gems do not go down and they seem to be alive. But why I have above
>> behavior?
>> Any idea? I don't know even were to start to debug the problem....
>>
>> The error is logged in the stack AND in the object log. Just the screen
>> is not rendering accordly.
>>
>> thanks in advance for any tip.
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150612/69753aa3/attachment.html>