Do not retry the payment, we will on the next charge cycle, but make sure email notifications are not interrupted by topup failing.

Check updated_at/created_at

I was thinking about removing the try/catch. If we make a top-up attempt on every WalletCheck job run there's really no need for dispatching a separate job. The only danger will be that if topUpWallet() always throws the rest of the code will never execute, but how big of a danger is that I'm not sure.

Fixed some typos, now the query exeutes in reasonable time

Questions:

• Is this good enough to detect inactivity?
• Is the degraded state good enough or do we need to check the wallet balance?

This uses the same mechanisms as the horizon dashboard, and allows us to largely ignore the dashboard and implement monitoring (to e.g. notice if a queue gets stuck or so).

Makes sense in principle, but yields about 20k fewer entries it seems (even when filtering only for the "pushed" jobs).

Take a look at App\Jobs\User\DeleteJob, it will add STATUS_DELETED after all code before passes (does not throw an exception). So, checking for missing STATUS_DELETED should be included, and probably should be enough to check just this one.

Only count actually pushed jobs

In D5014#62904, @machniak wrote:

Also, whereNot('status', '&', User::STATUS_DELETED) would probably do the same. This status is set after user deletion from LDAP/IMAP was successful.

Also, whereNot('status', '&', User::STATUS_DELETED) would probably do the same. This status is set after user deletion from LDAP/IMAP was successful.

Maybe where deleted_at < "5 seconds ago" would be better to give some slack to users deleted "right now".

• Add QR code

• CS fixes