These tests were originally in what is now 1201f754e3
but they were held back because they provide more information
to an attacker than strictly required.
The orignal (non-published, now published) commit message (which
goes with both the code and the tests) was:
As noted by @Cycloctane:
> The problem is that the infinte loop I was talking about is happening inside
> `brotli_generator`. Because brotli `decompressor.is_finished()` never returns
> True if the input is not valid brotli compressed data or is truncated. And
> `decompressor.process()` will keep returning empty bytes that won't be *yield*
> out, making the generator keep looping inside itself. `MaxDataReader` is not
> possible to limit it.
this was exposed when dealing with things that yield in very big chunks
potentially (e.g. brotli bombs)
tests are more directly on the GeneratorReader itself now rather than
integrating this with particular genators-under-test.
This became possible with brotli 1.2.0
It is my understanding pre-this change there was basically no
enforced limit on the amount of bytes "coming out" of
decompressor.process(); in other words: chunk size did not
apply to the most relevant (potentially blowing up) part of
the equation.
We had a MaxDataReader in place, but that would come "too late"
since all the mem-consuming stuff would happen right in brotli_generator
before any limiting would be possible.
See https://github.com/google/brotli/issues/1381
See https://github.com/Sija/raven.cr/issues/100 for the thing that triggered this
Caused by spotting this in the (shared on discord) logs of one of our users:
```
RuntimeWarning: DateTimeField Event.timestamp received a naive datetime (2025-10-26 16:01:08) while time zone support is active.
```
See #252
This is not backwards compatible (it will now hard-break), but given snappea's
rather particular design decisions this is probably for the best, and given
what else was just discovered on #252 I strongly doubt anyone was actually using
it in such setups anyway.
See #252 where the following error was triggered:
> django.db.transaction.TransactionManagementError: select_for_update cannot be
> used outside of a transaction.
I believe that this is caused by using a non-sqlite database for the snappea DB.
"You probably shouldn't" but at least our own behavior should be consistent.
I haven't been able to reproduce this particular error BTW, but at least I've
reproduced _some_ error conditions that this commit fixes.
Bugsink 2.0 upgraded to Django 5.2 (from 4.2) under the hood. However, Django
5.0 made it so that on MariaDB >= 10.7, UUIDFields are stored as native UUID
fields, and special conversion steps are required.
The Django 5.0 release notes suggest basically downgrading your existing UUIDs
to CharField values and sticking with that forever, but that's not a workable
solution for us for many reasons:
* Bugsink is multi-DB-backend, and this change would affect them all. I don't
want to force postgres-users to downgrade just for this.
* Bugsink 2.0 is already out in the wild, and people who've deployed it on
MariaDB >= 10.7 would already "be in the correct future" (have UUID columns).
i.e. the "solution" would just create the inverse problem.
* What with new models with new UUID fields? We'd run the rist of a "mix" with
all the future complexity that comes with _that_.
So I've decided to just bite the bullet and force an upgrade. The provided
command allows users to upgrade their data. Just run:
```
bugsink-manage convert_mariadb_uuids
```
I have not (yet) provided this as a migration (it's always an option for the
future)... mostly for lack of time but also because we "need this as a command
anyway"... because people that would be on MariaDB < 10.7 still need this
tool whenever they migrate to >= 10.7.
Fix#226
See #236 (for context, not for something that's solved by this):
> I did just notice that whatever the form validation error on-login is, the
> above message is shown. I will fix that at least to make debugging the above
> easier in the future. (i.e.: to make it so that if the form data is missing
> entirely, you'd get a "this field is required" for both fields)
This also gets rid of the lock/person but I don't care enough for those
to keep them around.
