Page MenuHomeSoftware Heritage
Create Task
Maniphest T2283

"Vault Status" page doesn't get updated when asking for email notifications
Closed, MigratedEdits Locked
Actions

Description

When downloading a directory on the web-app the item doesn't appear in the vault admin page (same session and all)

This happens when you set an email address for the completion notification.

(this was a report for a transient issue with the vault, which got fixed)

Also in the notification email, I got:

You have requested the following bundle from the Software Heritage
Vault:

Object Type: directory
Object ID: 00b4bcdff80e8b3c180e481c76709fc876958b8a

This bundle could not be cooked for the following reason:

Internal Server Error. This incident will be reported.

We apologize for the inconvenience.

-- 
The Software Heritage Developers
  1. check if swh-team or devs received the report (not from me on IRC)
  2. check the error of the non cooked bundle
  3. check if the hiccup on the web-app was a one time thing

Related Objects

Event Timeline

moranegg triaged this task as High priority.Feb 13 2020, 3:50 PM
moranegg created this task.
olasd added a subscriber: olasd.Feb 14 2020, 3:08 PM

I wonder why sometimes requested objects don't show up on the vault status page. I think this might be because the "status page update" doesn't happen when the cooking has been requested in the past.

As for the rest of your questions:

  1. sentry does receive the automated reports properly (https://sentry.softwareheritage.org/share/issue/2fe372c9fb4443e5a0fb418f936540bf/)
  2. The actual error looks like a postgresql connection issue between the (postgresql) storage backend and its database
  3. after upgrading and restarting said storage backend, it looks like I managed to request this directory to be cooked, and the cooking succeeded

Requesting the cooking again:

curl -X POST https://archive.internal.softwareheritage.org/api/1/vault/directory/00b4bcdff80e8b3c180e481c76709fc876958b8a/

Checking cooking status:

curl -X GET https://archive.internal.softwareheritage.org/api/1/vault/directory/00b4bcdff80e8b3c180e481c76709fc876958b8a/
olasd added a comment.Feb 14 2020, 3:11 PM

Ah, I think I understand the issue:

When setting an email address in the "request cooking" popover, the "vault status page" doesn't update with the new object requested.

I think we really always should do both.

olasd renamed this task from Fix Vault on web-app to "Vault Status" page doesn't get updated when asking for email notifications.Feb 14 2020, 3:12 PM
olasd updated the task description. (Show Details)
olasd edited projects, added Web app; removed Vault.
anlambert added a subscriber: anlambert.Feb 14 2020, 3:27 PM

When setting an email address in the "request cooking" popover, the "vault status page" doesn't update with the new object requested.

I do not get the issue. Even if I set an email, the vault status page gets correctly updated.

moranegg added a comment.Feb 14 2020, 3:36 PM

I actually don't have it in both cases.
I'm firefox quantum 68.2

anlambert added a comment.Feb 14 2020, 3:39 PM

This must be related to T2284 when trying to recook an object, currently working on it.

anlambert mentioned this in D2674: Force recooking of an object when previous vault task failed.Feb 14 2020, 4:55 PM
olasd added a comment.Feb 14 2020, 5:23 PM

Hmm. I think there might be a race condition somewhere.

I really get a consistent pattern where requesting a cooked directory updates the status page when I don't set an email, but doesn't update when I set an email.

In both cases, the directory hadn't been cooked before (I tried on subdirectories of a fresh revision of cpython), and the cooking eventually succeeded.

anlambert added a comment.Feb 14 2020, 5:33 PM

That's weird, I just created a bunch of vault tasks for non cooked directories using chromium and Firefox and the vault status page correctly updates itself.

Can you check if there is some errors reported in your browser console ?

anlambert lowered the priority of this task from High to Normal.Jun 30 2020, 4:01 PM

I still can not reproduce the issue. Keeping that task opened in case someone else encounters it but I am raising down the priority of that task.

anlambert closed this task as Invalid.Nov 17 2020, 3:12 PM
anlambert claimed this task.

Closing this as the observed issue could not be reproduced. I just checked again and everything works as expected plus the vault UI is fully tested with cypress.

gitlab-migration changed the task status from Invalid to Migrated.Jan 8 2023, 4:29 PM
gitlab-migration claimed this task.
gitlab-migration added a subscriber: gitlab-migration.

This task has been migrated to GitLab.

About · Developer information · Legal