Database growing way too much (music_upload)

Steps to reproduce

Unfortunately I don't have enough time to trial-and-error a reproduction. I'll try to describe what lead to this situation.

My funkwhale is about a year old now and my library consists of ~4600 Files (according to find -type f), totalling 39 GiB, there's probably some other non-music files sprinkled in. Funkwhale, however, tells me my Library consist of 292994 Songs, according to the number that shows up in the library management view.

Because I use syncthing to get my music library that I manage with https://beets.io synced to my music server which resides on a vps in a datacenter, I don't want to manually tell funkwhale to keep it updated. So I set up a script that is ran by cron every three hours that performs some maintenance:

import_files --recursive --in-place --no-input --username $myuser $my_library_uuid /path/to/my/synced/music/
check_inplace_files --no-dry-run
prune_library --no-dry-run --artists --albums --tracks
rebuild_music_permissions

Which worked well for me so far.

What happens?

I was recently greeted by a 500 Server error, which was caused by postgresql crashing due to the harddisk usage reaching 100%. When I inspect my funkwhale database in postgresql, it tells me the music_upload table totals 28GiB.

What is expected?

The music_upload tables's size stays reasonably low, or functionality is added to prune it.

Context

Funkwhale version(s) affected: 1.1.4

• OS: Debian 10.10

I'd added some logs first but those are 100% irrelevant to this case. I decided to inspect the contents of music_upload and a single row(!) for a song takes 1.1MiB to store on disk when writing it out: dump