Module marketplace fails to load: getAvailableModules returns HTTP 400 on fresh install

[jorikfon]

Description

English Description

Multiple users report that the module marketplace fails to load for at least ~3 days, even on a clean, fresh install. The browser console shows the REST call to list available modules returning HTTP 400:

/pbxcore/api/v3/modules:getAvailableModules:1
  Failed to load resource: the server responded with a status of 400 ()

API: Server gave an error: error /pbxcore/api/v3/modules:getAvailableModules

Current Implementation Overview

• ❌ getAvailableModules returns HTTP 400; the marketplace page cannot list modules.
• Reproduces on a brand-new clean install (so it is not a per-install corruption).

Root cause unknown — needs triage

This may be a backend/marketplace-server-side problem rather than a defect in Core's PHP code (the reporter himself asked "Provider?"). Please confirm whether:

1. The marketplace/license backend is returning 400 to the request MikoPBX sends, or
2. Core builds a malformed request (e.g. a missing/invalid board parameter — cf. In key outgoing HTTP requests, send the board parameter #940) that the backend rejects with 400.

Capturing the actual outbound request and the backend response body is the first triage step.

Proposed Changes / Solution

• Reproduce and capture the full request/response for getAvailableModules.
• If backend-side: route to the marketplace service owners.
• If Core-side: fix the request construction and add an integration check.

Benefits

• Restores the ability to browse/install modules on fresh installs of the current release.

---

Русское описание

Несколько пользователей сообщают, что маркетплейс модулей не загружается уже как минимум ~3 дня, даже на чистой свежей установке. В консоли браузера REST‑запрос списка доступных модулей возвращает HTTP 400:

/pbxcore/api/v3/modules:getAvailableModules:1
  Failed to load resource: the server responded with a status of 400 ()

API: Server gave an error: error /pbxcore/api/v3/modules:getAvailableModules

Обзор текущего поведения

• ❌ getAvailableModules возвращает HTTP 400; страница маркетплейса не может отобразить модули.
• Воспроизводится на абсолютно чистой установке (значит, дело не в повреждении конкретной инсталляции).

Причина неизвестна — требуется анализ

Это может быть проблема на стороне бэкенда/сервера маркетплейса, а не дефект PHP‑кода Core (сам автор спросил «Провайдер?»). Нужно установить:

1. Бэкенд маркетплейса/лицензий возвращает 400 на запрос, который шлёт MikoPBX, или
2. Core формирует некорректный запрос (например, отсутствует/неверен параметр board — ср. In key outgoing HTTP requests, send the board parameter #940), который бэкенд отклоняет с 400.

Первый шаг — снять реальный исходящий запрос и тело ответа бэкенда.

Предлагаемые изменения

• Воспроизвести и снять полный запрос/ответ для getAvailableModules.
• Если проблема на бэкенде — передать владельцам сервиса маркетплейса.
• Если в Core — исправить формирование запроса и добавить интеграционную проверку.

---

Reported in: Telegram «MikoPBX community», user @oleg_cg (Олег), 2026-06-11. Reproduces on clean fresh install.
Status: needs-triage — root cause may be server-side (marketplace backend), not Core.

[miko-service-bot]

Triage summary / Анализ

1. Что именно отправляется на releases.mikopbx.com

GetAvailableModulesAction::main() → POST https://releases.mikopbx.com/releases/v1/mikopbx/getAvailableModules
(src/PBXCoreREST/Lib/Modules/GetAvailableModulesAction.php:96-112) с JSON-телом:

{
  "PBXVER":  "<version, '-dev' stripped>",
  "LANGUAGE":"<WEB_ADMIN_LANGUAGE>",
  "ARCH":    "arm64" | "amd64",
  "TYPE":    "docker" | "lxc" | "bare",
  "BOARD":   "<contents of /etc/miko-board>" | "unknown",
  "DOCKER_NETWORK_MODE": "native|host|bridge|unknown"
}

→ BOARD/ARCH (#940) уже отправляются, добавлены через System::getPlatformInfo() (src/Core/System/System.php:584-596). На clean-install без /etc/miko-board уходит BOARD=unknown (System.php:533-545) — стоит проверить, не отбивает ли бэкенд именно это значение.

2. Откуда в браузере 400 (важно для триажа)

Сам action не проставляет httpCode при провале — на 3 неудачных попытках возвращается success=false, data=[]. Через BaseController это бы дало HTTP 422 (line 271-274).

HTTP 400 на фронте возникает другим путём — REDIS_JOB_PROCESSING_ERROR (BaseController.php:254-258, default 400). То есть в воркере выбрасывается исключение. Кандидаты:

• MutexProvider::synchronized('getAvailableModules', …, 10, 30) бросает RuntimeException если не смог взять lock за 10 с (MutexProvider.php:57-71). При тайм-аутах upstream 15 с × 3 попытки = 45 с, а TTL lock — 30 с → второй параллельный запрос гарантированно отвалится.
• Любое другое Throwable вне catch внутри action.

Это согласуется с симптомом «массово, на clean-install» — первый клиент висит в upstream, остальные получают 400 через mutex timeout.

3. Сравнение с близким эндпоинтом

CheckIfNewReleaseAvailableAction отдельно реализует degraded result: при недоступности upstream возвращает HTTP 200 + checkSucceeded:false, чтобы дашборд не падал (CheckIfNewReleaseAvailableAction.php:171-185).

GetAvailableModulesAction такого fallback не имеет — отсюда жёсткий 400 на UI вместо «маркетплейс временно недоступен».

4. Статус develop

git diff origin/master..origin/develop по GetAvailableModulesAction.php и System.php — пусто. В develop фикса нет, последние коммиты по модулям (4a38c0a, a757f6e) трогают enable/disable/install, не marketplace.

5. Покрытие тестами

tests/api/test_39_modules.py:19-26 — тест есть, но он толерантен к ошибкам (try/except, принимает 501/404), верхний путь не валидирует. Реальный сетевой контракт с releases.mikopbx.com тестами не покрыт.

6. Что нужно для разбора

Запрашиваю у репортёра/тех, кто воспроизводит:

• Версия MikoPBX (/etc/version или из UI). Без неё не двинуться.
• Тип установки: ISO / Docker / Proxmox LXC.
• Архитектура и BOARD: вывод cat /etc/miko-board 2>/dev/null; uname -m.
• Серверный лог, фильтр по GetAvailableModulesAction:

  grep -iE 'GetAvailableModules|getAvailableModules|releases\.mikopbx' \
    /storage/usbdisk1/mikopbx/log/system/messages | tail -200

  Ожидаем увидеть либо API request failed with code: 4xx (тогда бэкенд режет), либо Attempt N/3 failed: … (сеть/таймаут), либо исключение mutex.
• Сырой исходящий запрос/ответ на releases.mikopbx.com:

  PBXVER=$(grep -oP "INSERT INTO m_PbxSettings.*PBX_VERSION[^']*'\K[^']+" /cf/conf/mikopbx.db.sql 2>/dev/null || echo UNKNOWN)
  BOARD=$(cat /etc/miko-board 2>/dev/null || echo unknown)
  ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
  curl -sS -i -X POST https://releases.mikopbx.com/releases/v1/mikopbx/getAvailableModules \
    -H 'Content-Type: application/json' \
    -d "{\"PBXVER\":\"$PBXVER\",\"LANGUAGE\":\"en\",\"ARCH\":\"$ARCH\",\"TYPE\":\"bare\",\"BOARD\":\"$BOARD\",\"DOCKER_NETWORK_MODE\":\"native\"}"

⚠️ Репозиторий публичный. Если в логах окажутся токены/IP/имена клиентов — не вставлять сюда, отправить на support@mikopbx.com со ссылкой на этот issue.

Предварительные выводы

Что	Оценка
Корневая причина	Скорее всего upstream-side: releases.mikopbx.com отдаёт 4xx или зависает; Core этим триггерит mutex-таймаут и сам отдаёт 400. Подтвердится после curl к бэкенду из п. 6.
Состояние develop	code-analysis-only: следов фикса нет, исправление потребуется отдельно.
Покрытие тестами	no-tests — интеграционная проверка контракта с release-сервером отсутствует.
Severity	High — на clean-install ломает basic UX маркетплейса; voice-функционал не затронут.
Workaround	Нет на стороне пользователя. На стороне Core кандидаты на доработку: (a) degraded-result как в CheckIfNewReleaseAvailableAction, (b) сократить mutex timeout/TTL под реальный upstream timeout, (c) логировать тело 4xx-ответа upstream целиком.

Рекомендуемые labels

area:rest-api, area:modules, needs-info (версия + лог), no-tests, code-analysis-only, severity:high.

Рекомендация

needs-info + параллельно проверка статуса бэкенда releases.mikopbx.com владельцами сервиса. PR в Core (degraded-result + расширенное логирование upstream) делать только по явному запросу мейнтейнера — текущая первопричина с большой вероятностью вне репозитория.

---

Generated by Claude Code