This issue is present on all components of this flow.
Starting backwards, the operator service expects ONE of:
owner (consumer address)
jobId (the job identifier)
agreementId (the tx id proving the transactions)
The Provider, when calling the Operator Service, uses the documentId , instead of the agreementId.
This documentId is the id of the data assets, but along the flow, no component does anything with it.
So, the CLI is sending a did and a JobId to the provider, via the SDK
The SDK is doing the following call to the Provider Instance
The fact that is doing the call to this.noZeroX(did) (to remove leading 0x) clearly indicates that its not actually expecting a DID, but a transaction hash, since a DID would start with did:op:
At the end we are sending the did as documentId parameter
Provider will then call Operator Service, which is not expecting a DID at all. On Provider side, we transform the consumerAddress param into owner, we grab the jobId and this documentId (no logic done with this one)
Then we call Operator Service compute status URL:
@services.route("/compute", methods=["GET"]) def get_compute_job_status(): .... msg = f"You have to specify one of agreementId, jobId or owner"
Here the agreementId will always be null, as we're not providing it anywhere, and the documentId is also useless to identify a job status
This issue is present on all components of this flow. Starting backwards, the operator service expects ONE of:
owner
(consumer address)jobId
(the job identifier)agreementId
(the tx id proving the transactions)The Provider, when calling the Operator Service, uses the
documentId
, instead of theagreementId
. This documentId is the id of the data assets, but along the flow, no component does anything with it.So, the CLI is sending a
did
and aJobId
to the provider, via the SDK The SDK is doing the following call to the Provider InstanceThe fact that is doing the call to
this.noZeroX(did)
(to remove leading 0x) clearly indicates that its not actually expecting a DID, but a transaction hash, since a DID would start withdid:op:
At the end we are sending the
did
asdocumentId
parameterProvider will then call Operator Service, which is not expecting a DID at all. On Provider side, we transform the
consumerAddress
param intoowner
, we grab thejobId
and thisdocumentId
(no logic done with this one)Then we call Operator Service compute status URL:
@services.route("/compute", methods=["GET"]) def get_compute_job_status(): .... msg = f"You have to specify one of agreementId, jobId or owner"
Here theagreementId
will always be null, as we're not providing it anywhere, and thedocumentId
is also useless to identify a job status