Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

call_runner doesn't report the signer sessions it opens

Ouverte
#74 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
python
Domaine
api

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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/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.

Langage dominant
Python
Étoiles
1
Forks
8
Métriques de merge des PR
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de livepeer/livepeer-python-gateway

Toutes les issues de livepeer/livepeer-python-gateway

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.