Add networked debugging to Questie via CapTP #79

flockofbirbs commented 2023年03月07日 15:15:16 +01:00 (Migrated from gitlab.com)

It is an open question as to how we implement this. Needs some serious thought...

It is an open question as to how we implement this. Needs some serious thought...

flockofbirbs commented 2025年10月23日 15:12:09 +02:00

Here is the current situation. The trace of (with-vat vat-a (<- bob "Alice")) is currently disconnected near the CapTP boundary. Starting from the entry point, we only see this:

Vat A, 44: (message #<local-object ^call-with-vat>)
├▸ Vat A, 45: (message #<local-promise> "Alice")
└▸ Vat A, 46: (listen #<local-promise>)

I was hoping to at least see a CapTP actor show up here, but alas it does not. So, there's a gap in our local-only tracing that needs to be dealt with.

Starting from the end and working backwards, we see this:

Vat A, 207: (message #<local-object #{swappable: ^setup-completer}#> #<<op:deliver-only> to-desc: #<<desc:export> pos: 2> args: (fulfill "Hello, Alice! My name is Bob.")>)
└▸ Vat A, 208: (message #<local-object resolver> fulfill "Hello, Alice! My name is Bob.")
 └▸ Vat A, 209: (message #<local-object ^resolver> fulfill "Hello, Alice! My name is Bob.")
 └▸ Vat A, 210: (message #<local-object ^resolver> fulfill "Hello, Alice! My name is Bob.")
 └▸ Vat A, 211: (message #<local-object ^on-listener> fulfill "Hello, Alice! My name is Bob.")
 └▸ Vat A, 212: (message #<local-object fulfilled-handler> "Hello, Alice! My name is Bob.")

This at least shows that the promise resolution was caused by an op:deliver-only message.

We need a way to link a local event with a remote one, so that we can stitch together these two partial event trees. Some ideas:

1. Each side of a CapTP session could have a monotonically increasing message counter so they can keep a side table mapping remote message ids to the relevant local message.
2. Each side of a CapTP session could likewise have a side table mapping local messages to remote message ids.
3. The bootstrap object could be extended with methods for querying based on remote message id.

There are some difficulties to making this plan work as Goblins is currently implemented.

1. The CapTP implementation speaks "high-level" Goblins for message dispatch. For example, op:deliver-only results in (apply <-np target args). The underlying <message> object that this creates is inaccessible to CapTP, so there's no way to create the mapping described in item 1 above. If we could instead speak in terms of low-level messages then we'd have something that is eq? that would be stored in a vat event record and CapTP's debug side table.
2. Vat event records have no way of recording that a local event is linked to a CapTP event. We need a way for a local vat event to point at a CapTP event so the debug tools can reach out via <- to gather the remotely held debug data. This may require changes at the vat connector level.

Here is the current situation. The trace of `(with-vat vat-a (<- bob "Alice"))` is currently disconnected near the CapTP boundary. Starting from the entry point, we only see this: ``` Vat A, 44: (message #<local-object ^call-with-vat>) ├▸ Vat A, 45: (message #<local-promise> "Alice") └▸ Vat A, 46: (listen #<local-promise>) ``` I was hoping to at least see a CapTP actor show up here, but alas it does not. So, there's a gap in our local-only tracing that needs to be dealt with. Starting from the end and working backwards, we see this: ``` Vat A, 207: (message #<local-object #{swappable: ^setup-completer}#> #<<op:deliver-only> to-desc: #<<desc:export> pos: 2> args: (fulfill "Hello, Alice! My name is Bob.")>) └▸ Vat A, 208: (message #<local-object resolver> fulfill "Hello, Alice! My name is Bob.") └▸ Vat A, 209: (message #<local-object ^resolver> fulfill "Hello, Alice! My name is Bob.") └▸ Vat A, 210: (message #<local-object ^resolver> fulfill "Hello, Alice! My name is Bob.") └▸ Vat A, 211: (message #<local-object ^on-listener> fulfill "Hello, Alice! My name is Bob.") └▸ Vat A, 212: (message #<local-object fulfilled-handler> "Hello, Alice! My name is Bob.") ``` This at least shows that the promise resolution was caused by an `op:deliver-only` message. We need a way to link a local event with a remote one, so that we can stitch together these two partial event trees. Some ideas: 1) Each side of a CapTP session could have a monotonically increasing message counter so they can keep a side table mapping remote message ids to the relevant local message. 2) Each side of a CapTP session could likewise have a side table mapping local messages to remote message ids. 3) The bootstrap object could be extended with methods for querying based on remote message id. There are some difficulties to making this plan work as Goblins is currently implemented. 1) The CapTP implementation speaks "high-level" Goblins for message dispatch. For example, `op:deliver-only` results in `(apply <-np target args)`. The underlying `<message>` object that this creates is inaccessible to CapTP, so there's no way to create the mapping described in item 1 above. If we could instead speak in terms of low-level messages then we'd have something that is `eq?` that would be stored in a vat event record *and* CapTP's debug side table. 2) Vat event records have no way of recording that a local event is linked to a CapTP event. We need a way for a local vat event to point at a CapTP event so the debug tools can reach out via `<-` to gather the remotely held debug data. This may require changes at the vat connector level.