Getting Bug Reports From Your Blender Add-on's Users

Someone hits an error in your add-on. Today, the paths available to them are: open an issue on a repo they may not know exists, dig up your email from a store listing, post in a Discord you may not read, or — by far the most common — say nothing and uninstall.

None of those get you the traceback. This is the path that does.

What it actually is

Every add-on that's registered and active on Project LEUC can already receive bug reports. There's no separate opt-in, no setting to flip, no code to add — it's the same registration that gives you update notifications and a changelog page. If you can register an add-on, it can receive a report the same afternoon.

What changes is on the reporter's side, and it's genuinely small:

Redaction is not optional, and not just a courtesy

The client-side scrub is a preview so the reporter can see what's about to leave their machine — not the thing that actually protects them. The server runs the identical rule set on every report as it arrives, whatever the client sent. An old copy of the module, a patched one, or someone calling the endpoint directly with curl all get the same treatment.

That matters because you never see:

• Windows or macOS account names in file paths — replaced with a placeholder, path structure kept, so C:\Users\amandeep\...\my_addon\ops.py still reads as a real frame.
• Email addresses, raw IPs, and anything shaped like an API key or personal access token.
• Machine hostnames in UNC paths.

What survives is what makes the report useful: the exception, the stack, your add-on's own file names and line numbers, the detected Blender and add-on versions.

A ping in Discord, not a page you have to remember to check

The dashboard is where you triage, but it is not something you should have to poll. Add a webhook URL to an add-on's settings — Edit → Links → Discord webhook — and every report filed against it posts to that channel as soon as it arrives: the redacted excerpt, the ticket, and whatever version was detected.

It is opt-in and off by default, one webhook per add-on. Get the URL from the target channel's Integrations → Webhooks in Discord; Project LEUC only accepts discord.com/api/webhooks/… URLs, so the field can't be pointed at anything else. If the webhook is missing, revoked, or Discord is having a bad day, the report is still filed and still on your dashboard — the notification is a courtesy, never the thing the report depends on.

What lands in your dashboard

Each report on Bug reports shows the redacted message, the versions detected from the traceback itself where one was found — a typed field is a claim, a traceback is evidence, so the field only fills the gap when detection fails — and contact details only if the reporter chose to leave any. A name, email or Discord tag are all optional; a report is complete without them.

Triage

You set a status on each report:

Status	Meaning
new	Just arrived.
acknowledged	You've seen it.
needs_info	You need more from the reporter. Ask them in the thread.
resolved	Fixed.
rejected	Not a bug, a duplicate, or out of scope.

You can actually ask them a question

The hardest part of an anonymous report used to be the follow-up. You read a traceback, you know exactly which one line of context would settle it, and there was nowhere to ask.

Every report now carries a conversation. You write into it from the report page; the reporter's add-on picks it up on its next poll and shows it inside the same Report a Bug panel they filed from, with a reply box under it. Their answer comes back to your dashboard, and to your Discord channel if you set a webhook up.

Neither side learns anything new about the other. The ticket is the whole address — no account, no email, no handle required in either direction. A reply also moves a needs_info report back to acknowledged, so your queue stops showing it as waiting on someone else.

Duplicates fixed once, not once per reporter

The same crash usually arrives more than once. Merge the reports into one canonical report and every linked ticket starts reading that report's status on its next poll. You triage the bug once; everyone who hit it sees the answer, without you writing the same reply five times.

Conversations stay per-report, deliberately. Merging shares a verdict, never a thread — showing one reporter what another wrote would hand a stranger's words to a stranger.

What this costs a reporter

Nothing they didn't already have. No account creation, no email required, no web form to find. The whole interaction is: copy the error, paste it, optionally hit redact, send. What they get back is a ticket their add-on remembers and checks quietly, the same way it already checks for updates.

What this costs you

Also nothing, in the integration sense — this is the part worth being blunt about. If you're already registered, reports can already reach you. There's no module to install, no endpoint to call, no schema to learn, unless you're building a custom client instead of using the Master Add-on or the drop-in module — in which case the raw /api/report-bug and /api/report-status endpoints are documented and public.

The only real cost is triage time, and that's the point: a report you'd otherwise never receive costs you nothing until you decide it's worth acting on.

Privacy, in one paragraph

A ticket identifies nobody and isn't derived from anything about the reporter's machine — it's a random string, full stop. The status endpoint a reporter's add-on polls returns only the status and your note, never the report body or contact details. Reports themselves are private: visible only to you, never listed publicly, never shared across add-ons.

Related reading

• The Project LEUC Master Add-on
• Add Update Checking to Your Blender Add-on
• Publishing Blender Add-on Updates
• Why Blender Add-ons Don't Update