Проблема в настоящее время происходит локально для меня, не пытался загрузить ее на сервер. Иногда (но не всегда) случайные вызовы API в моем проекте возвращают следующую ошибку:
AxiosError {message: 'Request failed with status code 500', name: 'AxiosError', code: 'ERR_BAD_RESPONSE', config: {…}, request: XMLHttpRequest, …}
code:
"ERR_BAD_RESPONSE"
config:
{transitional: {…}, adapter: Array(2), transformRequest: Array(1), transformResponse: Array(1), timeout: 0, …}
message:
"Request failed with status code 500"
name:
"AxiosError"
request:
XMLHttpRequest {onreadystatechange: null, readyState: 4, timeout: 0, withCredentials: false, upload: XMLHttpRequestUpload, …}
response:
{data: '{\n "message": "Server Error"\n}{\n "message": "Server Error"\n}', status: 500, statusText: 'Internal Server Error', headers: AxiosHeaders, config: {…}, …}
stack:
"AxiosError: Request failed with status code 500\n at settle (webpack-internal:///./node_modules/axios/lib/core/settle.js:24:12)\n at XMLHttpRequest.onloadend (webpack-internal:///./node_modules/axios/lib/adapters/xhr.js:120:66)"
[[Prototype]]:
Error
Это то, что я получаю в своей консоли. На вкладке сети просто написано: "message": "Server Error"
Я упомяну:
Я знаю, что ошибка, которую я упомянул, не слишком много говорит, вероятно, и звучит так же, как какая-то общая ошибка сервера, но что может быть причиной?
Обновления работали нормально, и я убедился, что у меня PHP 8.2, с помощью команды php -v
.
Я поправил все файлы конфигурации, такие как php.ini
, httpd.conf
и т. д. (могу загрузить, если нужно).
И последнее, что я хотел бы упомянуть, это то, что по какой-то странной причине, когда я использую Xdebug для отладки моего проекта и размещаю точки останова в начале каждой функции контроллера (направление, куда мой вызов API идет в бэкэнде) - ошибки никогда не появляются. Но это, очевидно, не решение, так как я не хочу заполнять все свои внутренние функции точками останова, а Visual Studio будет всплывать при каждом вызове API.
Обновлено: просмотрев журнал Laravel, я увидел следующее: «production.ERROR: ключ шифрования приложения не указан». Посмотрев, я нашел решение использовать следующие команды: php artisan key:generate
, php artisan config:cache
. Они вызвали другую ошибку, самый первый вызов API моего проекта выдал ошибку - файл .env больше не читался после команд. строка кода, например: "env('OKTA_CLIENT_ID')" теперь возвращает null вместо фактического значения.
Любая помощь будет оценена, спасибо.
`xdebug.start_with_request=yes'" -- Вы настроили Xdebug на попытку отладки каждого отдельного запроса/скрипта. Это объясняет ваши сообщения «Xdebug: [Step Debug] Time-out при подключении к клиенту отладки...». Обратите внимание, что это будет работать так же в вашем предыдущем PHP/Laravel, если у вас также есть Xdebug v3.x.
Но это не должно быть причиной (поскольку Xdebug отправляет его только в журнал ошибок PHP или консоль, если это CLI). Я предлагаю вам добавить журнал трассировки в ваш код в конечных точках, которые терпят неудачу (вы знаете, что-то вроде $log->write('entering this step / finished that step');
своего рода пользовательского ведения журнала и смотрите, на каком этапе он обычно терпит неудачу.
@LazyOne, согласно руководству по обновлению Xdebug с 2 до 3, они говорят, что переключите «xdebug.remote_autostart = 1» на «xdebug.start_with_request = yes». И у меня был такой вариант раньше. Я не знаю, может быть, эти предупреждения относительно Xdebug появились и до перехода с версии 2 на 3.
Такое предупреждение было введено в Xdebug v3. Это делается специально, чтобы пользователь знал, что подключение отладчика не было успешным (поскольку этот параметр предполагает, что вы ХОТИТЕ отлаживать каждый сценарий, поэтому он ожидает, что вы также захотите иметь этот сеанс отладки). К сожалению, нет возможности отключить его (также мы сообщаем, когда используются параметры Xdebug v2). Это сообщение отправляется с использованием функций PHP error_log
, поэтому оно попадает в журнал ошибок и/или в стандартный вывод для сеансов CLI. Это не должно быть причиной ваших 500 ответов TBH, но лучше отключить и перепроверить тестами.
О вызовах API, которые терпят неудачу, это каждый раз другой вызов API, иногда вызов работает, иногда нет. Посмотрев журнал Laravel, я увидел следующее: «production.ERROR: ключ шифрования приложения не указан». Посмотрев, я нашел решение использовать следующие команды: php artisan key:generate
, php artisan config:cache
. Они вызвали другую ошибку, самый первый вызов API моего проекта выдал ошибку - файл .env больше не читался после команд. строка кода, например: "env('OKTA_CLIENT_ID')" теперь возвращает null вместо фактического значения.
«Самый первый вызов API моего проекта выдает ошибку - файл .env больше не читается после команд». Может быть что-то с кешированием Laravel или одним из пакетов. Сам никогда не сталкивался с такой проблемой. Попробуйте очистить все кеши и запустить без них (вы запускаете его локально на своей машине разработки, верно?) Возможно, также включите DEBUG в конфигурации окружения Laravel...
@LazyOne, я очистил все кеши, и это действительно устранило проблему, но вернуло исходную проблему сбоя некоторых вызовов API. Так что я побежал artisan key:generate
, php artisan config:cache
снова. И тогда мой проект заработал нормально. Только не хватает одного последнего кусочка. Теперь, если я очищаю данные просмотра своего браузера (например, в Chrome - очистка кеша и файлов cookie), это возвращает меня к проблеме с файлом .env, который не читается. Приходится повторять все заново, и это немного раздражает.
Есть ли способ автоматически очистить весь кеш + сгенерировать ключ и config:cache через код всякий раз, когда я впервые захожу в проект? (например, после очистки кеша браузера)? Или, может быть, есть какое-то другое более правильное решение для этого?
РЕШЕНО!
Ошибка: production.ERROR: No application encryption key has been specified
была устранена с помощью команды: php artisan config:cache
.
«Файл .env больше не читался после команд» было исправлено с помощью команды php artisan config:clear
.
Впоследствии, чтобы исправить повторяющуюся проблему каждый раз, когда я очищал кеш браузера, я добавил две следующие строки в мой файл UserController.php, часть этого файла вызывается только тогда, когда пользователь является новым пользователем или когда конфигурация была сброшена. строки:
Artisan::call('config:clear');
Artisan::call('config:cache');
Таким образом, эти строки будут запускаться только после очистки кеша браузера или когда новый пользователь войдет на веб-сайт, казалось, что они работают отлично и устраняют все проблемы.
Если ваш сервер выдает такую ошибку, обычно фронтенд не виноват. Но, пожалуйста, взгляните на журнал ошибок вашего сервера. Если он еще не содержит никаких подробностей, используйте более высокий уровень сообщения об ошибках.