Research: Diagnostic Refresh Triggers

[Sewer56]

Spike

Not to be confused with:

• Check whether diagnostic is relevant #1852

Currently

We only run diagnostics when the state of the Loadout changes.
In some cases, there may be alternative times when you may want to refresh diagnostics.

An UX Example

• User needs to install REDmod to Cyberpunk2077
• App shows an Error Diagnostic for missing REDmod
• REDmod is a DLC installed via your game store.

Because REDmod is installed externally, the diagnostic for missing REDmod continues to show
until the loadout is updated.

In practice this update will most likely happen when the user hits Sync to Ingest the new items
in the game folder. However, until that time, there is still a minor risk that the user will continue to
see the diagnostic, leading to confusion.

This time window however is very small. Therefore it is currently not that big of an issue.

Additional Information

Some questions arise:

• Should diagnostics opt-in to which events they should be updated on?
• Do we continue to just refresh the diagnostics entirely?
  • Only some diagnostics involve the current disk state, for example.
• Can this be turned into a caching system?
  • For example reuse a previous diagnostic result and check if it can be 'invalidated'.
  • This will let us have more expensive diagnostics in the App.

[erri120]

If you want to refresh on something else, you make a new emitter type. Previously, we had a mod and file emitter as well, it was just never used and didn't make a lot of sense. Since diagnostics are scoped to a Loadout, they'd change when the Loadout changes, anything else wasn't useful.

[Al12rs]

You need

• Apply/Ingest - Implement detection of outside changes #1198

Then a new emitter can be attached to that potentially.
I think we can revisit this after we have detection and have a clearer idea how that system will all work.