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.

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.