Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fix helps prevent #428 from resulting in the entire container being killed by the host. The timeout still occurs on the web browser, but importantly the delete task does complete whereas before the gunicorn worker timeout interrupts the task. Reloading the tubesync homepage after the timeout will now show the source as deleted. I've done this by ensuring that the gunicorn workers have a much longer timeout before being killed (10mins instead of 30 seconds), and by forcing the workers to be restarted. I think the key change is increasing the timeout but I think both are helpful in long-running applications (months of uptime).
As can be seen from the logs below, it's the gunicorn worker (pid 358) that ultimately causes the application to crash completely and the delete task to be interrupted. First is log from meeb/tubesync:latest, 2nd log has this fix included (I've shortened the log to show the key entries only). I understand the root cause (excessive memory usage) is still unaddressed, but this should hopefully reduce the severity of the issue.
Also fixes a mistake I made in signals.py which prevented the filter_text from working properly.