I took a peruse through the code, and my biggest suggestion would be to just use Task and Task.Supervisor instead of GenServer, which would probably clean the code up a bit (Task.Supervisor is a DynamicSupervisor!) You could also use PartitionSupervisor with it, but I don’t think invoking the supervisor will be your bottleneck if you only have 250-ish tasks.

All in all, nice job! We had some code at my job that looked pretty similar to this running an automated integration test suite against prod

Everything is a process including supervisors, their only difference is that they catch exits from their child processes and restarts them, you can decide whether your topology makes sense.

I also thought using a TaskSupervisor inside a Task would be bad practice. Do you think it’s okay to do this, or could it lead to some issues?

I’m not sure what you mean? Your code can call code in another module at any time, nothing is really “special”.

I think once you start adding a few more tests, you’ll find the parts of this program that could be abstracted a bit, but as far as the code goes, it really is great, for your first shot at a “real OTP program” you’ve done a great job.

There are a few nitpicks I’d say, like rather than cast()-ing to yourself here, I’d use the {:continue, ...} return from init: auto_grader/lib/auto_grader.ex at dev · sheerlox/auto_grader · GitHub

You’re also doing a lot to store the parent pid, then send a message back when processing is done, whereas you could use the Task abstraction and just return the value.

If you’re writing use GenServer, restart: :temporary you may instead want a module that use Task instead.