Runner selection: pool size, failure classification and payment_sent on rejections
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, distributed-systems
Research direction
Start with the proposal, then read RunnerSelectionCursor.next in src/livepeer_gateway/selection.py and discover_orchestrator_runners in src/livepeer_gateway/discovery.py. Trace the related reserve_session change from #37 and the still-open #36 before deciding the pool, ordering, failure categories, and payment state. Done means the requested selection and rejection information is defined and implemented consistently.
Written by the indexing model from the issue text.
Description
The builder engine (proposal) will build its runner failover on runner_selector / RunnerSelectionCursor. Three things are missing for that.
Today (main at 44df061):
RunnerSelectionCursor.nexttries candidates in discovery order and moves on after any exception.- Its candidates come from
discover_orchestrator_runners, which returns the runners of the first batch of five orchestrators that has any. - There is no setting for how many candidates to consider, no ordering hook, and no way to tell a capacity refusal from other failures.
RunnerRejectionrecords only the URL and a reason string, so a caller cannot tell whether a failed attempt had already paid. With a session prepay, a start refused on capacity has paid.
Request:
- A maximum pool size, so selection can consider runners across more than one orchestrator batch.
- An ordering hook, or ranking inputs.
- A classified failure reason: capacity refusal versus unreachable versus other.
- Whether payment was sent, on each rejection.
Related: #37 forwarded orchestrators through reserve_session. That change is on main, but #36 is still open.
- Dominant language
- Python
- Stars
- 1
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from livepeer/livepeer-python-gateway
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
livepeer/livepeer-python-gateway#64 · 1 comment ·
-
Improvement
Difficulty 1/5 Under an hour Newbie friendliness 68/100
livepeer/livepeer-python-gateway#27 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 1/5 Under an hour Newbie friendliness 70/100
livepeer/livepeer-python-gateway#12 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 76/100
livepeer/livepeer-python-gateway#62 · 3 comments ·
All issues in livepeer/livepeer-python-gateway
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
TencentCloud/Octop#1577 · 1 comment ·
Maintainers usually reply within 1 day
-
bug frontend
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
PedestrianDynamics/pyFDS-Evac#552 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
resend/resend-skills#144 ·
Maintainers usually reply within 1 day
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 68/100