frontend: always calculate the snippet indexes from the beginning

fedora-copr / log-detective-website

Data collection page for Log Detective AI

11 stars 7 forks source link

frontend: always calculate the snippet indexes from the beginning #113

Closed FrostyX closed 3 months ago

FrostyX commented 3 months ago

We have been collecting incorrect indexes. They aren't calculated from the end of the log but rather from the end of the previous node.

I am currently working on fixing our collected data.

nikromen commented 3 months ago

looking good so far, I checked the indexes on chromium and firefox.

Could you also please rebase to the current HEAD? since the backend part is not the latest so I want to test it against the latest BE just to be sure

TomasTomecek commented 3 months ago

We have been collecting incorrect indexes. They aren't calculated from the end of the log but rather from the end of the previous node.

I am currently working on fixing our collected data.

does this mean that some of our data may be wrong?

nikromen commented 3 months ago

Thanks everybody for the reviews! It works for the most cases. However, there are 2 issues:

1 issue is small - the indexes are shifted by 2 or 1 - not a big deal, the context still remains
2 issue is however worse - if you scroll around the log and add a few snippets and then delete some of them, the next snippet indexes are wrong - with 100% reproducibility if you add snippet from the very end of the log. I think this may be caused by the first issue (the index overflows due to the indexes shift?)

TomasTomecek commented 3 months ago

Thanks everybody for the reviews! It works for the most cases. However, there are 2 issues:

1 issue is small - the indexes are shifted by 2 or 1 - not a big deal, the context still remains

2 issue is however worse - if you scroll around the log and add a few snippets and then delete some of them, the next snippet indexes are wrong - with 100% reproducibility if you add snippet from the very end of the log. I think this may be caused by the first issue (the index overflows due to the indexes shift?)

naive thinking: how about disabling removals?

nikromen commented 3 months ago

as per chat in slack - merging this to release this fix ASAP and deal with the edgecase later - #117

nikromen commented 3 months ago

naive thinking: how about disabling removals?

That would significantly lower the user experience, potentially lowering the feedbacks we get :/ I used this feature several times. In case I'll need to close it and fill it once again (as normal user) I'd probably left it without giving feedback