Yeah I think that’ll work! But I was thinking about going further and support attaching multiple handlers with different configuration. Say, we want to post to different channels based on domain. We can define 2 handlers with different info_channel_id and create a handler filter that would only keep messages with that domain. This setup would require handler and it’s downstream code to rely on its own configuration and not reading from the global configuration.
martosaur
0
MRdotB
Regarding the logger handler, I see some improvements that could be made.
- Add the Ability to Pass a Module Function: Allow passing a module function that receives the
errororinfomessage, enabling you to dispatch logs dynamically. The routing function would process the metadata and dispatch the log accordingly.
Example:
Logger.info("✨ New User #{customer.email} created successfully.", channel: "accounts")
Logger.info("💸 Payment of 5 € succeeded from customer `#{customer.email}`", channel: "billing")
-
Support for Occurrences: This could also be extended to handle occurrences, but it would require extra work since the current ETS table for fingerprint only supports a single Discord channel.
-
Behavior for Routing: DiscoLog could ship with a
Behaviorto implement this feature. Additionally, the Discord client functions should be exposed.
With these improvements, I don’t see a use case for running multiple logger handlers ?
0
martosaur
To be clear, this is an imaginary use case, I just used it as an example meant to illustrate where configurability of the current design may come short. I have no doubt that with enough configuration options DiscoLog can cover pretty much any use case in the near future and perhaps for the time being.
Changes to configuration I’m talking about is for the love of the game, really. It would just be awesome if DiscoLog could play nicely with existing logging and application configuration. Following up with Oban example, there is a single place where Oban reads configuration and this is what unlocks independent Oban instances. As I mentioned, this isn’t necessary or anything, I just think it would be neat, so don’t feel pushed to agree or even consider this!
0
MRdotB
v1.0.0 Released!
I’m excited to announce the release of DiscoLog v1.0.0! This update introduces two optional features:
- Presence Status – Allows your bot to appear online, representing your node in Discord.
- Go To Repo – Provides a direct link to GitHub (or a similar platform) to check the code where an error was triggered.
Additionally, it’s now possible to use the Discord client for ad hoc usage, though examples are not yet available.
New Demo: I’ve created a YouTube video showcasing the Presence Status and Go To Repo features
Huge thanks to @martosaur for implementing the Presence Status feature and refactoring the code to support ad hoc usage
4
KristerV
the value this library brings is the amazing integration with Discord. not how you capture errors. so in an ideal world i would collect errors with Tower and send errors to Discord, Sentry and whatever other service.
But I get it. It’s easier to do a quick fully supported library than figuring out how Tower works.
0
MRdotB
If you want Tower to support Discord, feel free to implement tower_discord. Given the overlap in functionality, integrating Tower with disco_log doesn’t make sense. You’re better off using Tower events with a thin Discord client. Feel free to borrow ideas from disco_log, especially the occurrence channel implementation.
0