fix: don't bail on room compression

[siddarthkay]

Thank you for the amazing work on this library!

Summary

I observed this issue in one of our hosts that run rust-synapse-compress-state

[2025-05-12T00:11:01Z ERROR panic] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` 
value: Ran the compressor on a room that had no more work to do!': synapse_auto_compressor/src/main.rs:155
synapse-auto-compressor.service: Main process exited, code=exited, status=101/n/a

By looking at the code I observed that run_compressor_on_room_chunk is returning None for one of the rooms, indicating there's no more work to do in that room and I think it would be better if instead of bailing we could skip to the next room.

What do you think?

[reivilibre]

have you tested this in real life?

It looks like this risks hot-looping on the same room again and again — after all, we just selected a new room to compress (therefore the query for finding compressible rooms believed it was compressible), we didn't modify the room in any way and now we're going to select a room to compress... what stops us from getting the same room again?

Bear in mind I'm not familiar with this codebase to be fair — but this seems to be my impression of the intention of the code — this bail is indicating a bug that we are selecting a room believing it is compressible but actually it isnt..

[anoadragon453]

@reivilibre I agree with your reading of the code. Getting into this branch indicates a deeper bug in the compressor, and we should bail instead of continuing on. get_next_room_to_compress relies on run_compressor_on_room_chunk calling write_room_compressor_state to update the state_compressor_progress table (here) in order to advance to the next room. If we continue here, that won't happen.

@siddarthkay are you still able to reproduce the issue? Perhaps we can work out why the compressor is selecting a room it can't compress.

[anoadragon453]

Blocked on https://github.com/matrix-org/rust-synapse-compress-state/pull/155/files#r2093047490