Ось фраза, що спричиняє найдорожчі помилки в автоматизації LinkedIn: API повернув 200, отже, допис пішов.
Не обов'язково. 2xx від будь-якого API LinkedIn означає, що запит прийняли й передали далі. Що LinkedIn зробить із ним потім — не покаже нікому, затримає на перевірку, тихо впустить, покаже і зніме за двадцять хвилин — у цій відповіді немає, а в кількох випадках немає в жодній відповіді.
Чому цей розрив існує
Між вашим кодом і видимим дописом щонайменше два переходи, і другий — це платформа з власною думкою про автоматичний вміст. Синхронний код стану не може доповісти про рішення, якого ще не ухвалили. Ніхто нічого не приховує; інформації не існує тієї миті, коли пишеться відповідь.
Що робити замість припущень
- Зберігайте те, що надіслали, разом із відповіддю й позначкою часу. Не булеве значення: тіло.
- Читайте назад. Якщо допис важливий, заберіть його потім і запишіть, що повернулося.
- Вважайте число викликів і число видимих результатів двома різними мірами, бо це вони і є.
- Ніколи не показуйте клієнтові «опубліковано» на самому лише коді стану.
Версія, яка б'є найболючіше
Вичерпане очікування. Ваш запит не провалився — ви просто перестали чекати відповіді. Запис цілком міг дійти. Повтор — це те, як одне повідомлення стає двома, і друге помічає ваш клієнт. Тримайте ідентифікатор для кожного запису, який збираєтеся зробити, перевіряйте до повтору й радше прочитайте світ, ніж програвайте запит знову.
Часті запитання
Чи знає ШІ-агент різницю?
Лише якщо йому сказати. ШІ-агент, який отримав 200, зазвичай повідомить, що допис опубліковано. Закріпіть правило в його інструкціях: повідомляти про запис як про прийнятий і перечитувати його, перш ніж казати, що він вийшов.
Як проєктна кімната повідомляє про запис?
Відповіддю ШІ-агента в кімнаті, де його бачать усі. Це добра причина попросити агента процитувати те, що він надіслав, і id, який отримав у відповідь.