Error undefined failed to fetch - Исправление ошибок и поиск оптимальных решений проблем

В данной статье описан процесс подключения к регистратору выбытия через приложение «Тест регистратора выбытия»(TestRV). В этом приложении можно изменить настройки часового пояса, посмотреть документы, отправленные с устройства на выбытие.

Процесс подключения к регистратору выбытия:

1. Откройте браузерное приложение «TestRV». Как получить это приложение можно узнать в статье Получение приложения “Тест регистратора выбытия”

2. Запустить приложение “Тест регистратора выбытия” (TestRV). После запуска в окне браузера должно отобразиться следующее:

3. Включить регистратор выбытия;

4. Подключить регистратор выбытия к локальной сети с помощью Ethernet кабеля или беспроводной сети WiFi;

5. Ввести в окне «Теста регистратора выбытия» в поле «Адрес» IP-адрес регистратора выбытия (посмотреть IP-адрес можно выбрав пункт «Информация» в главном меню регистратора выбытия), в поле «Порт» значение «8080», в поле «Пользователь» выбрать пункт «Администратор» и в поле «пароль» ввести значение «654321»:

6. В левой панели окна выбрать «Получить информацию об устройстве»;

7. В центральной панели должна появиться кнопка «Получить информацию об устройстве». Нажать на неё:

8. В правой панели в поле «Запрос» появится отправленный на ip-адрес устройства запрос следующего вида: GET https:// [ip-адрес]:[порт]/v1/deviceInfo, где [ip-адрес] — ip-адрес регистратора выбытия, а [порт] – порт регистратора выбытия.

Если в поле «Ответ» первая строка будет «STATUS 200 OK» и в центральной части окна появилась информация об устройстве, то связь с регистратором выбытия успешно успешно:

Если в правой панели в поле «Ответ:» первая строка будет «ERROR undefined Failed to fetch», открыть в браузере новую страницу и пройти по ссылке вида: https://[ipадрес]:[порт], где [ip- адрес] — ip-адрес регистратора выбытия, а [порт] – порт регистратора выбытия (Пример ссылки: https://10.58.10.253:8080);

9. В результате появится следующее окно:

10. Нажать кнопку «Дополнительно». Будет выведена дополнительная информация:

11. Нажать ссылку «Перейти на сайт *** (небезопасно)»;

12. В поле «Вход» в поле «пользователь» ввести значение «administrator», в поле «пароль» ввести значение «654321»:

13. В окне браузера будет выведен ответ регистратора выбытия вида: {«error»: {«code»:400,»description»:»bad target»}}:

14. Перейти в «Тест регистратор выбытия», нажать на «получить информацию об устройстве». Если в поле «Ответ» первая строка будет «STATUS 200 OK» и в центральной части окна появилась информация об устройстве, то связь с регистратором выбытия успешно успешно:

Источник

Содержание

Подключение к регистратору выбытия через приложение «TestRV»
В данной статье описан процесс подключения к регистратору выбытия через приложение «Тест регистратора выбытия»(TestRV). В этом приложении можно изменить настройки часового пояса, посмотреть документы, отправленные с устройства на выбытие.
Процесс подключения к регистратору выбытия:
Fetch выдает ошибку «TypeError: Failed to fetch» при успешном запросе того же происхождения.
О том, как работать с регистратором выбытия: подключить, настроить и исправить частые ошибки
Суть устройства
Как подключить регистратор выбытия / начало работы
Как подключиться к сети интернет
Индикаторы соединения
Три типа подключения регистратора выбытия: компьютер, локальная сеть и автономный режим
РВ подключен к ПК
РВ подключен в локальную сеть
Автономная работа
Синхронизация с ГЛОНАСС
Как настроить
Частые проблемы и пути их решения
Если регистратор выбытия завис
Если РВ не заряжается
Ошибка 5090
К кому обращаться за тех. поддержкой и ремонтом
Инструкции для регистратора выбытия

Подключение к регистратору выбытия через приложение «TestRV»

В данной статье описан процесс подключения к регистратору выбытия через приложение «Тест регистратора выбытия»(TestRV). В этом приложении можно изменить настройки часового пояса, посмотреть документы, отправленные с устройства на выбытие.

Процесс подключения к регистратору выбытия:

