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

[RFC] Plugin Feedback API #2172

Open
KazWolfe opened this issue Jan 20, 2025 · 3 comments
Open

[RFC] Plugin Feedback API #2172

KazWolfe opened this issue Jan 20, 2025 · 3 comments

Comments

@KazWolfe
Copy link
Member

KazWolfe commented Jan 20, 2025

RFC-lite/tracker for the following changes:

  • Implement a new BugBait service so that plugins may attach their own data to feedback requests. This would be useful for, e.g., providing snippets of configuration or other settings when feedback is sent. The user should be able to disable submitting plugin-provided metadata alongside their feedback.
    • Ideally, plugins would return a string containing a JSON blob of the most relevant information.
    • This string should be no longer than 1024 characters to comply with Discord embed limits. Any trimming will happen server-side.
    • This will (obviously) not be called for plugins that are unloaded or errored.
  • Implement a better log filter to show the last exception raised by that specific plugin.
    • Serilog already should know which plugin any given log line comes from, so we can track LastException on a per-plugin basis.
  • Change BugBait URL to https://api.dalamud.dev/feedback (TBD) hosting new bugbait.
@nathanctech
Copy link

Would allowing the use of file attachments (for text, at least) for information exceeding the limit be considered? Since Serilog is aware of the plugin, it might be useful for plugin devs to have relevant log output for the plugin itself when feedback is submitted. The user sending feedback could have a button to attach plugin logs. Of course, for privacy reasons only the plugin-scoped logs should be included.

@KazWolfe
Copy link
Member Author

I'm not opposed to the idea, though I do worry that that'll just make a lot of noise given plugin logs can be relatively big. It'd definitely be a larger shift and not something I want to target in the initial feedback improvements.

@nathanctech
Copy link

Makes sense, something to look at down the line if the 1024 characters isn't enough. Discord does allow multiple fields (~8000 character total payload for the embed, 1024 characters per field, as noted) if a dev needed more, but that should be enough for most cases, I'd think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants