Skip to content

fix(pipeline): bound GitHub budget starvation #78

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ivanarama merged 1 commit into from
Sep 17, 2026
Merged

fix(pipeline): bound GitHub budget starvation #78

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -795,6 +795,7 @@ Worker публикует heartbeat в общей SQLite БД. Активный
"reset_grace_seconds": 60,
"lease_seconds": 900,
"busy_retry_seconds": 30,
"starvation_timeout_seconds": 900,
"unavailable_retry_seconds": 300
},
"priority_control": {
Expand Down Expand Up @@ -909,6 +910,16 @@ claim одной задачи происходят в одной SQLite-тран
получат одно вхождение. Без `scheduler` остаётся прежний порядок
`priority → created_at → id`.

Полоса становится выделенным физическим слотом только когда
`PP_CONCURRENCY` не меньше числа настроенных `lanes`. При меньшей
конкурентности это остаются детерминированные предпочтения свободных слотов, а
не резерв ёмкости; отдельную гарантию от ожидания GitHub API даёт описанный ниже
`github_budget.starvation_timeout_seconds`.
При включённом starvation timeout конфигурации `scheduler` нужна хотя бы одна
recovery-полоса с `borrow: true`; иначе lane policy считается невалидной и worker
откатывается к глобальному claim, чтобы переименованная очередь не удерживала
admission-эстафету навсегда.

#### Параллельные реплики REVIEW

Очередь REVIEW может явно владеть несколькими независимыми сериями. Для этого
Expand Down Expand Up @@ -1081,6 +1092,20 @@ skill остаётся дорогим: стартовые `3750 + 250` Core со
аварии процесса. Приоритетная эстафета сохраняется до фактического резервирования
бюджета, поэтому уже запущенный менее приоритетный этап не обгоняет разбуженный.
Жёсткий reset живого лимита этим сигналом не сокращается.
Необязательный `starvation_timeout_seconds` (по умолчанию `0`, выключено;
рекомендуемое начальное значение `900`) ограничивает голодание при непрерывном
потоке более приоритетных запусков. После дедлайна самая старая задача с
durable reservation/priority/scan handoff (но не с ожиданием живого quota reset)
получает временную admission-эстафету:
новые резервы ждут, пока текущие освободятся и она зарезервирует бюджет. Более
новая задача не обходит более старую; при одинаковом времени ожидания порядок
задают priority и id. Эстафета меняет только порядок: исходный priority задачи,
`minimum_remaining` и `priority_one_headroom` не меняются, поэтому P3/P4 не
заимствуют запас P1. Если без чужих reservations живого лимита всё равно мало,
задача переходит в обычное ожидание reset и сразу освобождает эстафету. Для
профилей с общим GitHub token действует минимальный положительный timeout;
отсутствие настройки во всех профилях полностью сохраняет прежнюю строгую
приоритетную семантику.
Недоступный лимит, повреждённый ledger или некорректная конфигурация работают
fail-closed на `unavailable_retry_seconds`. Для профилей с одним GitHub token и
`PP_DATA_DIR` PromptPilot покомпонентно применяет самый большой настроенный hard
Expand Down
Loading
Loading