500 was just fine when I was still calibrating the envelope parsing, but AFAICT it's
correct now, so I'd rather not get notified about 'remaining problems' (which are SDK problems)
Facilitate visual comparison with the 'reference impl' (slack).
The service backends do heavy copy/pasting, good to keep the beast
in check by at least limiting the changes to the bits that actually
diverge
W.r.t. the user-contributed version, this:
* removes commented-out code
* removes channels (not supported at the UI level)
* removes all other things
Said differently: the mattermost Alert Service Backend is simply the Slack version
with edits to make it mattermost-specific (and nothing else).
(In a few places I've edited the slack backend to make comparing easier).
Fix#277
See #253
I had someone run into this on hosted Bugsink; couldn't reproduce it.
Thought I fixed it in e8fb9556f7 (specific to the Chinese translation)
but appararently there's other ways to reach this point.
No matter, just create a version of the yesno filter that's not sensitive
to any future mistranslation.
i.e. running this:
```
python manage.py tailwind update
python manage.py tailwind build
```
prompted by:
https://github.com/advisories/GHSA-5j98-mcp5-4vw2
not (likely to be) affecting us (since this is for local builds only)
but might as well run the update to get rid of the warning the proper
way.
this code was created in a REPL/ChatGPT/minidump-API/HITL session,
until I had something that "seemed to work". the present commit
is the result of rereading, refactoring for understanding etc.
it's not "pure refacting" in the sense that it's behavior-changing,
but AFAICT for the better. e.g. "line 0" => just leave that out and
many similar changes.
(the now-removed 'treat as pid' was hallunicated by the bot; the
taken-from-sentry version missed the guard against -1)
> The index of the thread that requested a dump be written in the
> threads vector. [..] If the dump was not produced as a result of an exception
> [..] this field will be set to -1,
