You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At time of writing, there are a number of hurdles to debugging pet dæmon workers, not least of which is documenting the portion of that story that works. That is:
To start your dæmon in debug mode, you need to spawn it from your CLI with the node --inspect flag. Today, that looks like:
This ought to be a single endo subcommand that unconditionally restarts the daemon in debug mode. All workers currently inherit the debug flags by virtue of child_process.fork.
Once a debugger is attached, we do fine until we discover that the workers are running without Mathieu’s accommodations for async_hook (which is entrained by the debugger). This is simple neglect to use @endo/init. We instead import ses, shims, and @endo/lockdown/commit.js manually, much of which can be simplified.
Description of the Design
Presumably something like endo restart --inspect would start a debugger session. That requires us to figure out how to thread --inspect when using child_process.fork or fall back to child_process.spawn and set up IPC manually. (We currently daemonize the daemon and wait to hear it’s successfully started listening on its designated interfaces.)
Then we just need to use @endo/init instead of rolling our own version of that manually.
Within a VSCode terminal session with the attached debugger, the following should pause on the debugger line in debugme.js.
What is the Problem Being Solved?
At time of writing, there are a number of hurdles to debugging pet dæmon workers, not least of which is documenting the portion of that story that works. That is:
To start your dæmon in debug mode, you need to spawn it from your CLI with the
node --inspect
flag. Today, that looks like:This ought to be a single
endo
subcommand that unconditionally restarts the daemon in debug mode. All workers currently inherit the debug flags by virtue ofchild_process.fork
.Once a debugger is attached, we do fine until we discover that the workers are running without Mathieu’s accommodations for
async_hook
(which is entrained by the debugger). This is simple neglect to use@endo/init
. We instead importses
, shims, and@endo/lockdown/commit.js
manually, much of which can be simplified.Description of the Design
Presumably something like
endo restart --inspect
would start a debugger session. That requires us to figure out how to thread--inspect
when usingchild_process.fork
or fall back tochild_process.spawn
and set up IPC manually. (We currently daemonize the daemon and wait to hear it’s successfully started listening on its designated interfaces.)Then we just need to use
@endo/init
instead of rolling our own version of that manually.Within a VSCode terminal session with the attached debugger, the following should pause on the
debugger
line indebugme.js
.Furthermore, this should work:
As written today, that reports an error since the returned promise has async_hook symbol own properties that the marshaler does not expect.
Security Considerations
None.
Scaling Considerations
None.
Test Plan
TBD.
Compatibility Considerations
None.
Upgrade Considerations
None.
The text was updated successfully, but these errors were encountered: