1745178 - Slack cache grows without limits, causing shutdown issues

Status: NEW

(Core :: Storage: Cache API, defect, P2)

Description

[Francesco Lodolo [:flod]]

Attachment: Files in app.slack.com folder

I keep Slack opened in a pinned tab. Lately, I noticed issues while restarting Nightly (97, 20211209093228) for updates (shutdown would take between 45 and 60 seconds).

Looking at the profile, two size issues were evident:

• The webappsstore.sqlite file was about 5GB
• The storage folder was over 3GB

I tried removing cache and site data from preferences, but it didn't work. I had to manually remove files from disk.

In storage, Slack alone was taking over 2GB. This is the list of files in the https+++app.slack.com folder.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

It's not surprising for Slack's usage to reach that level; I did some investigation in https://bugzilla.mozilla.org/show_bug.cgi?id=1678795#c54 that covers its non-trivial caching heuristics that aren't concerned about quota limits.

Comment 2

[Eric Huber]

I'm seeing this too lately. Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=1665197 ? Most of the storage usage seems to be in the storage/default/https+++app.slack.com/cache/morgue directory. As a workaround, I periodically delete this subdirectory and reload any Slack tabs. The deletion can be automated but this seems so unnecessary.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

The general situation I think going on here is:

• Slack only cleans up quota after successfully installing.
• We have a non-trivial bug "ServiceWorker never actually gets to progress to activated" due to a pinned tab never being closed.

I think our next step for slack is likely to address the "ServiceWorker never actually gets to progress to activated" status that's documented and has a plan at https://bugzilla.mozilla.org/show_bug.cgi?id=1668743#c23 which was languishing a bit due to a lack of engineers available (and the domain complexity).

Once we've addressed that we can pursue other mitigations and/or talk to the slack devs about potentially rethinking how much quota they use, as our mitigations are mainly "wipe all slack storage" and "but keep the cookies so the user doesn't have to login again". And these are mitigations we've already deployed, but they only fire when it seems like slack is suffering from having hit the quota limit (which will now usually be 10G).

Comment 5

[Eric Huber]

Since my last comment, I've switched to another workaround that's been more convenient: rather than periodically deleting the morgue subdirectory, I replaced morgue with a symlink to /dev/null. This prevents additional storage from being used and so far it doesn't seem to have broken Slack. However, I can't say whether it's a safe workaround for others to try.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Tried to back up my Nightly profile today, to learn it was 10GB due to this issue. 😯

★ ~/Library/Application Support/Firefox/Profiles/uuid.default/storage/default/https+++app.slack.com $ du -sh cache
7.5G	morgue/

★ ~/Library/Application Support/Firefox/Profiles/uuid.default/storage/default/https+++app.slack.com $ ls -l cache/morgue
total 0
drwxr-xr-x@ 260 Jan  staff  8320 Jun  1  2022 0
drwxr-xr-x@ 249 Jan  staff  7968 Jun  1  2022 1
drwxr-xr-x@ 204 Jan  staff  6528 Jun  1  2022 10
drwxr-xr-x@ 241 Jan  staff  7712 Jun  1  2022 100
drwxr-xr-x@ 238 Jan  staff  7616 Jun  1  2022 101
drwxr-xr-x@ 260 Jan  staff  8320 Jun  1  2022 102
drwxr-xr-x@ 231 Jan  staff  7392 Jun  1  2022 103

Most of the folders are from June 1, so I'll wipe them and be fine. But should we clean these up for folks like we did in bug 1165119 maybe?

Maybe I'm dating myself, but 10GB seems a lot to let sites store on my box without ever asking (afaik).