[
https://issues.apache.org/jira/browse/PROTON-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921735#comment-17921735
]
Pete Fawcett commented on PROTON-2531:
--------------------------------------
I have encountered a problem as a result of the issue described in this ticket.
I have a Python client which processes messages received from a Qpid broker
(The C++ one) As part of the processing I read the tag from the incoming
delivery so that I can do asynchronous acknowledgement of messages when the
local processing has completed.
When I tried to use this client with version 0.40.0, I started getting
exceptions thrown when reading the tag from some deliveries.
({{{}UnicodeDecodeError{}}})
The problem is that {{pn_delivery_tag}} is converting the received bytes into a
{{str}} using "utf-8" decoding. The tag in the delivery from the Qpid broker is
arbitrary bytes and so may not be valid UTF-8. (Actually, the tag looks to be a
big-endian representation of a 32-bit integer sequence number, so the exception
gets thrown when the 128th message is received.)
The current unit tests do not show up the problem because, from what I can see,
the tag values used are all ANSI characters (i.e. < 128), even when testing
with bytes. Also, since the Python bindings are being used at 'both ends' of
the test the bytes in the tag are always valid UTF-8 when set via a string.
I am working on a PR to fix this issue.
>From one point of view I would prefer to change the return type of {{tag}} to
>be {{bytes}} but I don't think this is feasible. So I am suggesting two
>possible fixes.
[~astitcher], you make the point that the type annotations are not necessarily
binding, but the problem I see is that the current {{tag}} property does
actually return a string. If it was changed to {{bytes}} then it would break
existing client code.
My first fix is to use {{raw_unicode_escape}} when encoding/decoding between
{{str}} and {{{}bytes{}}}. This seems to work for all byte values (0x00 - 0xFF).
The second fix is to follow the suggestion earlier in this ticket and implement
a {{btag}} property and matching {{pn_delivery_btag()}} function to return the
actual bytes received - and avoid all that tedious mucking about in codecs.
Any thoughts on which fix might be preferable? (Both could be included)
Code is currently in
[pjfawcett/qpid-proton|https://github.com/apache/qpid-proton/compare/main...pjfawcett:qpid-proton:PROTON-2531]
but I haven't submitted a PR yet, partly because I am adding some more tests.
Also, can this ticket be assigned to me?
Thanks
> Delivery tag is str while it should be bytes
> --------------------------------------------
>
> Key: PROTON-2531
> URL: https://issues.apache.org/jira/browse/PROTON-2531
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Reporter: Ievgen Popovych
> Priority: Major
>
> According to AMQP standard delivery tag is ??up to 32 octets of binary
> data??. Proton C library also has it in binary format.
> But in the Python binding {{Delivery.tag}} is a string, which causes issues
> when trying to use it (i.e. print/visualize).
> As far as I understand this is down to Swig {{python/cproton.i}}
> {{wrap_pn_delivery_tag}} (since typemap for {{pn_delivery_tag_t}} seems to be
> correct)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
