Debug info: print all workers

[ArnyminerZ]

Purpose

Right now we only provide the information of the individual sync workers for each account and data type, but no information about the "generic" workers is provided.

Example:

Sync workers:

┌───────────────────────────────────────┬─────────────────┬─────────────┬─────────┬────────────┬────────────────┐
│ Tags                                  │ State           │ Next run    │ Retries │ Generation │ Periodicity    │
├───────────────────────────────────────┼─────────────────┼─────────────┼─────────┼────────────┼────────────────┤
│ [.sync.account.AccountsCleanupWorker] │ ENQUEUED (-256) │ In 20 hours │ 0       │ 11         │ every 1440 min │
└───────────────────────────────────────┴─────────────────┴─────────────┴─────────┴────────────┴────────────────┘

Short description

• Added workersInfoTable in DebugInfoModel which allows generating tables for workers in a more generic way.
• Added information for AccountsCleanupWorker.

Checklist

• The PR has a proper title, description and label.
• I have self-reviewed the PR.
• I have added documentation to complex functions and functions that can be used by other modules.
• I have added reasonable tests or consciously decided to not add tests.

[ArnyminerZ]

@rfc2822 I've added the info for AccountsCleanupWorker, I don't know if any other one is desirable.

[rfc2822]

Could we have a list of all "other" workers which are not mentioned in the account section? Reason is that there may be old workers which have not been cancelled correctly, for instance by migrations.

Maybe we can return the IDs of the workers when we dump the account workers, remember them and at the end print all other workers (= those which were not printed yet). Or something similar.

Also I think it's time to move the debug info generation into a separate class DebugInfoGenerator, then it won't clutter the model (still UI layer) so much.

[sunkup]

The AccountsCleanupWorker is not a "sync" worker. I would rename one or both of the dumpSyncWorkersInfo methods to dumpWorkersInfo.

Not sure we really need to be able to generate other tables besides "Sync workers" and the new "Generic workers" table. Having a generic generation function seems a bit overengineered to me, but I guess it might come in handy.

[ArnyminerZ]

I've done what you suggested, filtering the sync workers, and seems to work good. It's a bit more convoluted, but I think it's fine. An example of the result:

Generic workers:

┌───────────────────────────────────────┬─────────────────┬─────────────┬─────────┬────────────┬────────────────┐
│ Tags                                  │ State           │ Next run    │ Retries │ Generation │ Periodicity    │
├───────────────────────────────────────┼─────────────────┼─────────────┼─────────┼────────────┼────────────────┤
│ [.sync.account.AccountsCleanupWorker] │ ENQUEUED (-256) │ In 23 hours │ 0       │ 14         │ every 1440 min │
│ [.push.PushRegistrationWorker]        │ ENQUEUED (-256) │ In 23 hours │ 0       │ 0          │ every 1440 min │
└───────────────────────────────────────┴─────────────────┴─────────────┴─────────┴────────────┴────────────────┘

[sunkup]

You are right it still looks a bit inconvenient/awkward. I am wondering a whether it would be simpler to:

1. Request all workInfo of all workers.
2. Filter out the "sync-" workers by tag and display them
3. Filter out the non "sync-" workers by tag and display them.

That would probably require workersInfoTable to only display the workInfo data and not do the querying as well.

It shows up alright though, so I think it's not worth the hassle and this is fine, like you say. 👍

[rfc2822]

I have moved out debug info generation into a separate class.