Актуальні помилки Client SDK

Відомі помилки й нестиковки поточної версії ufo-tech/json-rpc-client-sdk (5.0.2). Виправлені — на сторінці Виправлені помилки.

<include>(.issues/errors-wrapped-in-sdk-exception.md)

<include>(.issues/async-params-not-reset.md)

<include>(.issues/sync-reset-skipped-on-error.md)

<include>(.issues/async-ping-fatal.md)

<include>(.issues/async-no-api-group.md)

<include>(.issues/response-schema-cached-by-method.md)

<include>(.issues/request-response-stack.md)

<include>(.issues/enum-try-from-value.md)

<include>(.issues/url-in-attr-ignored.md)

<include>(.issues/make-script-limits.md)

<include>(.issues/return-docblock-default.md)

<include>(.issues/readme-outdated.md)

Типізовані помилки сервера приходять лише всередині SdkException

Симптом. catch (RpcDataNotFoundException $e) навколо синхронного виклику ніколи не спрацьовує.

Причина. AbstractProcedure::requestApi() загортає будь-який виняток у Ufo\RpcSdk\Exceptions\SdkException; виняток rpc-exceptions доступний через getPrevious(), код JSON-RPC — через getCode(). Помилки валідації параметрів, навпаки, вилітають без обгортки.

Обхідний шлях. Ловіть SdkException і перевіряйте getPrevious() — див. Використання.

Асинхронні виклики не скидають спеціальні параметри і не змінюють id

Симптом. Після callbackTo(), asyncTimeout(), rayId() чи withoutCache() на асинхронному об'єкті параметр діє на всі наступні виклики цього об'єкта; усі виклики мають однаковий id.

Обхідний шлях. Викликайте resetConfig() і setId() перед кожним викликом або створюйте новий об'єкт для кожного запиту з особливими параметрами.

Після помилки синхронного виклику параметри й id не скидаються

Симптом. Якщо виклик завершився помилкою, спеціальні параметри (withoutCache(), rayId() тощо) і id переходять на наступний виклик того самого об'єкта.

Причина. Скидання параметрів і новий id виконуються лише на шляху успіху (AbstractProcedure::requestApi()).

Обхідний шлях. Після перехопленої помилки викликайте resetConfig() і setId().

ping() на асинхронному класі завершується фатальною помилкою

Симптом. $asyncSdk->ping() — Error: Call to a member function getResult() on true.

Причина. ping() оголошено в спільному AbstractBaseProcedure як $this->requestApi()->getResult(), а в асинхронних класах requestApi() повертає true.

Обхідний шлях. Перевіряйте доступність сервера синхронним класом.

Асинхронні виклики не передають групу API

Симптом. Асинхронний виклик методу, що належить не до групи general, сервер відхиляє як Method not found.

Причина. AbstractAsyncProcedure створює RpcAsyncRequest без apiGroup; сервер у такому разі використовує general.

Обхідний шлях. Для асинхронних викликів використовуйте методи групи general.

Схема результату кешується лише за назвою методу

Симптом. Якщо в одному процесі є два SDK-класи (різні постачальники чи версії API) з однаковою назвою RPC-методу, наприклад User.get, відповідь другого перетворюється за схемою, простором імен і обробниками першого — результат отримує DTO не того класу або падає.

Причина. SdkResponseCreator::$instances ключується лише назвою методу.

Обхідний шлях. Не використовуйте в одному процесі кількох постачальників з однаковими назвами методів або давайте методам різні назви на сервері.

RequestResponseStack::getLast*() не працюють

Симптом. getLastStack(), getLastRequest(), getLastResponse() після виклику дають помилку невизначеного індексу й TypeError. Асинхронні виклики перезаписують один і той самий запис стека.

Причина. addResponse() збільшує лічильник, а getLast*() читають запис за новим, ще порожнім індексом. Асинхронні класи не викликають addResponse().

Обхідний шлях. Використовуйте RequestResponseStack::getAll() і беріть останній елемент.

tryFromValue() згенерованих enum кидає TypeError

Симптом. OrderStatus::tryFromValue('unknown') замість null — TypeError.

Причина. Метод оголошено як : self, а він повертає self::tryFrom(), тобто ?self.

Обхідний шлях. Використовуйте вбудований OrderStatus::tryFrom().

urlInAttr / generate_url_in_attr не впливає на генерацію

Симптом. Атрибут #[ApiUrl] з адресою сервера ніколи не з'являється в згенерованих класах; адреса завжди береться з sdk_config.yaml(.dist).

Причина. SdkProcedureMaker передає в шаблон apiUrlInAttr, але шаблони його не використовують.

Обхідний шлях. Задавайте адреси через sdk_config.yaml.

bin/make.php не дозволяє задати простір імен і заголовки

Симптом.

• Простір імен жорстко заданий як Ufo\RpcSdk\Client, а його ж пакет зіставляє у своєму composer.json з власним каталогом sdk/, тож у встановленому як залежність пакеті згенеровані файли можуть потрапити у vendor/.
• Документацію запитує без заголовків — захищену protected_doc документацію не отримати.
• Без аргументу читає bin/schema.json, якого немає в пакеті.
• Maker::make() без callback завершується помилкою (callback викликається без перевірки на null).

Обхідний шлях. Генеруйте через SDK Bundle або з коду з власним ConfigsHolder і HttpReader із заголовками — див. Генерація.

Метод без @return дає попередження

Симптом. Для методу згенерованого класу без тегу @return (наприклад, після ручного редагування) — PHP warning про невизначений індекс.

Причина. (string)$tags[0] ?? 'mixed' у SdkResponseCreator: приведення типу виконується до ??, тож значення за замовчуванням не застосовується.

Обхідний шлях. Не прибирайте @return із згенерованих класів.

README пакета застарів

• Методи ->timeout() і ->callback() насправді називаються asyncTimeout() і callbackTo().
• Маска «лише синхронні» в таблиці — #Command.run; правильно &Command.run.
• Приклад використання з UserProcedure / PingProcedure — з версій 2.x–3.x; зараз класи називаються <Назва>SDK, результати — DTO.
• Вказано ufo-tech/rpc-objects ^3.7, у composer.json — ^3.8; Symfony 8 і rpc-exceptions ^2 не згадано.
• Посилання на документацію веде на стару вікі docs.ufo-tech.space.