Examples of such missing objects are revisions with attributes that cannot fit the current data model, e.g. out of range dates. We have example of such revisions in kafka, as mentionned in T3200 and T3170.

Note that none of their parent revisions can be found either in the archive (one invalid revision in a set of ingested revisions prevent any of them being inserted in the database I suppose, but they are already inserted in kafka at this moment).

In T3235#63002, @libEqualizer wrote:

You are likely doing a git pull on a periodic basis. Just add git bug bridge pull [<name>] next to it.

However, this would require considerable work

Hi, thanks for the suggestion.

In T3226#62710, @vlorentz wrote:

You should install swh.model[cli] instead of swh.model. I added a better error message in D5466 so it's clearer.

And I'm also updating the documentation at https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html#computing

You should install swh.model[cli] instead of swh.model. I added a better error message in D5466 so it's clearer.

Resolved by D5460; thanks again for the report

looks like there is no revision with date or committer_date > 9999-12-31 in the main storage...

duplicate with T3160

Already implemented in D4193

(and we should keep the origin topic; we already have an ExtSWHID for origins anyway)

The following objects remain:

In T3034#58665, @zack wrote:

Who needs to reference REMs in the first place?

In T3034#58665, @zack wrote:

Who needs to reference REMs in the first place?

(I've finally caught up with the backlog in this task, sorry I'm late to the party.)

So, there's still a few separate issues in this task which I'll try to spell out (at least for my sake) :

We also added a 'failed' status.

Sounds good to me.

Proposed manifest format:

Landed, packaged in swh.model 0.8.0.
Also email sent to swh-devel as a heads up to fellow developers using that function.