Возможно нужно умирать от call, если ген-сервер завершился нештатно. И точно не нужно умирать от call, если ген-сервер завершился штатно.

Нагородил, потом посмотрел и сравнил с кодом call ))

Нет, нужно чтобы call отдавал ответ и caller мог сам решить, что делать с этим

В зависимости от системы, ситуации, архитектуры.

ну и как это сделать? держать в памяти причины завершения всех сдохших процессов? Это утопия

Нет, зачем держать в памяти? А, не мне ответ.

Вот именно, делать свой ref, с пидом передавать его через cast - короче переизобретать call.

Да,  call должен отдавать 3 вида ответов: ok-result, timeout-norm, timeout-crash. А вызывающий процесс пусть разбирается с ними.

ну и как вызывающему процессу понять сдох ли процесс позавчера нормально или от краша?

Похоже что можно сделать линк если хочешь «умереть вместе»

Ну я же сказал, как. Использовать управление ресурсами на базе монитора. Например, пул воркеров.

А если у тебя не воркеры, стартовать под каждый новый процесс poolboy с ровно одним процессом, лишь бы не кетчить ответ генсервера?

И что пул воркеров держит информацию о все сдохших процессах?

процесс сдох, а обратились к нему через месяц, пул должен весь месяц помнить от чего скончался процесс?

в БД писать эту инфу? Накой?

Я все еще не понимаю, почему поведение должно зависеть от того, штатно или не штатно завершился процесс к которому ты идёшь

я тоже не понимаю. мне лично не нужно, Дмитрию вроде тоже

Этим скорее всего займётся кто-то другой

Супервизор там, или монитор того процесса

Опять же проблема бы решилась, если бы gen_server вместо exit-ов передавал ошибку в код дальше и был бы call!, который вёл бы себя как старый call и крэшился бы на ошибках. Но это слишком глубоко в OTP, чтобы это кто-то когда-то решил бы поменять - поэтому все Erlang и Elixir разработчики, когда такая необходимость появляются - используют try catch. И 6 лет назад уже использовали и используют сейчас. И нет в этом ничего плохого и никакая это не ошибка.