shopify_draft_proxy/proxy/passthrough
Substrate for forwarding a DraftProxy request to upstream Shopify
verbatim and returning the upstream response unchanged.
Lives here (separate from draft_proxy.gleam) so domain handlers
can call passthrough_sync themselves when their per-operation
logic decides upstream is the right answer — without importing
draft_proxy and creating a cycle. The dispatcher in
draft_proxy.gleam also calls this for its own substrate-level
fallbacks (operations marked Passthrough in the registry; root
fields with no local dispatcher implemented).
On the Erlang target, passthrough_sync always works: it uses the
installed upstream_transport if any, otherwise the real
upstream_client.send_sync HTTP shim. On the JavaScript target,
the real fetch is async, so passthrough_sync only succeeds when a
SyncTransport (typically a parity cassette) is installed; without
one it returns the documented 501 sentinel telling the caller to
use process_request_async.
Values
pub fn passthrough_async(
proxy: proxy_state.DraftProxy,
request: proxy_state.Request,
) -> promise.Promise(
#(proxy_state.Response, proxy_state.DraftProxy),
)
pub fn passthrough_sync(
proxy: proxy_state.DraftProxy,
request: proxy_state.Request,
) -> #(proxy_state.Response, proxy_state.DraftProxy)
pub fn passthrough_with_send_async(
proxy: proxy_state.DraftProxy,
request: proxy_state.Request,
send: fn(request.Request(String)) -> promise.Promise(
Result(commit.HttpOutcome, commit.CommitTransportError),
),
) -> promise.Promise(
#(proxy_state.Response, proxy_state.DraftProxy),
)
Test seam: dispatch a passthrough request with an injected send
closure so unit tests don’t need a real HTTP server. Callers should
generally use passthrough_sync/2 and install a transport via
with_upstream_transport instead.