Ну тогда только исключать параллельные запросы.
Соединять их в цепочку помисов (как писал ksa)

А нельзя после этой ошибки повторить запрос с новым (обновленным) токеном?

здесь есть несколько интересных моментов
1. в теле токена есть дата когда он протухнет. незачем дергать сервак с заранее протухшим токеном. (Лень фронтэндщика :lol: )
2. вопрос это по поводу токенов. Типичная работа с токенами jwt подразумевает возможность иметь множество валидных токенов(Токены не хранятся в базе!!! ). Разные клиенты, браузеры ...
В данном случае шансы зацикливания минимальны.
3. Всегда можно реализовать очередь, очередь с приоритетами или выбрать другое пдходящее решение
Что до ТС, самый лучший код - отсутствие кода.
Когда я смотрю на ваш код, думаю, зачем вы его пишите. Может вам платят за кол-во

Спасибо за замечание. Пока не планируем разбирать токены на клиенте.

Не понял. После каждой авторизации (разные устройства, браузеры) для пользователя создаётся отдельный токен, да. Или что ты имеешь ввиду под "множество валидных токенов"? Как "множество валидных токенов" связано с зацикливанием?

Совет из разряда "написать код на компьютере для того, чтобы что-то работало")) Ну ок.

Наверное, ты не поверишь, но всё же: не все с рождения умеют делать всё правильно :yes: Или форумы и проф.комьюнити не нужны?

Не представляю как это сделать.
Пришло "просрочен" - отправляем рефреш.
Пришло "не верный" - выбрасываем.
А если после каждого "не верный" отправлять рефреш - то по какому индикаторы стоит прекратить его отправлять?))

Была попытка сделать нечто типо такого, но в итоге всё равно изредка выбрасывало. Так и не смог тогда диагностировать что где не успевает обновиться.
Создали в сторе свойство (bool), которое переключалось в true после того, как какой-то компонент приложения посылал рефреш. Остальные компоненты, во время запроса проверяли это свойство и, если оно true - ждали изменение в false, затем получани токен (через rootState, из модуля с токеном, в котором уже обновились ключи) и продолжали запрос.
Покопаюсь в коммитах и постараюсь выложить код из той ветки :write:

Самый простой вариант, как я понимаю - это просто убрать у экшенов async?)) Но вот совсем не хочется загружать компоненты в приложении синхронно...

.catch(async e => {
                if (e.response.status === 401 && checkExp(this.refreshToken) && await this.refresh()) {
                    return this[method](path, params)
                } else {
                    console.log(e)
                    return location.href = '/login'
                }
            })

и токены лучше проверять

const parse = token => {
  const base64Url = token.split('.')[1];
  const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
  return JSON.parse(decodeURIComponent(atob(base64).split('')
    .map(c => '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2)).join('')));
}
const check = (token, type)=> {
  try {
    const data = parse(token)
    return (new Date(data[type] * 1000)) > (new Date())
  } catch (_) {
    return false;
  }
}
export default {
  checkExp(token) {
    return  check(token, 'exp')
  },
  checkIat(token) {
    return  check(token, 'iat')
  }
}

Если я правильно понимаю, "Не верный" приходит в ответ на запрос2, когда у запроса1 был "просрочен" и после этого сделали рефреш ( а запрос2 все еще обращается со стары токеном) .
Ну и повторите запрос2 уже с новым токеном, а не выбрасывайте. Дождитесь окончания рефреша (через промис) и повторите.

Не делайте рефреш после "не верный". Он уже сделан после "просрочен", просто не успел прийти. Дождитесь окончания рефреша и повторите запрос с новым токеном.