3. Включить регистратор выбытия;

4. Подключить регистратор выбытия к локальной сети с помощью Ethernet кабеля или беспроводной сети WiFi;

6. В левой панели окна выбрать «Получить информацию об устройстве»;

7. В центральной панели должна появиться кнопка «Получить информацию об устройстве». Нажать на неё:

9. В результате появится следующее окно:

10. Нажать кнопку «Дополнительно». Будет выведена дополнительная информация:

11. Нажать ссылку «Перейти на сайт *** (небезопасно)»;

12. В поле «Вход» в поле «пользователь» ввести значение «administrator», в поле «пароль» ввести значение «654321»:

13. В окне браузера будет выведен ответ регистратора выбытия вида: <«error»: <«code»:400,»description»:»bad target»>>:

Источник

Fetch выдает ошибку «TypeError: Failed to fetch» при успешном запросе того же происхождения.

Мы столкнулись с несовместимыми ошибками клиента с одностраничным приложением JavaScript, выполняющим запросы на выборку. Следует отметить, что все они являются запросами того же происхождения.

Около 5% обещаний отклоняются со следующей ошибкой, несмотря на то, что сервер и браузер получают ответ 200 OK :

Я в тупике . Все мои поиски приводят к обсуждениям ошибок CORS. Похоже, что это не применимо, учитывая, что все запросы имеют одинаковое происхождение. Что заставляет выборку бросать TypeError ?

С помощью вкладки «Сеть» в Chrome DevTools я могу подтвердить, что запрос на выборку завершается ответом 200 OK и действительным JSON. Я также могу подтвердить, что URL-адреса имеют одинаковое происхождение. Я также могу подтвердить, что предполетных запросов CORS нет. Я воспроизвел эту проблему в Chrome 66 и Safari 11.1. Однако мы получили поток отчетов об ошибках из разных версий Chrome и Safari, как настольных, так и мобильных.

Это не похоже на дубликат связанного вопроса, поскольку мы нет отправляем запросы CORS, нет устанавливает mode: «no-cors» , а нет устанавливает заголовок Access-Control-Allow-Origin .

Кроме того, я повторно провел тесты с явно заданной опцией mode: ‘same-origin’ . Запросы (все еще) успешны; однако мы (все еще) периодически получаем TypeError .

@Barmar Я делаю нет, устанавливаю опцию mode . Похоже, что по умолчанию mode — это cors (developer.mozilla.org/en-US/docs/Web/API/Request/mode). Не уверен, что это означает в контексте запроса из одного источника. Однако я могу повторно протестировать и обновить поток, явно используя mode: same-origin .

@ Mr.White, я прочитал этот вопрос . В принятом ответе говорится о заголовках CORS и предполетных запросах. Этого не происходит с моим запросом на то же происхождение. Кроме того, в комментариях к вопросу есть ответ настоящий на этот вопрос: «Я думаю, что все ваши проблемы исчезнут, если вы удалите заголовок контроля доступа из запроса и не добавите в запрос режим: ‘no-cors’. «. Я подтвердил, что так строятся мои запросы.

Мне не удалось найти другого объяснения этой ошибки, не связанного с этой опцией.

