Спасибо. Блин, переделывать буду.

Как можно поправить, чтобы проваливались?

Сделать серию if-ов. По строчкам будет то же самое

Я конечно не ученый, но у меня проваливается во все условия. Может есть какой нить вариант с циклами или рандомными проверялками? В программистике недавно.

Так и должно быть. Вы что хотите сделать? По логике?

Вывести логи по разным фильтрам(опциональным).

Так у вас могут сразу несколько условий быть верными. Как вы их дифференцируете?

@why_oleg Еще вопрос. Вот у меня есть де факто два встречно-направленных Flow, один из них в API сделан как подписка, другой как много раз единичный send. Я сейчас продублировал это как один sendAndForget и один requestStream. Но я только что подумал, что это можно было бы сделать при помощи заворачивания локальной отправки в callbackFlow и использования requestChannel. Будет ли так лучше? Как я понял как минимум будет менье установлений соединения

it depends
сложно сказать, что удобнее
зависит от того, насколько нужно знать, связаны ли это send или нет
если важно знать, что это поток значений или нужен backbressure - то лучше requestChannel


на счёт:
> Как я понял как минимум будет менье установлений соединения
соединение же будет всегда одно, просто будут слегка разные фреймы, по сути разницы нет

Точно не нужно. В смысле порядок. Он на уровне протокола вообще не регламентируется

Ну если я много раз fireAndForget делаю, то там вроде как должны быть какие-то накладные расходы

нет по сути
3 fireAndForget = 3 FAF frames
requestChannel with 3 elements = 1 RC frame + 2 Payload frames
единственный возможный оверхед это backpressure (RequestN)

+ с fireAndForget будет слегка проще наверно, если надо слать из разных мест кода

а связаны ли эти send и результ requestStream?

Нет, не связаны. Канал выгляди лучше. Единственное, я не вижу, можно ли там параметры канала первым фреймом как-то передать.

параметры? просто в payload(data/metadata), если я понимаю, что Вам нужно

Ну в requestStream. есть первый фрейм, которым можно сообщить параметры и сингнатура Payload->Flow<Payload>. У requestChannel сигнатура Flow<Payload>->Flow<Payload>. Можно ли передать отдельный первый фрейм для конфигурации?

почему бы не послать его просто внутри flow?
условно request:
flow { emit(configurationPayload); .... other logic }

Ну можно, просто логика усложняется. Там тогда надо на той стороне тоже первый элемент отщеплять. Хорошо, я подумаю.

>Там тогда надо на той стороне тоже первый элемент отщеплять
я сейчас тоже об этом думаю, как это сделать лучше, так как во flow не так просто отделить первый элемент, если flow single collectable
есть 2 решения:
1. продьюсить в канал, взять первый элемент и сконвертировать обратно во flow этот канал - возможно, но не приятно
2. поменять сигнатуру requestChannel
still WIP

А что с родым API?

Просто там есть некоторая проблема с обработкой реконнектов. Там будет не понятно, какой фрейм первый