yandex full-load: _leaf, обрезанный max_pages_per_bucket/CAP, пишется в done-леджер как complete — с containment (#3362) хвост крупного бакета не переобходится #3368

New issue

Closed

opened 2026-09-05 19:15:06 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-09-05 19:15:06 +00:00

Collaborator

Находка доводки PR #3362 (#3359). Там закрыта _degraded-ветка (on_bucket(…, complete=False) → не в done_buckets), но _leaf в providers/yandex/serp.py тоже обрезается max_pages_per_bucket/CAP и всё равно пишется как complete. У cian тот же случай считается честно: complete = pages_needed <= max_pages (cian/serp.py:~738). После containment (#3358/#3362) неполный ключ покрывает интервал и сливается с соседями → хвост крупного бакета на резюме не переобходится.

Лечение

В _leaf yandex — тот же флаг, что у cian: complete = pages_needed <= max_pages (или «дочитали до пустой страницы»). Риск, который надо взвесить: крупные бакеты, всегда упирающиеся в CAP, перестанут чекпоинтиться вовсе → резюм будет ходить по ним каждый раз. Честный вариант: бисекция должна дробить такой бакет дальше (как делает probe при total > cap), а не писать его неполным — проверить, почему бакет дошёл до leaf с pages_needed > max_pages.

Приёмка

Тест по значению: leaf, упёршийся в CAP → ключа в done_buckets нет (или бакет раздроблен);
Резюм по такому бакету делает >0 запросов;
Parity-фикстуры зелёные.

Refs #3359, PR #3362, #3358.

Находка доводки PR #3362 (#3359). Там закрыта `_degraded`-ветка (`on_bucket(…, complete=False)` → не в `done_buckets`), но `_leaf` в `providers/yandex/serp.py` тоже обрезается `max_pages_per_bucket`/CAP и всё равно пишется как complete. У cian тот же случай считается честно: `complete = pages_needed <= max_pages` (`cian/serp.py:~738`). После containment (#3358/#3362) неполный ключ покрывает интервал и сливается с соседями → хвост крупного бакета на резюме не переобходится. ## Лечение В `_leaf` yandex — тот же флаг, что у cian: `complete = pages_needed <= max_pages` (или «дочитали до пустой страницы»). Риск, который надо взвесить: крупные бакеты, всегда упирающиеся в CAP, перестанут чекпоинтиться вовсе → резюм будет ходить по ним каждый раз. Честный вариант: бисекция должна дробить такой бакет дальше (как делает probe при `total > cap`), а не писать его неполным — проверить, почему бакет дошёл до leaf с `pages_needed > max_pages`. ## Приёмка - [ ] Тест по значению: leaf, упёршийся в CAP → ключа в `done_buckets` нет (или бакет раздроблен); - [ ] Резюм по такому бакету делает >0 запросов; - [ ] Parity-фикстуры зелёные. Refs #3359, PR #3362, #3358.