kyrylo / airbrake-rust

WIP

Hey there 👋

I've had my fair share of ups and downs in the professional world. Getting laid off not once, but twice within a few months was a wake-up call. It made me realize that I want to be the captain of my own ship.

I am hacking on these projects:

• 🐛 Telebugs · track errors
• 🏳️ Flag Match · learn flags
• ☕️ Coffee World Rush · drink coffee
• 🍵 Matcharoo · learn words

I post on X daily about my journey: @kyrylosilin

airbrake-rust's Issues

Notification retry feature idea

Hi @kyrylo
I'm using Airbrake-Rust in an environment with really bad network connection, so I'm in a desperate need of a new feature to reliably send error notifications. I'm thinking about adding a "retry" feature with some configurable timeouts and number of maximum retries.
Before implementing something this big I would like to get your feedback on the idea and discuss the implementation details.

A: We will definitely need better error handling in the lib to determine if a notice was sent successfully or not. I've tried to add a simple boilerplate Error type with the error_chain! macro, and replace every unwrap() in SyncSender::send() with a try!(). It works fine, except for the serde_json::from_str call, which has some extra requirements which I couldn't handle, but I will look into it a bit more.
Do you mind changing the notify_sync function to return a Result instead a Value? I hope it's not a problem, after all if a developer wants to block the app while the notification is beeing sent, he would probably want to know if it was successfull or not (and also don't want his program to die in case of an unexpected response of course)

B: Where should I put the retry logic? I think AsyncSender could have the same retry functionality, because it basically includes a SyncSender in a separate thread, so that thread can also do the retry thing, even if we discard the final results after a given number of failures. So maybe we can have a simple wrapper type for SyncSender which contains the retry logic and the related params. Then the AsyncSender worker should decide if a simple SyncSender or a new Retry Sender should be created based on the config params. In this case the Notifier would have 3 senders, Sync, RetrySync and Async.
The other option is to not separate this, and make the SyncSender smarter by adding the retry logic to the send() function. I mean it gets the whole config in the constructor, so it can easily decide itself if any retries are needed. This way the whole structure can be the same, and we only have to add some new optional config params.
Both methods are backward compatible with the API.

project_id should be String

Please modify the project_id to be a String. I am planning to use this lib with ErrBit, but it has hexadecimal project IDs so I can't set it. The ID is only used to construct the request URL as far as I know, so it should not really matter and it would make this lib more universally usable.

Thanks
Sándor

Roadmap to a stable release?

The readme recommends against using this project in production until it reaches 1.0. Is there a roadmap or list of remaining work needed before a stable 1.0 release can be cut?

Why is the notifier module private?

I would like to create a central instance of the Airbrake notifier but the Notifier type is in the notifier module, which is private. This way I can't pass around the configured Notifier object, because I can't define the type for the function params and such.
Is there a reason why this type is private? I would think that a value returned by the a public function of the lib should have a type which is also public.