Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Provide transient message operations #36

Open
tomkerkhove opened this issue Dec 16, 2019 · 8 comments
Open

Provide transient message operations #36

tomkerkhove opened this issue Dec 16, 2019 · 8 comments
Labels
enhancement New feature or request specs-required All issues where the specifications are still being defined and implementation should be halted
Milestone

Comments

@tomkerkhove
Copy link
Contributor

Provide transient message operations to handle temporary failures when completing a message, etc.

@tomkerkhove tomkerkhove added the enhancement New feature or request label Dec 16, 2019
@stijnmoreels stijnmoreels added this to the v0.2.0 milestone Feb 26, 2020
@stijnmoreels
Copy link
Member

Somre more guidance for this issue is proparly required. What is considered a 'temporary failure'? How should it be handled?

The message pump has now something of a handling logic, but it's in my opninion a bit too high-level to be useful.

@stijnmoreels stijnmoreels added the specs-required All issues where the specifications are still being defined and implementation should be halted label Apr 23, 2020
@tomkerkhove tomkerkhove modified the milestones: v0.2.0, v0.3.0 Aug 24, 2020
@tomkerkhove tomkerkhove modified the milestones: v0.3.0, v0.5.0 Sep 18, 2020
@tomkerkhove tomkerkhove modified the milestones: v0.5.0, v0.6.0 Sep 28, 2020
@tomkerkhove tomkerkhove modified the milestones: v0.6.0, v0.7.0 Oct 16, 2020
@tomkerkhove
Copy link
Contributor Author

When we want to complete the message in a handler and it fails with Server too busy or time out, that we retry it x times

@stijnmoreels
Copy link
Member

stijnmoreels commented Dec 22, 2020

OK, cool, after #141 is done, we can maybe create some options a consumer can configure on the message router.

@stijnmoreels
Copy link
Member

stijnmoreels commented Dec 31, 2020

Except of course if you mean the RetryPolicy on the MessageReceiver (and in the future ServiceBusReceiver); in that case it can be a set of values configured on the options of the message pump.
This is again something that we may want to hold off until we've migrated to these new types.

@tomkerkhove
Copy link
Contributor Author

Adding retry on operations such as deadletter, etc would be enough indeed; but would need to be opt-in/out indeed with configurable retry count/wait time

@stijnmoreels
Copy link
Member

stijnmoreels commented Aug 16, 2021

Can we use the ServiceBusRetryOptions for this?

@tomkerkhove
Copy link
Contributor Author

Fine by me

@stijnmoreels stijnmoreels modified the milestones: v1.1.0, v1.2.0 Feb 9, 2022
@stijnmoreels stijnmoreels modified the milestones: v1.2.0, v1.3.0 Mar 31, 2022
@stijnmoreels stijnmoreels modified the milestones: v1.3.0, v1.4.0 Sep 12, 2022
@stijnmoreels
Copy link
Member

By default, the ServiceBusClient has a exponential retry with a time-out of 1min and max retry of 3.

@stijnmoreels stijnmoreels modified the milestones: v2.1.0, v2.2.0 Feb 13, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request specs-required All issues where the specifications are still being defined and implementation should be halted
Projects
None yet
Development

No branches or pull requests

2 participants