попытка обращения напрямую к методу, к которому нет доступа. вариант - при истечении срока жизни кеша АПИ произошел какой-то сбой и новый кеш построился "криво", неполностью. в итоге, когда приходит твой сервис, запрошенного метода нет в кеше, или он помечен, как недоступный. время жизни кеша - сутки от первого запроса к АПИ (по ИД приложения) или до рестарта сервиса. после чего кеш строится корректно и дальше все идет хорошо...

вариант лечения - отключить кеширование АПИ, сделать корректный запрос, затем опять включить кеширование

Доброе утро!

А есть какие-то ещё варианты?:) То, что у нас происходит, как-будто не подходит под описание.

У нас было так. Ко мне пришли коллеги из другой системы и сообщили, что у них, при обращении "из вне" ошибка. Я пошёл проверять на страничке /scripts/openapi/spec/index.html?remote_app_id=, условно "внутри". Открыл нужный метод, указал x-app-id, при попытке запроса ввёл данные учётки и у меня всё заработало. В этот же момент и у коллег всё начало работать. Но не прошло и часа как уже я стал получать ошибку 500. То есть и ожило оно не через сутки, а просто в момент обращения из другого места и померло оно не через сутки когда якобы мог сброситься кеш. Рестарта системы тоже не было.

Вот щас с утра, суток ещё не прошло, снова проверил - работает. Суток с вчерашних 15:17 не прошло, рестартов не было. Что могло сбросить кеш?

а у тебя вообще кеширование стоит? может отключено? есть еще, конечно, вариант, что ресурсов не хватает и кеш тупо вытесняется. redis?

а у тебя вообще кеширование стоит? может отключено? есть еще, конечно, вариант, что ресурсов не хватает и кеш тупо вытесняется. redis?

У нас была похожая история, посмотри, tempdb не разрослась?

У нас была похожая история, посмотри, tempdb не разрослась?

это включение/выключение API 1.0