akkoma/lib
floatingghost 28626eafc1 Allow higher amount of restarts for Pleroma.Repo during testing
This was done by floatingghost as part of a bigger commit in Akkoma.
See <37ae047e16/lib/pleroma/application.ex (L83)>.

As explained in <https://ihatebeinga.live/objects/860d23e1-dc64-4b07-8b4d-020b9c56cff6>

> there are so many caches that clearing them all can nuke the supervisor, which by default will become an hero if it gets more than 3 restarts in <5 seconds

And further down the thread

> essentially we've got like 11 caches (37ae047e16/lib/pleroma/application.ex (L165))
> then in test we fetch them all (https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/test/support/data_case.ex#L50) and call clear on them
> so if this clear fails on any 3 of them, the pleroma supervisor itself will die

How it fails?

> idk maybe cachex dies, maybe :ets does a weird thing
> it doesn't log anything, it just consistently dies during cache clearing so i figured it had to be that

> honestly my best bet is locksmith and queuing
> https://github.com/whitfin/cachex/blob/master/lib/cachex/actions/clear.ex#L26
> clear is thrown into a locksmith transaction

> locksmith says
> >If the process is already in a transactional context, the provided function will be executed immediately. Otherwise the required keys will be locked until the provided function has finished executing.

> so if we get 2 clears too close together, maybe it locks, then doesn't like the next clear?
2022-07-14 13:50:44 +02:00
..
mix Rename the Exiftool module 2022-07-01 12:15:02 +02:00
phoenix/transports/web_socket Copyright bump for 2022 2022-02-25 23:11:42 -07:00
pleroma Allow higher amount of restarts for Pleroma.Repo during testing 2022-07-14 13:50:44 +02:00