Now with a new session I can relaunch a failed directory, but in an old session it keeps the error in the vault table view.

I just had two vault successes:

• d83b7dda887dc790f7207608474650d4344b8df9
• cf31343fd5744d56d7126b6cb99e96d29f5c0376

Now this returned with internal server error: fb13b51abbcfd13de85d9ba8d070a23679576cd7
and this one is done: 4a2875f69e68bb60a9e76414439c073fd2b20732

For the new error where download stays at "new" for a long time, here are my 2 tests:
4a2875f69e68bb60a9e76414439c073fd2b20732
fb13b51abbcfd13de85d9ba8d070a23679576cd7

The query is done and cooked with 10% failed/unstarted directories.
Waiting for Crossminer's analysis to see if we need to relaunch the remaining 10%.

Directories I tried and failed:

• b1ed8c3c380b35c0a6546a04e526259d600c7a31
• 8fd378d35eb2c80a24d5a29e66b994ed2a275592

For the same reason as above I don't think the error message should be sophisticated and try to tell the user to enter a repo URL instead. It should just say something like "no repo to clone there". Users will figure out what they need to do.
(And we can have some example doc on the wiki, about how to "save code now" for common forges, if really needed.)

I agree it shouldn't be elaborated, a global rejection error with a link to the user documentation of how to use the "save code now" feature is sufficient.

A possible problem to check with this workflow:

hal-prod and hal-preprod uses the same identifiers for different objects

https://forge.softwareheritage.org/P285 (for my local tests)

make test 2>&1 | tee output-test

It is not yet deployed on the docs web pages, but I'll put a link here when it is.
Also I'm planing some modifications on the swh xml schema for the swh-id properties (mentioned in T1152).

After the deposit workshop and the last errors we had with HAL, I believe this entry point has to be without any deposit_id or external_id.

• docs: Update specs for the sparse-deposit and meta-deposit
• docs: Add swh xml schema for sparse and meta deposits
• docs: update example meta-deposit
• Update sparse-deposit and metadata-deposit specs
• Update sparse/metadata deposit specs

Just to be clear about this:

1. the property swh-id returned to the client is the directory, with or without context?
   • swh:1:dir:42a13fc721c8716ff695d0d62fc851d641f3a12b
   • swh:1:dir:42a13fc721c8716ff695d0d62fc851d641f3a12b;origin=https://hal.archives-ouvertes.fr/hal-01727745
2. How should we call the new property added for the revision ID ?
3. And will it be a revision ID with or without context?

Just adding another piece to the rational puzzle:
The software citation

I'm adding this meta-task to the grand HAL-opening thinking it can (and should) be resolved after accomplishing this milestone.

Looks good to me.
All tests pass...

My only comment would be to better document the possible archive errors that appear in the test,
if there are 4 types of errors -> missing / unreadable / unsupported / invalid, it will be easier to understand where they are captured if documented.

No worries, I'm good with the changes.
Also all tests pass on my machine.
When are you deploying?

This looks good ! are the error messages returned to the client as is?

I will take the improvement of the error message :-)

• Update sparse/metadata deposit specs