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

[Mariano Martinez Peck via Glass]

mmmmmm I think that what I thought it was ajax was plain requests (that
would explain why I didn't see this very frequent) and I may have problems
in this particular component with #children or #states or whatever...

sorry, I will try this before continue.

cheers,

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

> 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
>



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