fix(ptica): фильтр класса в velocity ссылался на алиас, которого нет в CTE (#2464-G) #2865

Merged

bot-backend merged 4 commits from fix/2464-velocity-class-filter into main 2026-08-13 17:46:29 +00:00

Conversation 3 Commits 4 Files changed 4 +97 -45

bot-backend commented 2026-08-13 11:44:36 +00:00

Collaborator

Copy link

Что

compute_velocity собирает фильтр класса как
AND COALESCE(o.obj_class, o.obj_class_fallback) = :obj_class и подставляет его
внутрь CTE latest_obj, где FROM domrf_kn_objects — без алиаса. Алиас o
появляется только во внешнем SELECT ... FROM latest_obj o.

Прод-EXPLAIN 13.08:

ERROR:  missing FROM-clause entry for table "o"
LINE 11:        AND COALESCE(o.obj_class, o.obj_class_fallback) = 'ко...

Насколько это горит

Не горит. Ветка мёртвая: единственный вызывающий — analyze_parcel
(parcels.py:3797) — obj_class не передаёт, значит class_filter всегда пустой
и в прод уходит валидный запрос. Так что это не «ломает сейчас», а «сломается
у первого, кто включит».

И сломается тихо: исключение ловит except Exception внутри compute_velocity,
функция возвращает None, вызывающий получает velocity_data = None — блок темпа
продаж просто исчезает из отчёта, оставив одну строку в логе.

Как

• Убран алиас: AND COALESCE(obj_class, obj_class_fallback) = :obj_class.
  Колонки внутри CTE неквалифицированы, domrf_kn_objects — единственный FROM.
• SQL вынесен в модульную константу _COMPETITORS_SQL_TMPL с {class_filter} —
  ровно затем, чтобы тест мог прогнать EXPLAIN по обеим подстановкам, а не
  только по той, что сегодня исполняется. Шаблон байт-в-байт прежний.

Проверка — реальная, не текстовая

tests/integration/test_analyze_parcels_sql.py делает EXPLAIN против живой прод-схемы.
Прогнал через SSH-туннель с TEST_DATABASE_URL, обе стороны:

со строкой из main (алиас o.)     1 failed, 3 passed
    psycopg.errors.UndefinedTable: missing FROM-clause entry for table "o"
после правки                      4 passed

То есть падает именно новая параметризация with_class_filter, а три контрольных
проверки зелёные с обеих сторон.

⚠️ В CI этот тест скипается — requires_test_db без TEST_DATABASE_URL. Прогон
выше сделан вручную против прод-PG; в пайплайне регрессию поймать нечем, пока
у CI нет базы.

• pytest tests/test_velocity.py tests/integration/test_analyze_parcels_sql.py — 29 passed, 4 skipped
• pytest -m integration через туннель — 4 passed
• ruff check — clean

Побочная находка, оставлена как комментарий

Правка делает ветку работоспособной — и первый, кто ей воспользуется, упрётся
в следующую ловушку: сравнение точное и регистрозависимое, а в проде классы
с заглавной и словарь шире ожидаемого (замер 13.08, region_cd = 66):

Комфорт   870      Премиум  13
(NULL)    504      Элит     12
Типовой   224      Стандарт  9
Бизнес     95      Элитный   4

Менять сравнение не стал — вызывающих нет, и любое «улучшение» было бы догадкой
о намерении. Написал это прямо в коде рядом с фильтром.

Шум в диффе

Один хунк в тесте — не мой: pre-commit пинит ruff v0.7.4, в backend/.venv 0.15.12
(#2864).

Refs #2464

## Что `compute_velocity` собирает фильтр класса как `AND COALESCE(o.obj_class, o.obj_class_fallback) = :obj_class` и подставляет его **внутрь CTE `latest_obj`**, где `FROM domrf_kn_objects` — без алиаса. Алиас `o` появляется только во внешнем `SELECT ... FROM latest_obj o`. Прод-EXPLAIN 13.08: ``` ERROR: missing FROM-clause entry for table "o" LINE 11: AND COALESCE(o.obj_class, o.obj_class_fallback) = 'ко... ``` ## Насколько это горит **Не горит.** Ветка мёртвая: единственный вызывающий — `analyze_parcel` (`parcels.py:3797`) — `obj_class` не передаёт, значит `class_filter` всегда пустой и в прод уходит валидный запрос. Так что это не «ломает сейчас», а «сломается у первого, кто включит». И сломается **тихо**: исключение ловит `except Exception` внутри `compute_velocity`, функция возвращает `None`, вызывающий получает `velocity_data = None` — блок темпа продаж просто исчезает из отчёта, оставив одну строку в логе. ## Как - Убран алиас: `AND COALESCE(obj_class, obj_class_fallback) = :obj_class`. Колонки внутри CTE неквалифицированы, `domrf_kn_objects` — единственный FROM. - SQL вынесен в модульную константу `_COMPETITORS_SQL_TMPL` с `{class_filter}` — ровно затем, чтобы тест мог прогнать EXPLAIN по **обеим** подстановкам, а не только по той, что сегодня исполняется. Шаблон байт-в-байт прежний. ## Проверка — реальная, не текстовая `tests/integration/test_analyze_parcels_sql.py` делает EXPLAIN против живой прод-схемы. Прогнал через SSH-туннель с `TEST_DATABASE_URL`, обе стороны: ``` со строкой из main (алиас o.) 1 failed, 3 passed psycopg.errors.UndefinedTable: missing FROM-clause entry for table "o" после правки 4 passed ``` То есть падает именно новая параметризация `with_class_filter`, а три контрольных проверки зелёные с обеих сторон. ⚠️ **В CI этот тест скипается** — `requires_test_db` без `TEST_DATABASE_URL`. Прогон выше сделан вручную против прод-PG; в пайплайне регрессию поймать нечем, пока у CI нет базы. - [x] `pytest tests/test_velocity.py tests/integration/test_analyze_parcels_sql.py` — 29 passed, 4 skipped - [x] `pytest -m integration` через туннель — 4 passed - [x] `ruff check` — clean ## Побочная находка, оставлена как комментарий Правка делает ветку **работоспособной** — и первый, кто ей воспользуется, упрётся в следующую ловушку: сравнение точное и регистрозависимое, а в проде классы с заглавной и словарь шире ожидаемого (замер 13.08, `region_cd = 66`): ``` Комфорт 870 Премиум 13 (NULL) 504 Элит 12 Типовой 224 Стандарт 9 Бизнес 95 Элитный 4 ``` Менять сравнение не стал — вызывающих нет, и любое «улучшение» было бы догадкой о намерении. Написал это прямо в коде рядом с фильтром. ## Шум в диффе Один хунк в тесте — не мой: pre-commit пинит ruff v0.7.4, в `backend/.venv` 0.15.12 (#2864). Refs #2464

bot-backend added 1 commit 2026-08-13 11:44:37 +00:00

fix(ptica): фильтр класса в velocity ссылался на алиас, которого нет в CTE ... e7d112b028

class_filter подставляется ВНУТРЬ latest_obj, где FROM — голый
domrf_kn_objects, а алиас `o` появляется только во внешнем SELECT.
Прод-EXPLAIN 13.08: `missing FROM-clause entry for table "o"`.

Ветка мёртвая — единственный вызывающий (analyze_parcel) obj_class не
передаёт, поэтому в проде это не стреляло. Стрельнуло бы тихо: исключение
глотает except в compute_velocity, функция возвращает None, и блок
velocity просто исчезает из отчёта с одной строкой в логе.

SQL вынесен в модульную константу _COMPETITORS_SQL_TMPL — чтобы
integration-тест мог прогнать EXPLAIN по ОБЕИМ подстановкам, а не только
по той, что сегодня исполняется.

Один хунк в тесте — не мой: pre-commit ruff v0.7.4 против 0.15.12 в venv (#2864).

Refs #2464

bot-backend referenced this pull request 2026-08-13 12:00:35 +00:00

EPIC: exhaustive line-by-line аудит backend ПТИЦЫ (2026-07-07) — 89 подтверждённых находок #2464

bot-backend closed this pull request 2026-08-13 12:19:04 +00:00

bot-backend reopened this pull request 2026-08-13 12:19:09 +00:00

bot-backend commented 2026-08-13 12:19:26 +00:00

Author

Collaborator

Copy link

Первый прогон backend-tests покрасился, но не на тестах. Достал лог задания
(actions/runs/7493/jobs/1):

Required test coverage of 65% reached. Total coverage: 74.57%
4646 passed, 28 skipped, 7 warnings in 911.53s (0:15:11)
...
12:01:24  docker exec cmd=[node .../hashfiles/index.js]
12:01:25  Skipping step 'Cache uv packages' due to 'success()'
12:01:31  🏁  Job failed

То есть шаг с pytest прошёл целиком, гейт покрытия пройден, а красным job стал
после него — в одном из двух if: always()-шагов (Coverage summary /
Снести тестовый Postgres), причём ни один из них не напечатал ни строки.

Локально полный сьют на этой же ветке: 4622 passed, 48 skipped.

Что я НЕ утверждаю: что это «просто флак». Причина шага не видна, вывода нет.
Что известно точно — падение не в тестах и не в покрытии. Перезапускаю прогон
(close/reopen), чтобы отличить воспроизводимое от разового. Если покраснеет так же —
заведу отдельную задачу на этот участок пайплайна.

Соседний сигнал: на PR #2868 в то же окно упал openapi-codegen-check (2m20s, на
установке). Проверил отдельно — схема app.openapi() на той ветке байт-в-байт
совпадает с main-эквивалентом, то есть правка тут ни при чём. Три прогона CI и сборка
деплоя одновременно на трёх раннерах одного VPS — похоже на нехватку ресурсов, но это
гипотеза, а не диагноз.

Первый прогон `backend-tests` покрасился, но **не на тестах**. Достал лог задания (`actions/runs/7493/jobs/1`): ``` Required test coverage of 65% reached. Total coverage: 74.57% 4646 passed, 28 skipped, 7 warnings in 911.53s (0:15:11) ... 12:01:24 docker exec cmd=[node .../hashfiles/index.js] 12:01:25 Skipping step 'Cache uv packages' due to 'success()' 12:01:31 🏁 Job failed ``` То есть шаг с pytest прошёл целиком, гейт покрытия пройден, а красным job стал **после** него — в одном из двух `if: always()`-шагов (`Coverage summary` / `Снести тестовый Postgres`), причём ни один из них не напечатал ни строки. Локально полный сьют на этой же ветке: **4622 passed, 48 skipped**. Что я НЕ утверждаю: что это «просто флак». Причина шага не видна, вывода нет. Что известно точно — падение не в тестах и не в покрытии. Перезапускаю прогон (close/reopen), чтобы отличить воспроизводимое от разового. Если покраснеет так же — заведу отдельную задачу на этот участок пайплайна. Соседний сигнал: на PR #2868 в то же окно упал `openapi-codegen-check` (2m20s, на установке). Проверил отдельно — схема `app.openapi()` на той ветке **байт-в-байт** совпадает с main-эквивалентом, то есть правка тут ни при чём. Три прогона CI и сборка деплоя одновременно на трёх раннерах одного VPS — похоже на нехватку ресурсов, но это гипотеза, а не диагноз.

bot-backend referenced this pull request 2026-08-13 12:24:30 +00:00

CI/деплой встали: диск VPS 94%, копятся buildx-билдеры (20 штук, до 2 месяцев) #2869

bot-backend commented 2026-08-13 12:24:55 +00:00

Author

Collaborator

Copy link

Причина найдена, и это не «флак» и не нехватка ЦПУ, как я предположил выше.

Диск на VPS был заполнен на 94%. Лог упавшего деплоя main:

#15 ERROR: mkdir /var/lib/buildkit/.../fs/app: no space left on device

Один дефицит объясняет все три сегодняшних покраснения: этот backend-tests (упал ПОСЛЕ
успешных тестов, в шаге без вывода), openapi-codegen-check на #2868 и обе сборки деплоя.

Накопитель — buildx-билдеры: каждый прогон CI создаёт новый и не убирает, на хосте их
скопилось 20 штук возрастом до двух месяцев, суммарно ~19 ГБ в _state-томах.
Вычистил кэш в восьми старых (buildctl prune --all, только регенерируемый кэш, ничего
не удалял): 132G → 117G использовано, свободно 13G → 28G. Разбор и план корневой
починки — #2869.

Прогон перезапущен уже на разгруженном хосте.

Причина найдена, и это не «флак» и не нехватка ЦПУ, как я предположил выше. **Диск на VPS был заполнен на 94%.** Лог упавшего деплоя main: ``` #15 ERROR: mkdir /var/lib/buildkit/.../fs/app: no space left on device ``` Один дефицит объясняет все три сегодняшних покраснения: этот `backend-tests` (упал ПОСЛЕ успешных тестов, в шаге без вывода), `openapi-codegen-check` на #2868 и обе сборки деплоя. Накопитель — buildx-билдеры: каждый прогон CI создаёт новый и не убирает, на хосте их скопилось **20 штук** возрастом до двух месяцев, суммарно ~19 ГБ в `_state`-томах. Вычистил кэш в восьми старых (`buildctl prune --all`, только регенерируемый кэш, ничего не удалял): **132G → 117G использовано, свободно 13G → 28G**. Разбор и план корневой починки — #2869. Прогон перезапущен уже на разгруженном хосте.

bot-backend referenced this pull request 2026-08-13 12:25:05 +00:00

fix(ptica): нет сделок за окно — цена не 0 ₽/м², а «нет данных» (#2464-B) #2868

bot-backend added 1 commit 2026-08-13 12:40:00 +00:00

Merge branch 'main' into fix/2464-velocity-class-filter ef6813d670

bot-backend commented 2026-08-13 12:40:22 +00:00

Author

Collaborator

Copy link

Поправка к предыдущему комментарию: дефицит диска эту красноту не объясняет.

Перезапуск прошёл уже на разгруженном хосте (28 ГБ свободно) и упал точно так же:

run 7503, vps-runner-2, 12:19-12:35
Required test coverage of 65% reached. Total coverage: 74.57%
4646 passed, 28 skipped, 7 warnings in 893.16s (0:14:53)
   ← девять секунд без единой строки
Skipping step 'Cache uv packages' due to 'success()'
🏁  Job failed

Диск объяснил падение деплоя и openapi-codegen-check — это подтвердилось (после чистки
оба зелёные). А вот про этот job я поспешил и записал его в ту же корзину. Он
воспроизводится.

Что проверил дальше и что этим исключил:

• Не пропал тест. Счёт 4647→4646 passed и 26→28 skipped смутил, но это объясняется
  базой: ветка отрезана от старого main, до мержа #2863, поэтому в ней нет
  test_price_avg_has_sanity_bounds и есть мои два новых (скипаются без БД).
  Сверил pytest --collect-only на обеих ветках — расхождение ровно эти три теста,
  ничего не исчезло.
• Не раннер как таковой. Тот же vps-runner-2 в 11:38 отработал зелёным (run 7491).
• Не шаг с покрытием и не удаление тестового Postgres по логу. Сравнил с зелёным
  прогоном: там после pytest идут Post Cache uv packages / Post Set up Python,
  здесь — сразу Skipping ... due to 'success()', то есть job уже НЕ success к моменту
  post-фазы. Оба шага if: always() в обоих прогонах не печатают ничего, так что по
  логу их различить нельзя — act не выводит баннеры для обычных run:-шагов.

Итог: падение после успешного pytest, в невидимом шаге, воспроизводимо на этой ветке
и не воспроизводится на трёх других за то же окно. Обновил ветку от base (в ней теперь
все три сегодняшних мержа) — если покраснеет и на свежей базе, заведу отдельную задачу
на диагностируемость этого участка: сейчас шаги if: always() молчат, и отличить
«упал шаг покрытия» от «упала уборка контейнера» нечем.

Поправка к предыдущему комментарию: **дефицит диска эту красноту не объясняет.** Перезапуск прошёл уже на разгруженном хосте (28 ГБ свободно) и упал **точно так же**: ``` run 7503, vps-runner-2, 12:19-12:35 Required test coverage of 65% reached. Total coverage: 74.57% 4646 passed, 28 skipped, 7 warnings in 893.16s (0:14:53) ← девять секунд без единой строки Skipping step 'Cache uv packages' due to 'success()' 🏁 Job failed ``` Диск объяснил падение деплоя и `openapi-codegen-check` — это подтвердилось (после чистки оба зелёные). А вот про этот job я поспешил и записал его в ту же корзину. Он **воспроизводится**. Что проверил дальше и что этим исключил: - **Не пропал тест.** Счёт 4647→4646 passed и 26→28 skipped смутил, но это объясняется базой: ветка отрезана от старого main, до мержа #2863, поэтому в ней нет `test_price_avg_has_sanity_bounds` и есть мои два новых (скипаются без БД). Сверил `pytest --collect-only` на обеих ветках — расхождение ровно эти три теста, ничего не исчезло. - **Не раннер как таковой.** Тот же `vps-runner-2` в 11:38 отработал зелёным (run 7491). - **Не шаг с покрытием и не удаление тестового Postgres по логу.** Сравнил с зелёным прогоном: там после pytest идут `Post Cache uv packages` / `Post Set up Python`, здесь — сразу `Skipping ... due to 'success()'`, то есть job уже НЕ success к моменту post-фазы. Оба шага `if: always()` в обоих прогонах не печатают ничего, так что по логу их различить нельзя — act не выводит баннеры для обычных `run:`-шагов. Итог: падение после успешного pytest, в невидимом шаге, воспроизводимо на этой ветке и не воспроизводится на трёх других за то же окно. Обновил ветку от base (в ней теперь все три сегодняшних мержа) — если покраснеет и на свежей базе, заведу отдельную задачу на диагностируемость этого участка: сейчас шаги `if: always()` молчат, и отличить «упал шаг покрытия» от «упала уборка контейнера» нечем.

bot-backend referenced this pull request 2026-08-13 16:34:58 +00:00

CI: backend-tests краснеет ПОСЛЕ зелёного pytest, и по логу нельзя понять, в каком шаге #2871

bot-backend referenced this pull request 2026-08-13 16:35:42 +00:00

ci: сделать видимыми два безмолвных шага после pytest (#2871) #2872

bot-backend added 1 commit 2026-08-13 16:53:53 +00:00

Merge branch 'main' into fix/2464-velocity-class-filter 8aacd1385e

bot-backend referenced this pull request 2026-08-13 17:13:14 +00:00

ci: печатать код возврата pytest явно (#2871) #2875

bot-backend referenced this pull request 2026-08-13 17:13:33 +00:00

CI: backend-tests краснеет ПОСЛЕ зелёного pytest, и по логу нельзя понять, в каком шаге #2871

Light1YT added 1 commit 2026-08-13 17:28:22 +00:00

test(ptica): объявить пропуск нового EXPLAIN-теста в skip_allowlist ... c9c7aab228

Причина четырёх красных прогонов backend-tests найдена, и это не инфраструктура:
сторож в tests/conftest.py (pytest_sessionfinish) роняет прогон, если тест
пропустился, но не объявлен в skip_allowlist.txt. Мои два новых
параметризованных EXPLAIN-теста скипаются без TEST_DATABASE_URL и в списке
не значились → session.exitstatus = 1 при зелёной сводке «4647 passed».

Сторож сработал ПРАВИЛЬНО и ровно за тем, зачем написан: пропуск без записи
неотличим от пройденной проверки. Его сообщение всё это время лежало в логе
на 1014-й строке, за две секунды до сводки, — я его не увидел, потому что
искал по английским «FAILED/ERROR» и смотрел хвост лога.

Почему проверку нельзя выполнить здесь (как требует шапка файла): EXPLAIN идёт
против КОПИИ ПРОДОВОЙ схемы через SSH-туннель, CI намеренно не задаёт
TEST_DATABASE_URL (комментарий в ci.yml у backend-tests). Где выполняется
вместо этого: вручную с туннелем — прогнан в этой ветке, 4 passed, и со
строкой из main падает 1 из 3.

Плюс backend/.gitignore: coverage.xml. Локальный прогон с --cov-report=xml
кладёт 1.2 МБ рядом с кодом; в этом заходе файл чуть не уехал в коммит и был
пойман только хуком check-added-large-files.

Refs #2464, #2871

bot-backend referenced this pull request 2026-08-13 17:28:48 +00:00

CI: backend-tests краснеет ПОСЛЕ зелёного pytest, и по логу нельзя понять, в каком шаге #2871

bot-backend merged commit c40261cb16 into main 2026-08-13 17:46:29 +00:00

bot-backend deleted branch fix/2464-velocity-class-filter 2026-08-13 17:46:30 +00:00

bot-backend referenced this pull request from a commit 2026-08-13 17:46:31 +00:00

fix(ptica): фильтр класса в velocity ссылался на алиас, которого нет в CTE (#2464-G) (#2865)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

Fable 5 ревью

Находки полного мульти-агентного ревью (Claude Fable 5, 2026-06-09)

  

GG-форсайт

Новое ТЗ от Ген Геныча (июнь 2026): Site Finder v2 — ИИ-прогноз продуктовой стратегии девелопера. Актуальный приоритет.

  

admin

Admin UI / internal tools / pipeline tracker

  

analytics

Аналитика данных / matching

  

auth

Authentication / authorization / multi-tenancy

  

automation

Автоматизация / cron / scheduler

  

bug

Something isn't working

  

business

Коммерческая воронка / пилоты / pipeline / реестр ПО

  

chore

Operational housekeeping

  

ci

Forgejo Actions / build pipeline

  

compliance

152-ФЗ / реестр ПО / legal / TOS

  

data

Data sources, parsers, ETL

  

data-moat

Уникальные данные — sales tracker, CRM aggregation

  

docs

README / runbooks / onboarding

  

duplicate

This issue or pull request already exists

  

dx

Developer experience / build speed

  

enhancement

New feature or request

  

feedback/max

Feedback from Max (Senior partner)

  

generative

Generative Design — concept generation engine

  

needs-discussion

Pending team sync / decision

  

needs-human

Human review/decision required

  

observability

Monitoring / metrics / logs / Sentry / Uptime

  

pause-bots

Kill-switch — all autonomous bots pause

  

performance

Latency / throughput / DB query tuning

  

priority/p0

Critical / production-blocker

  

priority/p1

High priority

  

priority/p2

Normal priority

  

priority/p3

Низкий приоритет (follow-up, tech-debt)

  

scope/backend

Backend Python — FastAPI, Celery, scrapers

  

scope/db

DB migrations, indexes, SQL

  

scope/devops

docker-compose, Caddy, workflows

  

scope/frontend

Frontend — Next.js, React, TypeScript

  

scope/qa

Tests, smoke, Playwright

  

scrapers

Скрапперы (Avito/Cian/Yandex/Rosreestr)

  

security

Security audit / secrets / vulnerabilities

  

site-finder

Site Finder scoring quality & data layer

  

stage/1

Stage 1: Generative MVP (нед 2-7)

  

stage/2

Stage 2: Site Finder MVP (нед 8-12)

  

status/blocked

Blocked — needs human intervention

  

status/done

Closed, completed

  

status/needs-analysis

Raw/fuzzy task filed by human — auto-analyst подхватывает: code-archeology + декомпозиция в actionable scope/* + status/ready (или split на под-issues)

  

status/needs-fix

Reviewer/QA вернул worker на доработку — worker сам чинит свой PR (fixup), НЕ требует human (в отличие от status/blocked)

  

status/qa

PR merged, awaiting smoke test

  

status/ready

Ready for pickup by worker bot

  

status/review

PR open, awaiting code review

  

status/wip

Work in progress (worker claimed)

  

tech-debt

Технический долг

  

tradein

Trade-In MVP проект

  

ux

User experience / responsive / conversion

  

week ревью 1

Week review 1 — находки multi-agent аудита проекта (2026-06-14)

  

wontfix

This will not be worked on

  

ИРД

Исходно-разрешительная документация — слой ограничений участка для analyze-таблицы

  

вторичка

Trade-In Estimator — проект оценки вторичного жилья

No labels

Fable 5 ревью

GG-форсайт

admin

analytics

auth

automation

bug

business

chore

ci

compliance

data

data-moat

docs

duplicate

dx

enhancement

feedback/max

generative

needs-discussion

needs-human

observability

pause-bots

performance

priority/p0

priority/p1

priority/p2

priority/p3

scope/backend

scope/db

scope/devops

scope/frontend

scope/qa

scrapers

security

site-finder

stage/1

stage/2

status/blocked

status/done

status/needs-analysis

status/needs-fix

status/qa

status/ready

status/review

status/wip

tech-debt

tradein

ux

week ревью 1

wontfix

ИРД

вторичка

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lekss361/gendesign#2865

No description provided.