The RPC process API results in a Task object with a reference to the request-id associated with the API request. This allows the requestor to later check the "result" of that Task by correlating the request-id with an activity log entry.
Although the RPC process API itself is idempotent -- only one Task will ever be created for a given node-transition -- subsequent calls to the RPC process API for the same "thing" generate new request-ids that are not tracked by the Task or any resulting activity logs entries. Consequently, the URL for "status update" returned by the API is incorrect.
The API should check for an existing Task item and scrape the original request-id from it to use in the "status update" URL. This would make the RPC process API idempotent for both the backend and the caller.
The RPC process API results in a Task object with a reference to the request-id associated with the API request. This allows the requestor to later check the "result" of that Task by correlating the request-id with an activity log entry.
Although the RPC process API itself is idempotent -- only one Task will ever be created for a given node-transition -- subsequent calls to the RPC process API for the same "thing" generate new request-ids that are not tracked by the Task or any resulting activity logs entries. Consequently, the URL for "status update" returned by the API is incorrect.
The API should check for an existing Task item and scrape the original request-id from it to use in the "status update" URL. This would make the RPC process API idempotent for both the backend and the caller.