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

live runner: metered session dies after ~600 tickets because ticket params are never rotated

Aperta
  • Qualcosa non va?
#62 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
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
api, backend, payments

Direzione di ricerca

Inizia in src/livepeer_gateway/remote_signer.py leggendo send_payment(), _payment_request() e run_payments(); confronta il loro comportamento con i dettagli della risposta e del flusso di aggiornamento descritti qui. Usa live-runner-test/realtime_transcription_soak.py per riprodurre il problema della sessione. Il lavoro è completato quando i pagamenti riusciti mantengono aggiornati i parametri del ticket o si riprendono da un nonce del mittente non valido, e le sessioni lunghe non terminano più al raggiungimento del limite del nonce.

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

Descrizione

Summary

A metered live-runner session dies after ~600 signed tickets because the SDK reuses the ticket params from the original 402 challenge for the session's whole life. The orchestrator's recipient caps distinct sender nonces per recipientRand at 600 (pm/recipient.go:26, maxSenderNonces), so once that many tickets have been signed against one params set, every further payment is rejected:

HTTP 400 ... body='invalid ticket senderNonce: too many values sender=0x491F...E0DB nonce=611'

The SDK retries the same doomed nonce sequence, the orchestrator releases the session a few seconds later, and the stream ends.

How fast this happens is set by the orchestrator's ticketEV, not by anything the client controls: tickets per payment is fee / ticketEV. Measured against two orchestrators serving livepeer-example/realtime-transcription at the same price (73562861230 wei/s):

orch faceValue winProb ticketEV tickets/payment 600 reached after
0xdc28F2… 1.196e15 8.361e-04 1e12 wei 1.0 ~600 payments (~30 min)
0x9727b4… 1.196e15 8.361e-06 1e10 wei 30.4 ~20 payments (~60 s)

Both configurations are legal. Payment cadence is irrelevant: total tickets is spend / ticketEV however you batch them.

Root cause

src/livepeer_gateway/remote_signer.py (same on main and rs/live-runner-session-payments):

  • send_payment() POSTs to the session payment URL and discards the response (_post_empty, line 273). go-livepeer returns PaymentResult{Info: oInfo} on every successful payment (server/ai_http.go:569), and that OrchestratorInfo carries fresh TicketParams with a new seed — i.e. a new recipientRand that would reset the nonce map.
  • _payment_request() always sends "orchestrator": self._challenge.payment_params, the params from the initial 402, for the entire session.
  • run_payments() treats any 4xx except 408/429 as fatal, so the nonce error stops funding instead of refreshing.

Refresh is wired up, but only for one trigger: the signer returns HTTP 480 when it knows params expired, raising SignerRefreshRequired → POST /refresh-payment. The 600-nonce cap is a recipient-side limit the signer cannot see, so it never fires. That is why the 1e12 ticketEV orchestrator survives: its params expire (40 blocks) and get refreshed before 600 tickets accumulate. It is timing, not correctness — a long enough session there fails identically.

Fix

  1. Preferred: consume PaymentResult.Info.TicketParams from each successful payment and use it for the next cycle. Matches what the orchestrator already sends and is safe at any ticketEV.
  2. Minimum: treat invalid ticket senderNonce like ticketparams expired — call /refresh-payment and retry. go-livepeer's own gateway does exactly this (server/ai_process.go:1556, isInvalidTicketSenderNonce).

Reproduction

24h WebSocket soak of livepeer-example/realtime-transcription, one held session streaming 16 kHz PCM, signer at a $0.50/hour cap:

  • against the 1e10 ticketEV orchestrator: 200 sessions in 5.2h, lifetimes median 87s / min 86s / max 88s, first payment failure at a constant +67s, 1,182 payment failures, 197 forced reconnects. Deterministic, not flaky.
  • against the 1e12 ticketEV orchestrator: 1 session, unbroken 5.17h, 4 TicketParams expired failures, all self-recovered.

The socket itself never faulted in either lane: 0 stalls, 0 transcript gaps, 0 socket errors across 9.9h of streaming. The only failure mode is payments.

Harness: live-runner-test/realtime_transcription_soak.py.

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.