Page MenuHomeSoftware Heritage

Some SWHIDs provided by the WebApp produce 404 when resolved
Closed, ResolvedPublic


SWHIDs obtained via the WebApp are expected to be all resolvable, but I stumbled on a corner case that systematically fails.

To reproduce:

  1. go to;origin=;visit=swh:1:snp:1f5f82e8e604e7aabc815c99bd0d15769e60016e/
  2. pull out the Permalinks tab and click on "Directory", you get;origin=;visit=swh:1:snp:1f5f82e8e604e7aabc815c99bd0d15769e60016e;anchor=swh:1:rev:52f5f708b220b6a006fa64d54f915beb73cb65cf/
  3. this last link produces a 404: NotFoundExc: Branch refs/pull/97/head for snapshot with id 1f5f82e8e604e7aabc815c99bd0d15769e60016e not found!

Event Timeline

rdicosmo triaged this task as High priority.Apr 1 2021, 3:56 PM
rdicosmo created this task.

Arf, this is a side effect of rDWAPPScc652d5240d9cd6186c6a8ce8b5938f2c7a8f921.

We decided to hide pull requests branches by default in browse as it adds a lot of noises in the branches views.

I added the filter globally in browse but I did not think about that corner case, will fix that asap.

When resolving a revision SWHID or an extended SWHID with anchor revision, swh-web checks if the revision is a tip of a branch to display the information in the HTML views.

Thinking it back, this is not a great idea plus the code I wrote only gets the first branch targeting that revision.

I think the simplest fix to that issue will be to remove that process in the resolve code.

Bug has been fixed but will be deployed tomorrow as @ardumont is currently working on migrating
the webapp database in production to postgres (T2945).

We need that migration effective before any new deployment of swh-web.

Fix has been deployed to production, closing this.