Да. Мне очень любопытно явно выставить mode: «same-origin» по запросу. Пробую прямо сейчас. Интересно, что спецификация указывает, что режим по умолчанию — «no-cors» (fetch.spec.whatwg.org/#concept-request-mode), в отличие от документов MDN, которые говорят, что это «cors».

У вас когда-нибудь получалось с этим? У меня такая же проблема.

@AndyFurniss К сожалению, нет. В итоге мы переписали наш HTTP-уровень с помощью RxJS. (Мы по-прежнему используем fetch , но все обещания заключены в наблюдаемый объект.) Во время этого процесса эта проблема исчезла. Простите.

@seniorquico Не беспокойся. Спасибо, что ответили мне. Рад, что ты в конце концов обошел стороной.

Там только сказано Failed to fetch и все тут?

Насколько я помню, информация, размещенная выше, была всем доступным в то время. Ошибка была просто TypeError: Failed to fetch , а вкладка «Сеть» в Chrome DevTools подтвердила, что браузер получил правильный ответ. Это выглядело как типичная ошибка CORS, но это были те же запросы происхождения (все отправлялись на один и тот же сервер . ). Как отмечалось в моем редактировании, проблема исчезла после того, как мы переработали наш клиентский уровень HTTP на RxJS. Я все еще немного расстроен, что мы так и не догадались!

Я добавил награду, потому что у меня такая же ошибка, как записано Sentry, но ее практически невозможно воспроизвести с какой-либо последовательностью. В моем случае это приложение Next.js с useSWR для выборки данных, завернутое в React Suspense. Я понятия не имею, запускается ли он сервером или клиентом, прерывая соединение по какой-либо причине, и, похоже, нет никакого способа «поймать» и «обработать» это.

Я знаю, что это старая проблема, но после целого вечера поисков я хочу поделиться своими выводами, чтобы вы могли лучше провести время.

Мое веб-приложение также хорошо работало для большинства пользователей, но время от времени посетители получали ошибку, упомянутую в вопросе. Я не использую какую-либо сложную инфраструктуру (обратный прокси и т. д.) И не общаюсь со службами в другом домене / протоколе / порте. Я просто отправляю запрос POST в PHP-файл на том же сервере, с которого обслуживается приложение React.

Краткий ответ: Моя проблема заключалась в том, что я отправил запрос на серверную часть, используя абсолютный URL-адрес, например https://my-fancy-domain.com/funky_service.php . После изменения этого пути на относительный, например /funky-service.php , проблема исчезла.

Мое объяснение: большинство пользователей заходят на сайт без www в URL-адресе, но некоторые пользователи действительно вводят эту часть в свои адресные строки ( www.my-fancy. ). Оказалось, что www является частью происхождения, поэтому, когда эти пользователи отправляют форму и отправляют запросы на публикацию на https: // my-fancy . технически это другой источник. Вот почему браузер ожидает заголовки CORS и иногда даже отправляет предварительный запрос OPTIONS. Когда вы используете относительный путь в своем JavaScript-коде, почтовый запрос также будет включать www-часть (использует происхождение из адресной строки) -> то же происхождение -> никаких проблем с CORS. Поскольку он влияет только на посетителей, которые приходят с www на ваш сайт, он также объясняет тот факт, что он работал для большинства пользователей даже с абсолютным URL-адресом.

Также важно знать: запрос не выполняется в браузере / JavaScript-коде, но фактически отправляется на бэкэнд (очень некрасиво!).

Дайте мне знать, если вам понадобится дополнительная информация. На самом деле это очень просто, но сложно объяснить (и найти)

Проблема может заключаться в ответе, который вы получаете от серверной части. Если он работал нормально на сервере, проблема могла быть в заголовках ответа. Проверьте Access-Control-Allow-Origin (ACAO) в заголовках ответа. Обычно API выборки response выдает ошибку при извлечении даже после получения ответа, когда ACAO заголовков ответа и источник запроса не совпадают.

Да, отличный способ устранения неполадок для приложений CORS. В нашем случае это был запрос из одного источника.

Источник

О том, как работать с регистратором выбытия: подключить, настроить и исправить частые ошибки

Регистратор выбытия предназначен для аптек и лечебных учреждений, отпускающих лекарства по 100 %-ной льготе. Это частный случай контроля за оборотом лекарственных средств в рамках единой государственной системы маркировки товаров.

Работая с регистратором выбытия, важно внимательно изучить инструкции. Однако даже после этого могут остаться вопросы по эксплуатации прибора. В статье мы разберемся с вопросами, которые чаще всего возникают у пользователей.

Суть устройства

Функции регистратора выбытия:

считывание кода маркировки;

формирование данных о лекарственных препаратах;

передача информации в ФГИС МДЛП с фиксацией факта выбытия лекарственного препарата из оборота.

РВ не предназначен для использования в розничной торговле лекарственными средствами. Он нужен только для фиксации движения лекарств, отпускаемых бесплатно.

Программный интерфейс РВ дает возможность пользователю осуществлять передачу информации о выбытии ЛП в автономном и сетевом режиме.

Как подключить регистратор выбытия / начало работы

Первым делом устройство нужно включить. Производитель рекомендует достичь уровень заряда выше 50%, а лучше включать тогда, когда аккумулятор будет заряжен полностью.

Первое включение требует авторизации в качестве «Администратора».

Как подключиться к сети интернет

Алгоритм действий для соединения с интернетом обычно выглядит следующим образом.

Для локальной сети:

Подключить сетевой провод.

В меню выбрать вкладку «Сервис».

Перейти в «Настройки».

Выбрать «Конфигурация Ethernet».

При ручном способе настройки ввести необходимые параметры.

Подключение к Wi-Fi:

Действия аналогичны предыдущему случаю до перехода в «Сервис» — «Настройки».

Выбор сети Wi-Fi.

Если сеть защищена паролем, ввести его.

Если все действия выполнены верно, то появится значок «Честный ЗНАК», а в верхней части экрана отобразится пиктограмма статуса соединения с сетью.

Индикаторы соединения

— Зеленый. Подключение к серверу имеется.

— Желтый. Соединение находится в режиме ожидания (подключение к интернету имеется).

— Синий. Нет защищенного соединения с сервером, но подключение с интернетом имеется.

— Красный. Подключения нет. Для выяснения причин следует обратиться в техническую поддержку.

Три типа подключения регистратора выбытия: компьютер, локальная сеть и автономный режим

РВ подключен к ПК

Работает через ту же сеть интернет, что и компьютер.

Может быть использован встроенный сканер штрих-кодов или сканер, подключенный к ПК.

РВ подключен в локальную сеть

Возможно подключение с любого ПК, входящего в локальную сеть. При этом рабочие места должны быть оборудованы сканером штрих-кодов, так как использование встроенного будет невозможно.

Обязательно необходима установка на рабочих местах ПО, управляющего работой регистратора выбытия.

Автономная работа

Отправка информации о выбытии ЛП может происходить через любое подключение с сетью интернет.

Дополнительные сведения вводятся вручную.

Синхронизация с ГЛОНАСС

На регистраторе выбытия должно быть установлено корректное время. В противном случае вывод лекарственных препаратов из оборота невозможен из-за блокировки отправки документов.

Если регистрация выбытия лекарств не планируется, то синхронизация со спутниками ГЛОНАСС не обязательна.

Как настроить

После включения прибора следует авторизоваться в качестве Администратора.

В меню выбрать «Сервис».

Перейти в пункт «Проверка РВ».

Найти пункт «Спутники». На этом этапе происходит поиск спутников (должно быть найдено не менее пяти) и синхронизация часов.

Если синхронизация прошла успешно, то в меню появится статус «Блокировка: НЕТ» вместо «Блокировка: ДА».

Есть также пункт «Информация», в нем указано время до блокировки РВ.

Частые проблемы и пути их решения

Если регистратор выбытия завис

Неприятным известием для пользователя может стать появление на экране изображения песочных часов. В этом случае поможет перезагрузка устройства путем одновременного нажатия красной и зеленой клавиш.

В большинстве случаев после перезагрузки аппарат начинает работать корректно. Если это не помогло, стоит обратиться в тех.поддержку.

Если РВ не заряжается

Низкий заряд может сделать невозможным использование прибора по назначению.

Зарядное устройство вышло из строя.

Поврежден шнур зарядки.

Сломался или расшатался usb-порт на регистраторе.

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

Современные зарядные устройства универсальны и взаимозаменяемы, поэтому подойдут те, которыми обычно заряжают смартфоны.

Если неисправно само устройство, необходимо обращаться к мастерам сервис-центра.

Ошибка 5090

Эти цифры означают, что появились проблемы с синхронизацией внутреннего времени РВ со спутниками ГЛОНАСС. Проблема решается после проверки статуса синхронизации.

К кому обращаться за тех. поддержкой и ремонтом

Напомним, что регистраторы выбытия выдаёт Центр развития перспективных технологий по заявке.

Изначально именно ЦРПТ занимается технической поддержкой. О неисправности можно сообщить, отправив заявку на почту или в личном кабинете.

Если аптеки и медицинские учреждения заключили договор на обслуживание и сопровождение РВ с партнерами компании ФедТех, то они будут обращаться в свой сервисный центр. Это, как правило, позволяет гораздо более оперативно решить любые вопросы с подключением, настройками и даже ремонтом оборудования.

Во время, пока регистратор выбытия неисправен, загружать отчеты о выбытии лекарственных препаратов можно через Личный кабинет ФГИС МДЛП.

Инструкции для регистратора выбытия

Статья подготовлена ритейл-экспертами ПОРТ. Информационная поддержка: Сергей Хорош.

Если у вас есть вопросы по маркировке товаров, оборудованию и подключению к системе Честный Знак, пишите в комментариях к материалу и в соцсетях, приезжайте на консультации в наши офисы в Красноярске.

Источник

Viewing 15 replies — 1 through 15 (of 16 total)

Can you share a screenshot of the error you are getting? Is your server firewall is blocking the API calls to Cloudflare in any way?

Thread Starter
989

(@989-1)

I found it was apparently a DNS problem even though right now I have this problem…

Page caching seems not working for both dynamic and static pages.

Error on dynamic page (https://989records.com): Cache status: DYNAMIC - The resource was not cached by default and your current Cloudflare caching configuration doesn't instruct Cloudflare to cache the resource. Instead, the resource was requested from the origin web server.

Error on static resource (https://989records.com/wp-content/plugins/wp-cloudflare-page-cache/assets/testcache.html): Unable to find the Cache-Control response header.

Please check if the page caching is working by yourself by surfing the website in incognito mode 'cause sometimes Cloudflare bypass the cache for cURL requests. Reload a page two or three times. If you see the response header cf-cache-status: HIT, the page caching is working well.

Mat

(@mateithemeisle)

Hello @989-1 ,

Thank you for your reply!

It seems like you are using another caching system alongside this plugin. Please make sure to deactivate all other caching systems in your environment and try again.

Thank you and we’ll await your answer!

Hi,
It seems your cache-control header value is not what this plugins set and it also seems you are using W3 Total Cache for Page Caching: https://i.imgur.com/iQJ7p6N.png

Please note that while using this plugin you need to make sure there is no other page caching plugin active whether at the WordPress plugin level or Server Level.

I would suggest Deleting other caching plugins from your site and inside this plugin, setting doing “Deactivate Page Cache” and then “Enable Page Cache”.

Thread Starter
989

(@989-1)

Hi there
yep, W3 it’s installed, but now

Consider that we had this error with a fresh WP installation
And the unique cache plugin installed was yours

Server-side caching or compressions are disabled

o will remove agaain w3 and give atry to your than
when with everything deleted and cache purged everywhere
I will update you

Thanks in advance

Thread Starter
989

(@989-1)

Here we are…
Delete completely W3 and all its files/folders where necessary
purged cache from CDN
Installed again your plugin in
Same error message as above
Page caching seems not working for both dynamic and static pages.

From the consolle, Now I have
cache-control: s-maxage=31536000, max-age=60
server: cloudflare
x-wp-cf-super-cache: cache
x-wp-cf-super-cache-active: 1
x-wp-cf-super-cache-cache-control: s-maxage=31536000, max-age=60
x-wp-cf-super-cache-cookies-bypass: swfpc-feature-not-enabled

thanks in advance

Hi @989-1,
Yes I see that the response headers are now perfect as there is only one cache-control header and the value of it matches with the value of x-wp-cf-super-cache-cache-control header.

Now I want you to share a screenshot of your Cloudflare Dashboard > Page Rule Section so that I can take a look at it.

This reply was modified 1 year, 2 months ago by Saumya Majumder.

Thread Starter
989

(@989-1)

Nice!
with great pleasure
there we go
https://ibb.co/jb4Xn5m
thanks

Alright. So, here lies the issue. It seems you already have 3 page rules there. Cloudflare free account can only have max 3 page rules. I would suggest you to remove these page rules you have added as none of them are needed when you are using this plugin.

Once you have deleted all the page rules, Go to the CF Dahboard > Cache > Configuration > Set Browser Cache TTL -> Respect Headers

Then come back to the plugin settings page. Click on Disable Page Cache and then Enable Page Cache.

This time the plugin will create the page rule it needs automatically. Do not tinker with the page rule created by the plugin.

Let me know once you have done that. Then share a screenshot of the page rule section again and let me know so that I can test your site.

Thread Starter
989

(@989-1)

Hello again
got it, in fact, the rules were created for the W3 total cache.
So, I followed your suggestions but again, if I test the cache from your plugin, I have always the same warning.

Here are the screenshots
https://ibb.co/L0LJNqP
https://ibb.co/crSYc8f

thanks

Hmm… It’s wired, it should be HIT but I have a hunch.
can you disable the Cookie Consent thing and purge the whole cache?

Let me know when it’s done.

Thread Starter
989

(@989-1)

oh my….
done so far and still disabled the cookie plugin—
can you have a look?
thanks

Huh! It’s still showing as DYNAMIC. Can you enable the Worker Mode inside the plugin settings?

Oh darn! No Need Ignore my previous message. The issue is happening because in your page rule added by the plugin it is http:// inetsad of https://.

This is because inside your WP Settings > General your site URL has been set as http:// inetsad of https://.

So, you can either go and edit your site URL inside the WP settings and then disable/enable page cache again.

OR inside the Cloudflare page rule section, edit the page rule added by the plugin and make the http:// to https://. This will solve your issue.

Thread Starter
989

(@989-1)

Dude you are a DRAKE!
I ought you 5 beer liters 😁🔥😁🙏🙏🙏🙏

it works even with the cookies plugin enabled again
Thank you so much
5 stars on the way

Viewing 15 replies — 1 through 15 (of 16 total)

Источник

7 комментариев

Написать комментарий…

Сломалось

20.12.2019

Попробуйте очистить куки. Используйте комбинацию CTRL+F5

Ответить

Развернуть ветку

Pixel Lens

20.12.2019

Автор

Ок

Ответить

Развернуть ветку

Pixel Lens

20.12.2019

Автор

Не сработало — сразу же вылезла ошибка

Ответить

Развернуть ветку

Семен Смирнов

20.12.2019

Если что, это 2 разных совета

Ответить

Развернуть ветку

Pixel Lens

21.12.2019

Автор

разве ctrl+f5 не делает то же самое?

Ответить

Развернуть ветку

Алюминиевый торшер

21.12.2019

Комментарий недоступен

Ответить

Развернуть ветку

Станислав Тюрин

20.12.2019

Никогда такого ещё не было, и вот опять

Ответить

Развернуть ветку

Написать комментарий…

Читать все 7 комментариев

Источник

Issue Description

Swagger Open API documentation gives the below error in .NET Core API etc.

“Failed to load API definition. Fetch error undefined /swagger/v1/swagger.json”

It is also observed that Swagger API documentation/description works on ‘localhost’ i.e locally but when it runs in publish mode i.e hosted on IIS or Cloud Server, produces the error like “Failed to load API definition” with undefined/swagger/v1/swagger.json error.

Resolution

Before applying this fix, I would recommend you to validate the swagger implementation with the below article,

ASP.NET Core 3.1 or 5.0 – Add Swagger OpenAPI V3.0 specification documentation

ASP.NET Core 2.2- Add Swagger v2.0 API documentation

Please make sure you verify the below points steps,

Resolution 1

Swagger Document is defined with proper Title and Version details, as both are required parameters.

Resolution 2

Please make sure the API doesn’t contain any conflicting action. Conflicting action could be using the same routes. To be on the safer side, you can very much use the below flag to control that behavior,

c.ResolveConflictingActions(x => x.First());

Resolution 3

Please make sure all controller methods are attributed with proper HTTP attributes Example- HttpGET or HttpPost etc. Missing this attribute could cause the error.

If the issue still persists then please apply the below fix to resolve the issue.

Resolution 5

Please check if the hosting server allows CORS request processing. Also, its important swagger UI-related resources like CSS or stylesheets are accessible from your server.

Resolution 6

Please, note that Swagger JSON will be exposed at the following route as per default behavior.

"/swagger/{documentName}/swagger.json".

If you are using a custom route or prefix, then the route MUST include the {documentName} parameter.

To fix the issue, please update the UseSwagger() as below,

app.UseSwagger(c =>
             {
                c.RouteTemplate = "<custom-name>/swagger/{documentName}/swagger.json";
             });

Example,

 c.RouteTemplate = "MyTestService/swagger/{documentName}/swagger.json";

The above changes also need to be reflected in SwaggerUI middleware. Please update the UseSwaggerUI method will be as follows,

app.UseSwaggerUI(c =>
             {
                 c.SwaggerEndpoint("/<custom-name>/swagger/v1/swagger.json", "TestService");
             });

Example:

 app.UseSwaggerUI(c =>
             {
          c.SwaggerEndpoint("/MyTestService/swagger/v1/swagger.json", "TestService");
             });

Please note that in Swaggerendpoint() method ‘documentName’ value is cases sensitive.

In fact, documentName is case sensitive anywhere else if referenced.

This documentName is generally a Group Name associated with API version

Example: It won’t work for V1 but works for v1.

If using RoutePrefix in API then it can be defined as below,

Example only if using RoutePrefix,

c.RoutePrefix= "MyTestService/swagger"

Here MyTestService is my service name.

Please see below the complete implementation,

Finally, Swagger runs successfully locally and in any hosting environment like IIS or Azure Cloud, etc.

For any other issues, please use google chrome dev tools(FUN F12) or Edge Developer tools to verify the exact error causing the issue. Please verify Console and Network tab to validate the exact erros.

Other References:

Add swagger to ASP.NET Core API in simple 2-3 steps:

Swagger API Documentation in .NET Core 6 or 3.1

Add Swagger API documentation to .NET Core 2.2

Did I miss anything else in these resolution steps?

Did the above steps resolve your issue? Please sound off your comments below!

Happy Coding !!

Please bookmark this page and share it with your friends. Please Subscribe to the blog to get a notification on freshly published best practices and guidelines for software design and development.

Источник

Every single day I get Failed to fetch generic error message when using the upload files v2 api.
What do I benefit from such generic message?
I cannot even debug the issue or know what’s wrong, It happens so randomly from time to time!!!

error

We’ll be happy to help with any issues you’re having with the Dropbox API/SDK, but we’ll need some more information. Can you please share:

the name and version number of the platform where you’re running this
the version number of the Dropbox JavaScript SDK you’re using
the steps to reproduce the issue, including relevant code snippet(s)

I also rarely get the error message Failed to fetch in our logs as the only response from a call to filesListFolder. (^5.2.1 on web, Chrome) I dont know what status code it returns though. Might also be a console.error(). No idea whats going on or how to handle this. I should probably upgrade though.

@phil294 We haven’t heard back from the original poster here, and we don’t know exactly what the cause of this is. If you can share some way for us to reproduce it though, we’ll look into it. In any case, we do recommend upgrading to the latest version of the SDK.

I actually just now found the reason in my case: When the site is offline, a call like x = await filesListFolder(...) fails with a simple

message: "Failed to fetch",
stack: "TypeError: Failed to fetch"

object. This is also the case with v8.2.0. I’ll now just do a try { ... } catch(e) { if(e.message === 'Failed to fetch') { /* show network error to the user */ } }. Thanks for your help and I hope this will help someone else.

@greg-db I’m not sure how can I re-produce the error because I cannot myself, I have pretty much this setup on my App and the error is totally random, I just don’t know what the error is or where it happen.

But as @phil294 mentioned my App is fully PWA (https://app.replayed.co), and I always show network error to the user. In my case the error is happen after couple fetches so it’s not like there’s connection at all or the user access the page immediately from offline. It happens like 50% of the time, It’s getting annoying. I’m not sure what to do!

@ImSolitude Thanks for following up. Unfortunately if we can’t reproduce the issue here, it’s unlikely we’ll be able to offer much help.

To clarify though, since your app is a PWA, it seems the API calls are made client-side on your users’ devices (and you’re just seeing the error report). Is that correct? Given that you can’t reproduce it yourself, and since Philip mentioned this can happen when offline, it may indicate that it happens when the user has even just an unreliable connection, if not completely offline.

Hey @greg-db, An update to this, We checked the sentry issues and it was filled with this error,
TypeError: Failed to execute 'fetch' on 'Window': Illegal invocation, We’re using dropbox: 8.1.0, and we’re not passing any custom fetcher to the Dropbox constructor.

const dbx = new Dropbox({
  clientId: `${process.env.REACT_APP_DROPBOX_CLIENT_ID}`,
  accessToken: `${process.env.REACT_APP_DROPBOX_ACCESS_TOKEN}`,
  pathRoot: '{".tag": "namespace_id", "namespace_id": "####"}',
  selectUser: `${process.env.REACT_APP_DROPBOX_SELECT_USER}`, 
});

Not sure what’s wrong.
error

@ImSolitude Thanks for the information. From that code, it looks like you’re using this in a React app. This SDK doesn’t officially support React unfortunately, but I’ll pass this along as a feature request. I can’t promise if or when that might be implemented though.

Hi,

I have same fetch error problem. I have a node.js app which runs on AWS Lambda. The Lambda is connected with a VPC. It goes internet with a static IP. I use v10.23.0 dropbox-sdk-js. It always seems to run on my local but It sometimes runs on lambda, sometimes gets fetch error.

My code like this:

async function main() {
    const Dropbox = require('dropbox').Dropbox;
    const dropbox = {
        dbx: new Dropbox({
            accessToken: process.env.ACCESS_TOKEN,
            pathRoot: JSON.stringify({ '.tag': 'namespace_id', 'namespace_id': process.env.NAMESPACE_ID })
        })
    };
    const payload = {
        path: '',
        recursive: true,
        include_media_info: false,
        include_deleted: false,
        include_has_explicit_shared_members: true,
        include_mounted_folders: true,
        include_non_downloadable_files: true
    };

    let hasMore = true;
    let entries = [];
    let response;
    let cursor;

    while (hasMore) {
        try {
            if (cursor) {
                response = await dropbox.dbx.filesListFolderContinue({ cursor: cursor });
            }
            else {
                response = await dropbox.dbx.filesListFolderGetLatestCursor(payload);

                response = await dropbox.dbx.filesListFolderContinue({ cursor: response.result.cursor });

            }

            console.info('Entries: ', JSON.stringify(response.result.entries));

            cursor = response.result.cursor;
            entries = entries.concat(response.result.entries);
            hasMore = response.result.has_more;
        }
        catch (error) {
            console.info(error);
            return error;
        }
    }
}

main();

Error log:

2022-01-20T08:22:18.579Z	67caa239-e75c-46ce-be4c-0fcf6c154694	INFO	FetchError: request to https://api.dropboxapi.com/2/files/list_folder/continue failed, reason: connect ETIMEDOUT 162.125.4.19:443
    at ClientRequest.<anonymous> (/var/task/node_modules/dropbox/node_modules/node-fetch/lib/index.js:1483:11)
    at ClientRequest.emit (events.js:400:28)
    at TLSSocket.socketErrorListener (_http_client.js:475:9)
    at TLSSocket.emit (events.js:400:28)
    at emitErrorNT (internal/streams/destroy.js:106:8)
    at emitErrorCloseNT (internal/streams/destroy.js:74:3)
    at processTicksAndRejections (internal/process/task_queues.js:82:21) {
  type: 'system',
  errno: 'ETIMEDOUT',
  code: 'ETIMEDOUT'
}

@ridvankartal It looks like you’re not getting the exact same error as originally reported in this thread. The original reports were about a generic «Failed to fetch» error, but you’re getting an «ETIMEDOUT» error. Anyway, I’ll reply on your forum thread. By the way, for future reference, it is not necessary to post the same issue in multiple places.

Источник

Процесс подключения к регистратору выбытия:

Подключение к регистратору выбытия через приложение «TestRV»

Процесс подключения к регистратору выбытия:

Fetch выдает ошибку «TypeError: Failed to fetch» ​​при успешном запросе того же происхождения.

О том, как работать с регистратором выбытия: подключить, настроить и исправить частые ошибки

Суть устройства

Как подключить регистратор выбытия / начало работы

Как подключиться к сети интернет

Индикаторы соединения

Три типа подключения регистратора выбытия: компьютер, локальная сеть и автономный режим

РВ подключен к ПК

РВ подключен в локальную сеть

Автономная работа

Синхронизация с ГЛОНАСС

Как настроить

Частые проблемы и пути их решения

Если регистратор выбытия завис

Если РВ не заряжается

Ошибка 5090

К кому обращаться за тех. поддержкой и ремонтом

Инструкции для регистратора выбытия

Issue Description

Resolution

Resolution 1

Resolution 2

Resolution 3

Resolution 5

Resolution 6

Читайте также:

Fetch выдает ошибку «TypeError: Failed to fetch» при успешном запросе того же происхождения.