Candid Health Software Engineer Interview Experience — Phone Screen on Designing a Pub/Sub Signaling System

I recently interviewed with Candid Health, a healthcare insurance startup.
I basically couldn't find any specific interview reports for this company on the forum. Afterwards I used Claude to dig through Glassdoor and found some related info. The question I actually got in the phone screen mostly matched what I had found.
The question is roughly: implement a signaling system, which you can think of as a very simple pub/sub. You need to define 3 functions:
1.
register_callback(id, callback)
-> must return null
2.
unregister_callback(id, callback)
-> must return null
3.
signal(id)
-> must return null
Here a callback is just a callable function, e.g. Callable in Python.
Roughly how it's used:
register_callback(10, fn_foo)
register_callback(10, fn_bar)
signal(10) -> runs fn_foo, fn_bar
unregister_callback(10, fn_bar)
signal(10) -> only runs fn_foo
signal(200) -> nothing happens
The problem is deliberately open-ended, and you're not supposed to just put your head down and start coding. You need to proactively ask clarifying questions and surface the various failure modes / edge cases, because the interviewer keeps probing around those afterwards.
The follow-ups I got were roughly:

1. Do callbacks need to run in the order they were registered?
2. If one callback throws an exception, should the remaining callbacks still run?
3. If a callback itself calls signal(), causing a recursive / reentrant loop or even an infinite loop, how do you guard against that? You can search for reentrant loop prevention ahead of time.
4. How do you plan to store the callbacks underneath? For example, can you just put them in a dict / set, which means thinking about whether the callback itself is hashable, and so on.
   I feel the code itself isn't hard. What matters is whether you can proactively pin down the requirements and whether you've thought through these edge cases.