[Enhancement] Implement retry consuming based on Pulsar message middleware

[HarshSawarkar]

Search before asking

• [X] I had searched in the issues and found no similar issues.

Enhancement Request

This issue aims to implement retry consuming based on Pulsar middleware

Describe the solution you'd like

Implement a retry consuming based on Pulsar

Are you willing to submit PR?

• [X] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct *

[Chuckame]

First, I did not cover everything as I wanted first to agree on the main idea of buffering the calls. It seems that it's ok for you 😄

Secondly, if it's ok for you, I'll focus on the buffering itself, and then refine the public API and namings. I've did the current work quickly to show you the idea.

To finish, thanks for the quick answer 🚀

I'll make some tests to test the different use cases

[pdvrieze]

@Chuckame The buffering is basically correct (I've implemented this for XML for quite some time now)

[Chuckame]

@pdvrieze I've tried with all the possible combinations, and value classes serializers are not directly using encodeInlineElement but encodeSerializableElement that is buffered, which I think it's a bug where encodeInlineElement is never called (see #2738 freshly created).

Let's imagine that this bug doesn't exist, and encodeInlineElement is called as expected, beginStructure call on the inline's encoder is explicitly forbidden or discouraged as said in the docs:

    /**
     * [...]
     *
     * Calling [Encoder.beginStructure] on returned instance leads to an unspecified behavior and, in general, is prohibited.
     */
    public fun encodeInline(descriptor: SerialDescriptor): Encoder

So I would say that this use case shouldn't be handled to follow the docs, as this beginStructure call should be done by the structure's serializer.