33ed3242c2
Fix browser.version tag-deduction
2025-03-03 10:54:17 +01:00
00c49443eb
Add 'mostly_unique' property to tags
2025-03-03 10:52:28 +01:00
1b9a76bc17
Add comment about counting tags occurrences
2025-03-03 09:41:00 +01:00
7a30de3840
Issue Tags: select_related
2025-02-28 10:09:53 +01:00
60e25dac42
Issue Tags display: 'Other', sorting (WIP)
2025-02-28 09:48:01 +01:00
2c444c6e80
Display Issue (not event) tags in the RHS detail; WIP
2025-02-28 09:33:58 +01:00
f7e85b788c
Tags: count at issue-level (model impl. only)
2025-02-27 21:58:14 +01:00
4404538893
Storing tags in the DB: use bulk_create; a few tests
2025-02-27 20:41:36 +01:00
89d53a15c9
digest_tags: just use project_id to avoid lookups
...
maybe maybe the passed-in event also avoids this, but the present
method will always do what you expect and this is obvious upon
reading, rather than have the reader think about something
2025-02-27 16:21:29 +01:00
0d4d95defd
Use .iterator() idiom in init_tags
...
to avoid loading all events into memory before looping over them
There's some warnings in the docs about SQLite and iterators, but
I don't think those apply, for one because we don't write to the
events: https://docs.djangoproject.com/en/5.1/ref/databases/#sqlite-isolation
2025-02-27 14:54:26 +01:00
ab961d81c1
init_tags: interruptable; show progress
2025-02-27 14:35:59 +01:00
0aa067eb9b
Add --fresh-trace and --tag params to send_json/stress_test
2025-02-27 14:04:52 +01:00
5f1d5832d1
Add 'init_tags' command
2025-02-27 13:36:17 +01:00
ef3b19d794
UI: Specific 'no issues found' when searching
2025-02-27 13:18:33 +01:00
7a19e2d277
Tags; deducing tags; search on tags; WIP
2025-02-27 13:12:49 +01:00
4b7ed8f4ec
Rename get_contexts_enriched_with_ua
...
more closely match what's going on
2025-02-26 18:20:52 +01:00
348c2dc80f
tox.ini rule, as per comment
...
the associated code got removed before checkin, but I still like to ignore this
rule in the future
2025-02-26 16:34:47 +01:00
70a26ebb0f
Typo in changelog
2025-02-24 11:40:10 +01:00
e876944d42
Add note to 1.3.0 CHANGELOG
2025-02-20 22:07:54 +01:00
14d34807ca
Snappea 'worker done': display task name
...
for the important case of 'quickly eye-balling what-took-you-so-long'
this saves those eye-balls a lookup
2025-02-20 21:38:14 +01:00
f6b2c8ffbf
1.3.0 CHANGELOG
2025-02-20 21:27:19 +01:00
af58c8174a
QuietConsoleEmailBackend: prettier printing
...
message more clear, subject on a single line
2025-02-20 15:46:59 +01:00
757ee31bed
Support for CORS
...
Tested in-browser with:
```
function main() {
$.ajax({
type: "POST",
url: "http://bugsink:8000/api/1/store/ ",
headers: {
"Content-Type": "application/json",
"X-Sentry-Auth": "Sentry sentry_key=a2df4cd647dc4b7a8a81b78a3601eba1, sentry_version=7, sentry_client=bugsink/0.0.1",
},
data: JSON.stringify({foo: "Bar"}),
success: function(data) {
console.log(data);
}
});
}
```
2025-02-20 14:43:10 +01:00
2354241e2c
2 email backend warning improvements
...
*,Don't mention EMAIL_BACKEND in the warning message: in the
Docker setup, this isn't even a thing.
* In the single-server setup, when email is unconfigured, use
an explict Quiet backend. This will make sure you don't just
get failure-to-send, instead you'll get the nice yellow banner.
This will not affect existing setups (by design) because of
the template-based setup (those setups will have their version
already deployed)
2025-02-20 10:21:25 +01:00
387d037c7c
Slight rewording in the README
2025-02-20 09:29:57 +01:00
934764dd8c
Tests: Better error message for failing integration tests
2025-02-20 09:26:04 +01:00
93ae506230
Don't 'eat your own dogfood' (send errors) while running tests
...
this was generally already so, but as per issue 4078 at sentry-python, not in all cases
2025-02-19 21:31:37 +01:00
bc1541050d
thousand-separators for counts
...
useful when there are very many events
2025-02-19 16:58:54 +01:00
154dceb2af
EVENT_STORAGE (FileEventStorage): docker-configurable
2025-02-19 16:09:01 +01:00
b169749231
Send welcome email: as a command
2025-02-19 14:52:48 +01:00
073bc7aaec
make_consistent: add --dry-run
2025-02-19 12:06:16 +01:00
f4250d2db8
make_consistent: document possible way forward
2025-02-19 11:56:21 +01:00
92425890cd
make_consistent: take 'points to missing' into account while deleting
...
also: switch a number of deletions from in-the-loop deletions to
delete-using-sql.
2025-02-19 11:42:44 +01:00
918b1ef54c
Add ids to 2 system-checks
2025-02-18 12:10:32 +01:00
3cb07246b9
Add system-check for EVENT_STORAGES setting
2025-02-18 12:08:05 +01:00
10f8e10607
DB indexes for the issue-lits (including filters)
...
simply by reasoning about what they should be; no performance testing (on the issue-list
and on the event-ingestion) was done for these)
2025-02-18 10:32:06 +01:00
2cb87f8334
Issues list pagination
2025-02-18 09:47:30 +01:00
7b32e71e1c
Merge pull request #45 from bugsink/dependabot/pip/python-packages-8f6e7d9701
...
Update sentry-sdk requirement from ==2.21.* to ==2.22.*
2025-02-17 21:44:02 +01:00
14bc3688c7
retention: deletion counts, more defensive idiom
...
the dict as returned by Django won't contain 'events.Event' if none are deleted;
no observed bug for this line, but good measure to fix it anyway
2025-02-17 21:36:08 +01:00
3a1fe9acec
allow long-running queries on 'nuke' and 'make_consistent'
2025-02-17 21:32:39 +01:00
5766fb8485
Make_consistent: run in a transaction
...
'Nice consistency you got here. Be a shame if anything happened to it.'
2025-02-17 21:11:44 +01:00
e37274c9aa
nuke_events: improvements
...
* better name
* better confirmation box
* more complete deletion (turning points, groupings)
* run in transaction
2025-02-17 21:00:12 +01:00
9b3e810950
Update sentry-sdk requirement in the python-packages group
...
Updates the requirements on [sentry-sdk](https://github.com/getsentry/sentry-python ) to permit the latest version.
Updates `sentry-sdk` to 2.22.0
- [Release notes](https://github.com/getsentry/sentry-python/releases )
- [Changelog](https://github.com/getsentry/sentry-python/blob/master/CHANGELOG.md )
- [Commits](https://github.com/getsentry/sentry-python/compare/2.21.0...2.22.0 )
---
updated-dependencies:
- dependency-name: sentry-sdk
dependency-type: direct:production
dependency-group: python-packages
...
Signed-off-by: dependabot[bot] <support@github.com >
2025-02-17 16:10:10 +00:00
443014f0b1
Dead code removal
...
this comment was added for-reference, was accidentally checked in
2025-02-17 16:45:10 +01:00
bab889cd84
transaction semaphore: ensure release for exceptions while _entering_ the transaction
...
Similar to 415da94093b0; but this time focussing on potential problems in `__enter__`.
i.e. `BEGIN IMMEDIATE` (or `BEGIN`) can _also_ fail for whatever reason, which
is yet another case where the semaphore should be released.
Rather than wrapping more parts of code (in this case, in `__enter__`) with try/except,
this made it clear to me that a separation of concerns was in order. Simply making 2
context processors, and stacking those is more transparently correct. As per the quoted
SO answer:
> Don't re-invent the wheel; this is not as simple as it looks.
2025-02-17 15:43:50 +01:00
ff11b29e1b
MoreLoudlyFailingTransport: avoid infinite recursion
...
since logger.error tries to use sentry in typical setups, using that to report
trouble with sentry is not a good idea
2025-02-17 15:31:04 +01:00
fad34de68f
Move MoreLoudlyFailingTransport out of the default 'eat_your_own_dogfood' conf
...
it's an extra convinience function for Bugsink developers (me), but the
less stability/more ergonomics tradeoff is not right in the general
case of running Bugsink
(for an example of an actually materializing stability problem, see the
upcoming commit)
2025-02-17 15:27:55 +01:00
97e54868c9
showstat: warning about eviction
2025-02-17 13:41:21 +01:00
b4bf6d01c3
Make import lazy for performance reasons ('cold start')
2025-02-17 13:31:03 +01:00
5263980f54
showstat: digestion_speed
2025-02-17 13:21:41 +01:00
Klaas van Schelven