fix: enable dev SRO collection and handle real lookup responses
All checks were successful
Mostovik Backend CI/CD / Tests and lint (push) Successful in 3m12s
Mostovik Backend CI/CD / Build linux/amd64 release images (push) Successful in 4m0s
Mostovik Backend CI/CD / Deploy and verify internal main (push) Has been skipped
Mostovik Backend CI/CD / Deploy customer main (push) Has been skipped
Mostovik Backend CI/CD / Deploy dev (push) Successful in 2m44s
All checks were successful
Mostovik Backend CI/CD / Tests and lint (push) Successful in 3m12s
Mostovik Backend CI/CD / Build linux/amd64 release images (push) Successful in 4m0s
Mostovik Backend CI/CD / Deploy and verify internal main (push) Has been skipped
Mostovik Backend CI/CD / Deploy customer main (push) Has been skipped
Mostovik Backend CI/CD / Deploy dev (push) Successful in 2m44s
This commit is contained in:
@@ -7,7 +7,7 @@
|
||||
|
||||
## Доступ и пределы запросов
|
||||
|
||||
По умолчанию сбор закрыт. Для открытия необходимы одновременно
|
||||
По умолчанию сбор закрыт. Для production необходимы одновременно
|
||||
`SRO_UPSTREAM_ACCESS_APPROVED=true` и непустой
|
||||
`SRO_UPSTREAM_APPROVAL_REFERENCE` — ссылка/номер документированного разрешения
|
||||
владельца сайта на автоматизированные query/search запросы. Согласование разработки
|
||||
@@ -15,13 +15,30 @@
|
||||
должны быть совместимы с настройками загрузчика; более строгие пределы задаются
|
||||
перед включением. Секреты в approval reference хранить нельзя.
|
||||
|
||||
15.09.2026 пользователь явно изменил требование: «Изменить требование и включить
|
||||
сбор на dev». Только для dev предусмотрен отдельный opt-in
|
||||
`SRO_DEV_COLLECTION_ENABLED=true`. Он разрешает сбор без изменения
|
||||
`SRO_UPSTREAM_ACCESS_APPROVED` и `SRO_UPSTREAM_APPROVAL_REFERENCE` и не обозначает
|
||||
разрешение владельца upstream. По умолчанию флаг `false`; на production он должен
|
||||
оставаться выключенным. Код разрешает запуск при включённом dev-флаге **или** при
|
||||
наличии обоих параметров согласованного доступа. Для отключения dev-исключения
|
||||
верните флаг в `false` и примените конфигурацию web/worker.
|
||||
|
||||
Исходный [source-first контракт](source-integration/sources/sro-membership-check/backend-api.md)
|
||||
с ограничением production refresh и
|
||||
[документ замечаний](source-integration/source-records-backend-improvements.md)
|
||||
с исходным ответом `409` сохранены как происхождение требования. Настоящее
|
||||
изменение относится только к включению сбора на dev; ограничения запросов,
|
||||
привязки организаций и публикации данных сохраняются.
|
||||
|
||||
Оба ручных entrypoint проверяют этот gate до enqueue; task и HTTP клиент повторяют
|
||||
проверку перед внешним IO. Закрытый gate возвращает typed
|
||||
`409 upstream_access_not_approved`. Если разрешение отозвано после постановки,
|
||||
`409 upstream_access_not_approved`. Если gate закрыт после постановки,
|
||||
job завершается с ошибкой, без успешной пустой публикации.
|
||||
|
||||
| Настройка | По умолчанию | Значение |
|
||||
| --- | --- | --- |
|
||||
| `SRO_DEV_COLLECTION_ENABLED` | `false` | Явное включение сбора только на dev, отдельно от подтверждения разрешения upstream. |
|
||||
| `SRO_REQUEST_INTERVAL_SECONDS` | `3` | Минимум 3 секунды между запросами, включая redirects/retries; можно увеличить. |
|
||||
| `SRO_HTTP_MAX_RESPONSE_BYTES` | `2097152` | Предел распакованного тела одного ответа. |
|
||||
| `SRO_HTTP_TIMEOUT_SECONDS` | `30` | Read timeout; connect timeout 10 секунд. |
|
||||
@@ -33,7 +50,27 @@ HTTP клиент делает не более трёх попыток при т
|
||||
ответами; каждый адрес проверяется до обращения. Разрешён только HTTPS без
|
||||
credentials/нестандартного порта, на `reestr-sro.ru` и его поддоменах. Переменные
|
||||
окружения HTTP proxy автоматически не используются. HTML/query с идентификаторами
|
||||
не выводится в application logs.
|
||||
не выводится в application logs. User-Agent — нейтральный
|
||||
`Mostovik SRO integration`, без утверждения о разрешении upstream.
|
||||
|
||||
Наблюдаемый 15.09.2026 ответ lookup `404` учитывается как отсутствие членства
|
||||
только для `/proverka_dopuska/` с одним `q` из 10 или 13 цифр, при точном title
|
||||
«Проверка членства в реестре СРО, проверить допуск организации в СРО по ИНН»,
|
||||
единственном h1 «Запрашиваемая страница на сайте отсутствует.» и отсутствии
|
||||
`table.sro-members`. Конечный `q` после redirects должен совпадать с запрошенным
|
||||
идентификатором организации; иначе запуск отклоняется с
|
||||
`sro_lookup_identifier_mismatch`. Другой HTML при lookup `404` отклоняется с
|
||||
`sro_lookup_response_unrecognized`. На остальных путях `404` сохраняет прежнее
|
||||
значение `sro_page_not_found`, в том числе на страницах даты допуска.
|
||||
|
||||
Этот шаблон `404` неоднозначен: он сам по себе не доказывает отсутствие членства.
|
||||
Поэтому если **все** кандидаты получили такой ответ и ни один lookup не вернул
|
||||
успешно разобранный `200`, весь запуск отклоняется с `sro_ambiguous_empty_scan`
|
||||
до публикации и изменения checkpoints; прежние записи сохраняются. Смешанный
|
||||
запуск с корректным `200` может учитывать распознанные отрицательные ответы.
|
||||
Приватный raw manifest сохраняет `status_code`; artifact metadata содержит
|
||||
`recognized_lookup_404_count` и `successful_lookup_200_count`. Предел размера
|
||||
ответа действует и для lookup `404`. Дата реестра из error-шаблона не извлекается.
|
||||
|
||||
## Публикация и обновление
|
||||
|
||||
|
||||
Reference in New Issue
Block a user