Repository navigation
call_runner doesn't report the signer sessions it opens #74
Description
A caller of call_runner can't tell which signer sessions a call opened. That matters because the remote signer charges when it signs a payment, not when the runner delivers. A gateway that bills its users, or reconciles against Clearinghouse Batteries, has to link each charge to a call, including calls that failed after the payment was signed. The signer records each charge under the session's AuthID, but call_runner keeps its sessions private.
Proposed change
eliteprox#5 adds two things:
call_runner(..., on_payment_session=callback)callscallback(session)for each session the signer signs, before the paid request is sent.LivePaymentSession.auth_idreturns that session'sAuthID. It reads go-livepeer'sStatekey and livepeer/node'sstatekey.
Callers that don't pass the callback see no change. The PR adds 17 tests, covering repeated 402s, a runner failure after payment, a refused session and a cancelled call.
It replaces #71, which was closed so the change could target the fork's releases/m2. That branch matches main, and GitHub reports no conflicts. Could it come back here as a PR against main?
Known limit
RunnerSelectionCursor still fails over after a signed payment, so one job can pay twice. #70 tracks that.
Why we need it
The Network Engineering SPE build track matches each job attempt to Batteries usage by auth_id. Until this is released, the build track pins the fork.
Activity
j0sh commentedon Oct 14, 2026
The signer state is opaque and I'm not sure if we really want to turn that into a public compatibility requirement. Also, the AuthID might not always be there and I don't think it would be guaranteed to identify a specific session.
Would the ManifestID work in the callback? That is known to the SDK and would identify the orchestrator session and you can query it in the clearinghouse.
eliteprox commentedon Oct 14, 2026
Agreed on not decoding the signer state.
AuthIDonly identifies a session because Clearinghouse Batteries makes it one; the signer doesn't promise that.ManifestIDworks. Builder core attributes cost per job on(allocation_id, payment_session_id)(services/costs.pyin livepeer-builder-core), and that key stays. The callback reports each signed session'smanifest_id, and cost sync resolves it to thepayment_session_idon the matching Batteries usage rows. In our runs against public orchestrators the two mapped one-to-one.I'll update eliteprox#5 to replace
auth_idand the state decoding withLivePaymentSession.manifest_idfrom the 402 challenge, then open it here againstmain.One question: the orchestrator chooses the manifest, and the signer can't verify
Auth.SessionID. Is a freshManifestIDper challenge an orchestrator guarantee, or alivepeer/nodeimplementation detail? Either way, we can hold any manifest that maps to more than one Batteries session as uncertain (for per-job attribution, perallocation_idattribution remains unaffected). If it isn't guaranteed, we may want to consider having Batteries record our own per-attempt reference from a signer request header.eliteprox commentedon Oct 14, 2026
Opened #77 against
main.call_runner(..., on_payment_session=callback)reports each signed session, andLivePaymentSession.manifest_idis the manifest from the 402 challenge. The signer state is not decoded.The question from the previous comment is still open: is a fresh
ManifestIDper challenge an orchestrator guarantee, or alivepeer/nodeimplementation detail? Builder core will hold any manifest that maps to more than one Batteries payment session as uncertain, so per-job attribution stays honest either way. Per-allocation attribution does not depend on it.