To fix this, we probably need to monitor the date of the last ingestion, now that we have nuked the database, we cannot observe this on the long term anymore.

Ah, are you saying this is merely evaluations being out of sync, e.g. that we see old things on unstable because the last eval of unstable was before evaling stable branches?

In any case, keeping the evaluation timestamp would be nice, because we can display possible discrepancies right there in the UI. And maybe also show the commit hash we're working with for a given branch.

Correct.

We're not updating existing suggestions with new evaluations, right? This seems to be related to #201

We may want to update all derivations on existing suggestions with new evaluation data, and highlight if there was a change since the last manual modification. E.g., for "selected" suggestions: if the last change from the activity log was before the bump, make it visible that versions may have changed. Ideally we'd only highlight when they actually changed.

This is true, this means that once channel are updated, we need to:

• expire all pending suggestions and redo them
• iterate over rejected suggestions and accepted suggestions
  • do as if we were going to rematch things up
  • compare what is newly matched with what exist already
  • "replace" the M2M row for everything we can link (old derivation, new derivation)
  • add the new M2M rows
  • delete the old M2M we cannot match up

warning : this means we need to develop a way to relate derivation in channel rev X and derivation in channel rev Y.
(this problem also exist in some of the optimization work we do in Lix/Hydra for build analytics, I think what we can do is to track by attrPath and that's… probably the best we can do? i.e. if someone moves the derivation to another attribute path, bye bye, we lost it.)

Now with #378, the extra surprise is whenever we update suggestions, we need to schedule a background job to recache it.