Page MenuHomeSoftware Heritage

Improve save code now failed/uneventful status reporting
Closed, ResolvedPublic

Description

Some uneventful visits are reported as failed ones.
Only when looking into the popup details window of the visits
can we see if a visit is actually a failed visit or not (and sometimes be confused by it).

In the task log entry, at the end of the popup:

  • actual failed visits will report a failed visit with a potential extra Exception line.
  • uneventful visits will report an uneventful visit

It'd be best if we distinguish directly from the listing view such details.

Implementation wise, the save code now is missing the extra visit state to be able to distinguish such case.
The detail popup window is able to because it does some extra computing only when triggered by the user.
A relevant improvment would be to add the visit status in the pop up view before the task report.

Event Timeline

ardumont triaged this task as Normal priority.Mon, Apr 19, 9:42 AM
ardumont created this task.
ardumont renamed this task from Cannot distinguish failed visits from uneventful one to Improve save code now failed/uneventful status reporting.Mon, Apr 19, 9:53 AM

It'd be best if we distinguish directly from the listing view such details.

So in the end, i think that sentence was wrong.

I was unable to reproduce this through test. But i encounter the issue and reproduced
locally with the origin [1]. That repository no longer exists. So the loading task was
uneventful with a visit status "not_found". That visit status not being anywhere confuses
the report.

One still relevant improvment though would be to add the visit status in the pop up view
before the task report.

In the detail popup, right now, we can see only the last line of the task status as
uneventful [2]. So somewhere in that popup, if we could display the origin visit_status,
that would clarify immediately for the users who wants to know why the visit failed.

[1] https://github.com/arw36/species-interaction-dataset-inventory

[2]

[2021-04-19 15:33:42,601: INFO/ForkPoolWorker-1] Task swh.loader.git.tasks.UpdateGitRepository[82de1530-6c28-4b06-8e78-d2db780b0c00] succeeded in 0.3840508400462568s: {'status': 'uneventful'}

Landed. Remains to deploy. I'll attend to that tomorrow.

ardumont changed the task status from Open to Work in Progress.Wed, Apr 21, 7:08 PM

So, the debian/unstable broke which is fixed now [1] (it wasd missing one new deps to
test the migration part).

And now the stable build broke after that [2].

And fun fact, there are so much warnings that when reproducing the failure locally, I
can't reach the failure part of the output... (that exceeds my tmux configuration of
10000 lines...)

Now on to understand the difference (probably version mismatched...).

[1] https://jenkins.softwareheritage.org/job/debian/job/packages/job/DWAPPS/job/gbp-buildpackage/273/console

[2] https://jenkins.softwareheritage.org/job/debian/job/packages/job/DWAPPS/job/gbp-buildpackage/275/consoleFull

Trying to bisect the issue and failed (multiple dimensions got the best of me, master ok, debian build in stable ko... i need to improve my tooling there).

In any case, @anlambert got more result and identified the commit rDWAPPS1042f73c181d722e681a562088afcdcc2ee0af69 as introducing the issue.