Skip to content
New issue

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

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

Already on GitHub? Sign in 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
Projects
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
@tomkerkhove tomkerkhove added this to To do in Roadmap via automation Dec 18, 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 added this to the v2.1.0 milestone Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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
Roadmap
  
To do
Development

No branches or pull requests

2 participants