Similar to 'submit', but returns the result from the worker.
Similar to 'submit', but returns the result from the worker.
This assumes the job submitted to the exchange can be sent verbatim to the worker.
The workflow is:
1) submit to exchange, awaiting a match 2) on (redirect) response (when a worker is eventually assigned), submit the work to the matched worked 3) return the response from the worker ... which could be *anything*
the job submission
the worker response
Enqueues the given job, then uses the supplied function to send the matched work to the workers
Enqueues the given job, then uses the supplied function to send the matched work to the workers
What an odd signature!
What an odd signature!
This is to match the 'as' function used to map http responses to some type 'T'.
in the event of a failure (exception or non-success server response), we can optionally retry. The 'retry' function is given first so that the second param list matches that of the 'as' result
Submit the job, then on the (expected) rediret response, route the work to the given worker using the 'sendToWorker'
Submit the job, then on the (expected) rediret response, route the work to the given worker using the 'sendToWorker'
the job to submit
the function used to send work to the worker (which may or may not have been the same request)
both the original work submission response and the response from the worker
Represents a something that will request work and get a response.
A normal workflow would be to request work from an exchange, have that work eventually matched with a worker, and then receive a 307 response, telling us where to go.
We then make a request (typically the original one, but perhaps not if it was e.g. a multipart request w/ a large upload or summat) to that worker.