Поддержка от третьей стороны

Если ты добавляешь говно мамонта, которое никто не мейнтейнит, а потом оказывается, что он не доработан и/или есть баги, никому от этого лучше не будет

Будешь писать патчи? Ок, вариант. Только с нормальным мейнтейном с высокой вероятностью они бы уже были в мастере

Здравствуйте, я новичок в Elixir. Подскажите по naming convention, называть boolean колонки в Ecto лучше is_active или active?

назови лучше колонку "status" и держи там значения "active", "inactive"

в будущем вдруг захочется еще что то добавить, например "disabled", будет просто

подскажите пожалуйста как такое может быть?

1) есть главный процесс в фениксе, он запускает генсервер (FormWorker), который работает под DynamicSupervisor, и запускает WebSockex.start_link
2) затем главный процесс делает FormWorker.call(...), который под капотом дергает в третьем модуле Websockex.send_frame, и он уже отваливается по timeout

pid1 - phoenix request
pid2 - DynamicSupervisor.start_child(FormWorker, child_spec)
pid3 - модуль который использует WebSockex

сначала pid3  отваливается с (EXIT) time out
потом по цепочке в pid2 происходит (EXIT) time out
и в конце умирает процесс феникса pid1

при выходе дочернего процесса (pid2) главный процесс (pid1) же не должен крашиться если pid2 запущен под DynamicSupervisor?

лог феникса:

14:11:56.233 [error] #PID<0.3587.0> running TechMateWeb.Endpoint (connection #PID<0.3586.0>, stream id 1) terminated

Request: POST /forms
** (exit) exited in: GenServer.call(#PID<0.3589.0>, {:request, :full}, 5000)
   ** (EXIT) time out
14:11:57.918 [error] GenServer #PID<0.3589.0> terminating
** (stop) exited in: WebSockex.call(#PID<0.3593.0>, {:text, "{\"eof\" : 1}"})
   ** (EXIT) time out
   (websockex 0.4.2) lib/websockex.ex:431: WebSockex.send_frame/2
   (tech_mate 0.1.1) lib/tech_mate/workflow/form_worker.ex:91: TechMate.Workflow.FormWorker.start_request/4
   (tech_mate 0.1.1) lib/tech_mate/workflow/form_worker.ex:25: TechMate.Workflow.FormWorker.handle_call/3
   (stdlib 3.12.1) gen_server.erl:661: :gen_server.try_handle_call/4
   (stdlib 3.12.1) gen_server.erl:690: :gen_server.handle_msg/6
   (stdlib 3.12.1) proc_lib.erl:249: :proc_lib.init_p_do_apply/3

pid1 у вас отваливается из-за таймаута GenServer.call,
тк этот вызов заканчивается exit(timeout), если ответ не пришел

То есть dynamic supervisor не может спасти в случае таймаута генсервера? Как тогда обработать эту ситуацию чтобы pid1 не падал?

Сейчас я в pid2 просто делаю try catch на :exit pid3 - костыльно но работает

Process.trap_exit true

можно проверять перед call существует ли pid

Pid 3 существует всегда перед вызовом, а потом он падает и за ним падает pid2 вследствие таймаута своего же call

Process.flag trap_exit: true делаю в ините pid2 - это не помогает handle_info :EXIT не отлавливает выход по таймауту pid3

Но отлавливает все остальные причины выхода

Некрофилия пошла

Открыл после работы чат - а тут про наркотики

Шозанах?

Все-таки есть какая либо стандартная практика обработки таймаута call генсервера или тут нормально с try catch?

Гугл что-то ничего дельного не предлагает