Ok so absolute URLs are indeed URLs starting with http(s):// scheme.

I don't really see why it should break worker job (dev, staging, prod).

FTR I have this working in docker dev on my machine.
I may require some configuration adjustments when deployed.

In the following diffs I also have code to be able to test the interaction with the scheduler, which should also improve a bit the reliability of the stack.

I don't really see why it should break worker job (dev, staging, prod).

well, we already agreed some time ago it should not.
(I'm just telling you the current state, i never fixed that nor see any diffs going that way yet)

In the current code of the deposit checker, it will break.

(This is no longer true on the deposit loader so \m/, checked the scheduler db, see below)

The deposit client (used by the checker) expects from its settings the absolute urls of the deposit server it's supposed to connect to. It then expects a relative url to fill in the blank to answer correctly.

See some swh-scheduler' tasks sample (prod):

softwareheritage-scheduler=> select arguments from task where type='check-deposit' limit 10;
                                  arguments
------------------------------------------------------------------------------
 {"args": [], "kwargs": {"deposit_check_url": "/1/private/other-client/352/check/"}}
 {"args": [], "kwargs": {"deposit_check_url": "/1/private/hal/351/check/"}}

In the following diffs I also have code to be able to test the interaction with the scheduler, which should also improve a bit the reliability of the stack.

yes, server side, eveything was tested but that part indeed iirc.
so cool.

Ok so absolute URLs are indeed URLs starting with http(s):// scheme.

well, we already agreed some time ago it should not.

Clarifying...
I mean we agreed on no longer using relative urls.
And that this is what the current diff does.

We should use absolute urls.
But that diff won't work if we deploy it today (and that's how i see a diff by default, something that can land and be deployed).

That's all i'm trying to convey.

This needs to include the necessary fix on the deposit client used by the checker.
As of today, there is only one user of the deposit client (private deposit client), it's the checker.
(the loader used to use it but no longer, it defines its own [1])

[1] and in the end, there will be a slight impact there as well, still related to relative url... (it does the same stuff to speak with the private api part to update the deposit's status, i can take care of this i think, just tell me if you want me to ;).

[1] and in the end, there will be a slight impact there as well, still related to relative url... (it does the same stuff to speak with the private api part to update the deposit's status, i can take care of this i think, just tell me if you want me to ;).

never mind that part, i think it's fine as is.