Unstable channel shows wrong version in the suggestions view

erictapen commented

2024-10-31 15:22:36 +00:00

(Migrated from github.com)

I have no idea yet how it works or wether it's an actual issue, but there seems to be the pattern, that the old stable version and the unstable version seem to be equal, while the new stable version is newer. Hints towards a bug.

Edit by @fricklerhandwerk:

We want to display when the evaluation for a matched derivation was made, so users can inspect whether the data is recent. Needs refinement on how to present that.

I have no idea yet how it works or wether it's an actual issue, but there seems to be the pattern, that the old stable version and the unstable version seem to be equal, while the new stable version is newer. Hints towards a bug. ![tmp J9lSQSs1Lo](https://github.com/user-attachments/assets/d136449d-8437-41de-8bc8-c2ad9f41a16d) Edit by @fricklerhandwerk: We want to display when the evaluation for a matched derivation was made, so users can inspect whether the data is recent. Needs refinement on how to present that.

RaitoBezarius commented

2024-11-14 12:48:00 +00:00

(Migrated from github.com)

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.

fricklerhandwerk commented

2024-11-14 14:05:21 +00:00

(Migrated from github.com)

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.

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.

RaitoBezarius commented

2024-11-14 15:32:39 +00:00

(Migrated from github.com)

Correct.

fricklerhandwerk commented

2024-11-18 23:37:28 +00:00

(Migrated from github.com)

We're not updating existing suggestions with new evaluations, right? This seems to be related to https://github.com/Nix-Security-WG/nix-security-tracker/issues/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.

We're not updating existing suggestions with new evaluations, right? This seems to be related to https://github.com/Nix-Security-WG/nix-security-tracker/issues/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.

RaitoBezarius commented

2024-11-20 18:28:40 +00:00

(Migrated from github.com)

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.)

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.)

👍 1

RaitoBezarius commented

2024-11-20 18:30:40 +00:00

(Migrated from github.com)

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

👍 1

Rows
Columns

Unstable channel shows wrong version in the suggestions view #307