Help with actors and supervisors | The Gleam Programming Language | Page 1

rich surge Feb 5, 2026, 5:02 PM

#

I'm having some issues with trying to set up actors and supervisors.

The code is a bit too large for discord message, so here is a gist: https://gist.github.com/mooreryan/f5746df4105072a6bce09d973b0031e4

The error I'm getting is this:

=SUPERVISOR REPORT==== 5-Feb-2026::11:49:08.154546 ===
    supervisor: {<0.83.0>,gleam@otp@static_supervisor}
    errorContext: child_terminated
    reason: <<"oops">>
    offender: [{pid,<0.84.0>},
               {id,0},
               {mfargs,
                   {gleam@otp@static_supervisor,start_child_callback,
                       [#Fun<gleam@[email protected]>]}},
               {restart_type,permanent},
               {significant,false},
               {shutdown,5000},
               {child_type,worker}]

runtime error: panic

callee exited: ProcessDown(//erl(#Ref<0.68767505.3939500033.239374>), //erl(<0.84.0>), Abnormal("oops"))

stacktrace:
  gleam/erlang/process.-perform_call/3-anonymous-1- src/gleam/erlang/process.gleam:626
  gleam_erlang_ffi.select /Users/ryan/Projects/tmp/xx/build/dev/erlang/gleam_erlang/_gleam_artefacts/gleam_erlang_ffi.erl:60
  gleam/erlang/process.perform_call src/gleam/erlang/process.gleam:644
  xx.main src/xx.gleam:56

There were a couple other questions that got similar errors:

But, I wasn't able to figure out what was going wrong with my code from them.

(I have some experience with Elixir, having read Elixir in Action, but have only made toy apps with it, and am not comfortable with OTP.)

Gist

actors & supervisors issue

actors & supervisors issue. GitHub Gist: instantly share code, notes, and snippets.

viscid tiger Feb 5, 2026, 5:05 PM

#

You’re deliberately abnormally exiting

#

What is it you are expecting the behaviour to be?

rich surge Feb 5, 2026, 5:06 PM

#

I thought that the supervisor would catch abnormal exits (or really I thought any "crashes"). Eg, I tried a panic to see if it would restart

viscid tiger Feb 5, 2026, 5:08 PM

#

Supervisors don’t catch exits, they restart processes

#

The caller isn’t supervised. It’s the main process so if you panic that then it dies

rich surge Feb 5, 2026, 5:09 PM

#

yeah I guess I need to go back and reread elixir in action

rich surge Feb 5, 2026, 5:10 PM

#

viscid tiger The caller isn’t supervised. It’s the main process so if you panic that then it ...

I did try a 2nd version, which changes that main function to some other name, and then starts that in a supervisor, but that also failed....so its def a skill issue

viscid tiger Feb 5, 2026, 5:45 PM

#

It's not the fact that it's called main

#

The code crashes because it's written to crash, and as it's being run by the main process the program fails

#

What is it you expect to happen?

rich surge Feb 5, 2026, 7:00 PM

#

I thought the supervisor would restart the process. Like say I called erlang:error(oops) inside a process that was supervised, I thought that the supervisor of that process would say "hey, this processes terminated, I better restart it"

#

Like when the docs here (https://www.erlang.org/doc/system/sup_princ.html#one_for_one) say "terminates", I think I'm not understanding what the word terminate means in this context

mossy salmon Feb 5, 2026, 7:03 PM

#

  actor.call(squidward_subject, timeout, fn(subject) {
    GreeterMessage(client: subject, name: "Patrick")
  })
  |> io.println

when this code runs the message sent to eh process causes it to exit, which means it does not reply to the call, which means this process (your main process) crashes

#

a call expects a response

rich surge Feb 5, 2026, 7:06 PM

#

ohh, so calling call crashes the calling process?

viscid tiger Feb 5, 2026, 7:07 PM

#

runtime error: panic

callee exited

#

ya

#

It panics because the callee exited

mossy salmon Feb 5, 2026, 7:07 PM

#

Send a synchronous message and wait for a response from the receiving process.

If a reply is not received within the given timeout then the sender process crashes rather than leaving the processes in an invalid state.

rich surge Feb 5, 2026, 7:07 PM

#

Ohhh: Panics
This function will panic under the following circumstances:

The callee process exited prior to sending a reply.
The callee process did not send a reply within the permitted amount of time.
The subject is a named subject but no process is registered with that name.
(from the docs)

#

https://hexdocs.pm/gleam_erlang/gleam/erlang/process.html#call

mossy salmon Feb 5, 2026, 7:08 PM

#

you send a message to squidward, then squidward exists and doesnt send a reply, then time timeout expires and the caller crashes because it never got a reply

#

so it doesnt matter that the supervisor restarted squidward (it did), your code is waiting for a reply that wont come and then crashes when the timeout runs out

rich surge Feb 5, 2026, 7:09 PM

#

Interesting. Okay, I think I understand a bit more than before at least. I switched the code around so that the process running all the call functions sends like process.send_exit(pid) or process.kill(pid) and the process i sent those to does get restarted

rich surge Feb 5, 2026, 7:10 PM

#

mossy salmon so it doesnt matter that the supervisor restarted squidward (it did), your code ...

Thanks, I think I sort of understand this

viscid tiger Feb 5, 2026, 7:11 PM

#

mossy salmon you send a message to squidward, then squidward exists and doesnt send a reply, ...

nit: it doesn't timeout, it knows the callee exits as it is monitored

mossy salmon Feb 5, 2026, 7:11 PM

#

neat 💕

viscid tiger Feb 5, 2026, 7:12 PM

#

Same thing just less waiting

rich surge Feb 5, 2026, 7:12 PM

#

So, if this were a real app, and I used call , and for some reason the process that was the subject of that call crashes and call doesn't receive a reply, then how do I recover from that? Ensure that the caller of call is also in the supervision tree?

mossy salmon Feb 5, 2026, 7:12 PM

#

your supervision tree is like this

app
|
static supervisor
|         \
spongebob  squidward

if app exits or crashes theres nothing above it to restart it

rich surge Feb 5, 2026, 7:13 PM

#

so if I put this into an otp application, would that be the right thing to do?

viscid tiger Feb 5, 2026, 7:14 PM

#

Put what in an OTP application?

#

What would be the right thing to do about what?

rich surge Feb 5, 2026, 7:15 PM

#

well, I thought in a real app I probably wouldn't have a supervisor called in main. I would set up an otp application and run the erlang shipment (I thought)

viscid tiger Feb 5, 2026, 7:15 PM

#

Yeah!

rich surge Feb 5, 2026, 7:19 PM

#

Okay, so ... currently its like this:

app
|
static supervisor
|         \
spongebob  squidward

But that app thingy also needs to be supervised? I'm still trying to understand how to address this:

So, if this were a real app, and I used call , and for some reason the process that was the subject of that call crashes and call doesn't receive a reply, then how do I recover from that? Ensure that the caller of call is also in the supervision tree?

viscid tiger Feb 5, 2026, 7:21 PM

#

You don't recover, it crashes and those processes would be restarted (and possibly their siblings depending on how your tree is designed)

#

If you use the OTP application system to start your supervision tree the top supervisor of your application is supervised by the application controller

rich surge Feb 5, 2026, 7:32 PM

#

Thanks for the help y'all! I think this is just beyond my skill level at the moment. I will keep trying to figure out OTP though

plush sinew Feb 5, 2026, 8:22 PM

#

I think that if you replace the actor.callwith just:

#

process.send(subject, GreeterMessage(..))
process.receive(client_subject, timeout) |> io.println

You will not monitor the remote and your main process will not crash.

plush sinew Feb 5, 2026, 8:54 PM

#

But yes, you should move your client process(es) under supervisor tree(s) as well.

#Help with actors and supervisors