он добавляет строку, которую ты ему подсунул)) О том что это токен и что такое токен вообще - он понятия не имеет. Это знает твой бек, а не интерсептор

и не хочется делать  !req.url.includes('

так вот я и хочу, что бы интерсептор останавливался и ждал access-token’a если его нет и сразу его брал если он есть

и за чем мне посылать заведомо не правильный запрос, access-token’a то нет

и без backend’a понятно

Это не интерсептор тогда. Это сервис. Интерсептор не предназначен для подобных операций.  КмК - идея в принципе не очень хорошая контролить токены на этом слое. Ок, на месте токена есть НЕЧТО - да хоть просто строка "гы" - как мы проверим, токен это или нет? Следующий шаг - если мы все равно ждем токена, давайте убедимся что он валиден. Итог - мы перенесли авторизацию куда??? в интерсептор фронта? Гениально)))

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

равно как и в обратном направлении)))

не, проверять не надо, просто посылать если он есть

каким образом узнать, что он есть?

я храню его в ngrx т.е. в Observable

вопрос то и был как ждать первое значение или сразу брать его если уже есть

забудем про механику где хранится. мы выяснили, что там ЧТО ТО есть. Что мы делаем?

если есть посылаем запрос если нет, ждем токен

ок. послали.  токен не валидный. Что происходит дальше?

от backend’а получаю 401 и иду на login

и в итоге - получаешь валидный токен. Верно?

да,
и незабывай токен можно получить и без login’a, например и localstore

Интересно, обычно делают проверку refresh_token и если он не валиден, то отправляют на logo

xoтя про localstore я погорячился, сейчас это не имеет значения