new marshal pass-by-ref type: "note" #2974
Description
Problem
We need a way to associate debugging information to errors (e.g. stack trace) in a way that makes it possible to aggregate the information from the distributed sources involved with the error. That requires being able to carry some form of identifier for these errors, while also not forcing the vats encountering the error into undue bookkeeping.
Errors should also remain mostly copy data, and not gain a comparable identity.
Proposed solution
A new pass-by-ref type which like promises does not have a comparable identity (they cannot be used as keys in collections), and unlike promises and remotables does not require any lifecycle management at the protocol level (these are not kept in a clist). Let's call these notes.
Expected usage for errors
Errors created in vats
Errors that are sent or stored would get a note attached to them. When marshalled, the error data would contain a field referencing the note, whose ref would end up in the slots. A system like SwingSet would generate a new n+{id} vref for the note. While notes don't have recognizable identities at the protocol level, like promises, if the note object was previously known to SwingSet (recognized by its JS identity), the vref would be maintained.
How notes become attached to errors is TBD, but marshal could help, possibly using a "well-known" helper to "attach a note to an error". SwingSet is expected to be involved in the note creation and attachment so it can capture the debugging information of the error when doing so.
When transmitting a note, SwingSet would "log" the diagnostic information (stack) and the note's vref.
Handling of received notes
When a vat unmarshals data which contains a note, it may or may not create a new JS object for that note (like for promises) if it had seen that note's ref before. We may want to associate debugging information about the unmarshalling context (e.g. delivery info) when allocating a new object to represent the note.
When retransmitting a note, the marshal caller would simply allocate a new ref specific to that party. In the case of the SwingSet kernel, when receiving a note from a vat, it would allocate a new kn${id} kref for the note (even if that specific note had already been transmitted by the vat), and "log" the "mapping" (but not remember it). When delivering the now kref based note to a vat, the kernel would allocate a new vat specific kn-${id} for the note, making it appearing as new for the vat, and "log" the "mapping".
Usage for debugging
In practice that means these notes can only be used to "talk about them" at the protocol layer, without causing any book keeping on the system seeing them beyond keeping a "next id" for allocation. They would be the only "pass-by-ref" data allowed to be nested inside error data. They likely remove the need to have marshal created error ids visible to users.
Notes are per 2-party connections and do not have any recognizable identity when forwarded. However it's expected that the per connection ref be logged when remapped. That means unlike error ids, they don't reveal any information about their provenance.
A debugging system can collect the local information of all parties that have seen an error by their local connection ref, and following any logged remapping.
Previous
See