[Vortex] vortex_frame_is_error_message generating scary warning

[Francis Brosnan Blazquez]

Hi Jens,

> My client is calling vortex_frame_is_error_message( ) on frames it  
> receives, to check for errors and get the error messages. However, if  
> logging is turned on, and the frame is a normal reply instead of an  
> error, a rather scary message gets logged:
> 
> (proc 22466): (critical) vortex-channel: unable to parse err reply, we  
> have a buggy remote peer: Error found (stream size: 11, at byte 6  
> (global index: 5), near to ...Hello There..., while reading: There):  
> Parse error while reading a node being opened
> 
> This is coming from vortex_channel_validate_err (vortex_channel.c: 
> 3478). This function seems to assume that the frame given to it is an  
> error, and tries to parse the contents as a BEEP XML error document,  
> printing the above warning if it won't parse. But the docs for  
> vortex_frame_is_error_message imply it can be called on any frame,  
> whether or not it's an error: "Allows to check if the given frame  
> contains an error message inside the frame payload".
> 
> Is the problem in the documentation or the code? That is, should  
> vortex_frame_is_error_message be documented as working only on error  
> frames, or should the implementation check the frame type first and  
> quickly return false if it's not an error frame?

It is a documentation problem. The function must advice this is a
profile development function that expect a BEEP error message to be
parsed. In fact, the function returns false if such message were not
found. I've updated the documentation.

As a detail to mention, not all profiles uses the BEEP error message to
implement its error reporting. Some of them uses the MSG/RPY pattern,
including in the RPY body the application level error message. 

That's why this function, as you point, must only be used to implement
profiles that uses the standard, channel 0, BEEP error message.

> Also, a related doc issue: The docs for vortex_frame_is_error_message  
> should point out that the 'code' and 'message' strings it returns were  
> allocated from the heap and need to be freed by the caller after it's  
> done with them.

You are right. It is also updated the documentation to advice the
references returned must be deallocated by calling to axl_free when no
longer needed.

Thanks for reporting Jens!

> --Jens
> 
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.