Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

call_runner doesn't report the signer sessions it opens

Aperta
  • Qualcosa non va?
#74 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
api

Direzione di ricerca

Start from call_runner and the LivePaymentSession class, where the signer sessions are opened and where auth_id would be read. The change is already in progress as eliteprox/livepeer-python-gateway#5 and needs re-submission against main, so check with maintainers before writing code. Read RunnerSelectionCursor too, since failover after a signed payment is a known limit tracked in #70. Done means the on_payment_session callback fires before each paid request, auth_id is returned from the State and state keys, and callers who omit the callback see no change.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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/livepeer-python-gateway#5 adds two things:

  • call_runner(..., on_payment_session=callback) calls callback(session) for each session the signer signs, before the paid request is sent.
  • LivePaymentSession.auth_id returns that session's AuthID. It reads go-livepeer's State key and livepeer/node's state key.

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.

Lingua principale
Python
Stelle
1
Fork
8
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di livepeer/livepeer-python-gateway

Tutte le issue di livepeer/livepeer-python-gateway

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.