Closed Levyks closed 5 months ago
As a workaround, I thought about just receiving a generic Body<Value>
and dealing with the deserialization myself, but I couldn't figure out how to turn that into a MyMessage
enum after that, since apparently serde_amp
only implements a from_reader
and a from_slice
[serde(tag = "t", content = "c")]
Most of these serde tags are targeted at JSON and a lot of them don't make sense for other encoding (including AMQP). There's a high chance that the decoding error is caused by these tags.
Would it be possible to implement an auto-reject option to deal with this case? Or maybe just include the DeliveryInfo inside the error?
Good idea. I prefer the latter option but it would require a breaking release. A better way might be allowing user to set a handler function/closure that has access to the receiver and delivery info. I'll give this a try.
but I couldn't figure out how to turn that into a MyMessage enum after that
serde_amqp
has this method from_value
https://docs.rs/serde_amqp/latest/serde_amqp/fn.from_value.html
Most of these serde tags are targeted at JSON and a lot of them don't make sense for other encoding (including AMQP). There's a high chance that the decoding error is caused by these tags.
It works fine if I send it with an enum variant that actually exists, I just left it there as an example as that is how I'm using it in my project, it has some JSON interop.
serde_amqp
has this methodfrom_value
https://docs.rs/serde_amqp/latest/serde_amqp/fn.from_value.html
I totally missed that somehow, I guess I will be able to use the workaround I mentioned then, thanks
The message decode error now carries the delivery info in 0.10.0 https://docs.rs/fe2o3-amqp/0.10.0/fe2o3_amqp/link/enum.RecvError.html#variant.MessageDecode
@Levyks Would you consider this issue resolved?
yeah, sorry for not closing it
I've noticed that, when implementing something like the example below:
If I send something like this in that receiver's queue
I get a
MessageDecodeError
, which makes sense, however, the message is not rejected after it, and the error itself does not provide theDeliveryInfo
necessary for me to do it myself, making the message be stuck asdelivering
in the queue until the connection is dropped.Would it be possible to implement an
auto-reject
option to deal with this case? Or maybe just include theDeliveryInfo
inside the error?I haven't checked all the variants of the
RecvError
enum, but maybe there's a chance of that happening in other cases as well?