Виправлені помилки

Помилки попередніх версій і версія, з якої їх виправлено. Якщо ви на зачепленій версії — оновіться або скористайтеся обхідним шляхом. Актуальні помилки — на сторінці Актуальні помилки.

<include>(.issues/post-response-only-http.md)

<include>(.issues/adapter-routes-overwritten.md)

<include>(.issues/autowire-method-arguments.md)

<include>(.issues/info-concat-ignored.md)

<include>(.issues/deprecated-not-in-openrpc.md)

<include>(.issues/xhr-requests-empty.md)

<include>(.issues/response-cache-shared.md)

<include>(.issues/notifications-without-fpm.md)

<include>(.issues/batch-process-cpu-and-token.md)

<include>(.issues/from-integer-becomes-float.md)

<include>(.issues/terminate-listeners-skipped.md)

<include>(.issues/versioned-routes-issues.md)

<include>(.issues/callback-forwarded-all-headers.md)

<include>(.issues/regressions-8-1.md)

rpc.post_response запускалась не для всіх виконаних запитів

Симптом.

• До 10.4.2: на кожен HTTP-запит чи консольну команду подія генерувалась один раз — для останнього rpc.pre_response. У процесному batch її отримував лише один запит, а не кожен виконаний.
• 10.2.x — 10.4.1: на kernel.terminate подія запускалась лише тоді, коли carrier — RpcFromHttp цього HTTP-запиту. Для викликів через адаптери (REST тощо) вона не генерувалась, тож не працювали інвалідація #[RPC\CacheRelation] і виконання notifications / callback. Для консольних команд подія запускалась.

Виправлення. Запити збираються в PostResponseQueue, і подія генерується один раз на кожен успішно виконаний запит — для будь-якого carrier-а (IRpcHttpCarrier або виконання через RpcExecutor) і для кожного елемента batch.

Маршрути адаптера затирали один одного в різних групах API

Симптом. Два імпорти того самого router.yaml адаптера (наприклад, /mcp і /mcp/internal) давали однакові назви маршрутів, і другий імпорт затирав перший.

Виправлення. Адаптер реєструє свій router.yaml через IApiRouteImport; кожен імпорт отримує назви маршрутів з префіксом групи.

#[Autowire] в аргументах RPC-методу не працював

Симптом. Сервіс, позначений #[Autowire] в аргументі RPC-методу, не підставлявся.

Причина. RpcServiceMapPass::processParams() пропускав кожен типізований параметр, тому такі аргументи не реєструвалися в локаторі методу.

Обхідний шлях для старих версій. Ін'єкція через конструктор.

#[RPC\Info(concat: …)] ігнорувався

Симптом. Методи завжди мали роздільник . незалежно від concat.

Важливо при оновленні. Після виправлення concat знову застосовується: якщо його задано, а клієнти викликають методи через ., назви методів зміняться. Оновіть клієнтів або приберіть concat.

Застарілі методи не позначалися в OpenRPC

Симптом. Методи з @deprecated або #[\Deprecated] не отримували "deprecated": true в документації, хоча прапорець збирався в Service::isDeprecated().

Причина. OpenRpcAdapter не передавав прапорець у OpenRpcSpecBuilder::buildMethod().

XHR-запити отримували порожню відповідь

Симптом. POST із заголовком X-Requested-With: XMLHttpRequest (наприклад, jQuery $.ajax) отримував порожню відповідь 200, і метод не викликався.

Виправлення. Порожню відповідь тепер отримує лише CORS preflight OPTIONS.

Кеш відповідей був спільний для різних реалізацій і версій з однаковою назвою

Симптом. Однойменні методи різних версій API або різних груп, реалізовані різними класами, могли отримати кешований результат одне одного.

Виправлення. Ключ кешу відповідей містить реалізацію (Class::method) і версію API. Після оновлення наявний кеш один раз не знайдеться і заповниться заново.

Notifications не виконувались без PHP-FPM

Симптом.

• 10.1.x: поза PHP-FPM (Apache mod_php, вбудований сервер PHP) виклик fastcgi_finish_request() завершувався помилкою, яку бандл мовчки перехоплював, тож rpc.post_response не генерувалась і notification не виконувалась узагалі.
• 10.2.x: виклик захищено перевіркою function_exists(), але без ignore_user_abort() PHP обривав виконання, якщо клієнт уже закрив з'єднання, і notification мовчки пропадала.

Крім того, виконання друкувало запит і відповідь у stdout через echo.

Виправлення. Notification виконується в будь-якому SAPI, навіть якщо клієнт закрив з'єднання; виконання логується через LoggerInterface::info().

Процесний batch займав ядро CPU і передавав токен у командному рядку

Симптом. Під час процесного batch цикл очікування займав 100% ядра; токен і тіло запиту передавались дочірнім процесам аргументами командного рядка й були видні в списку процесів.

Виправлення. Без активного циклу очікування; токен передається через змінну UFO_RPC_TOKEN, запит — через stdin.

@FROM перетворював ціле число на дробове

Симптом. Цілий результат елемента batch при підстановці в інший елемент через @FROM:<id>(<поле>) ставав дробовим, і метод з параметром int отримував помилку типу.

Terminate-лістенери застосунку не виконувались після RPC-запитів

Симптом. Лістенери kernel.terminate / console.terminate застосунку (відправка пошти, flush логів, Sentry тощо) не спрацьовували після RPC-запитів.

Причина. Бандл зупиняв поширення цих подій.

Важливо при оновленні. Перевірте лістенери, які раніше мовчки пропускались, — тепер вони виконуються.

Batch і захист документації на версійних адресах

Симптом. Batch-запит на версійну адресу (/rpc/v2) виконував елементи у версії за замовчуванням; версійні адреси документації (/rpc/v2, /rpc/v2/postman) не підпадали під protected_doc.

На callback пересилались усі заголовки клієнта, включно з токеном

Симптом. Для одиночного HTTP-запиту з $rpc.callback сервер копіював усі заголовки вхідного запиту, зокрема RPC-токен (Ufo-RPC-Token) та інші облікові дані, у POST-запит на callback URL. Для callback з елементів процесного batch заголовки не пересилались (дочірній процес не має HTTP-запиту).

Причина. RpcCallbackProcessor::process() брав $httpRequest->headers->all() без фільтра.

Виправлення. Пересилаються лише заголовки трасування: X-Request-Id, X-Correlation-Id, traceparent, tracestate, baggage. Примітки до релізу 9.2 досі описують стару поведінку.

Що зробити, якщо ви були на зачепленій версії. Якщо клієнти передавали $rpc.callback на хости, яким ви не довіряєте, замініть токени, які могли туди потрапити.

Регресії у версіях 8.1.1–8.1.5

Симптом. Реліз 8.1.1 відкотив частину змін 8.0.4–8.1.0: схеми enum у документації та спеціальні параметри $rpc у RequestCarrier.

Виправлення. Спеціальні параметри — у 8.1.5, схеми enum — у 8.1.6. Не залишайтеся на 8.1.1–8.1.5, використовуйте 8.1.14.