slogger surprisingly hardens console.log() arguments

[warner]

While debugging some #2018 changes that attempted to apply Far() to an object, I ran into some very weird behavior. I tracked it down to the fact that my slogger code was independently calling harden() on the arguments it received. Because vats get a console which also routes to the slogger, and because Far() and Remotable() cannot be called on already-harden()ed objects, my diagnostic logging was changing the state of the objects under observation, which cost me several hours trying to unwind the weirdness.

agoric-sdk/packages/SwingSet/src/kernel/slogger.js

Lines 19 to 21 in 8afe604

	export function makeSlogger(writeObj) {
	const write = writeObj ? e => writeObj(harden(e)) : () => 0;

The fix is simple: remove that harden(). I'm not entirely sure why I included that call.. I try to be in the habit of harden()ing anything before allowing it to leave the function I'm writing, but now I think that's the wrong instinct. Rather, I should harden() only when creating a new object: if someone else handed the object to me, it is their responsibility to harden it, and it would be surprising for me to harden() it for them.

cc @erights to see if I'm updating my instincts correctly

[erights]

I should harden() only when creating a new object: if someone else handed the object to me, it is their responsibility to harden it, and it would be surprising for me to harden() it for them.

cc @erights to see if I'm updating my instincts correctly

Correct. Usually literally correct, but there's one valid pattern where this is correct once we expand the meaning of "create".

Sometimes one need to do some further computed initialization before exposing the object to clients. An object lifecycle is often

• literally create the object. Keep it closely held.
• initialize the object. Keep it closely held during initialization.
• initialization is complete. All invariants are in place. It is ready to be exposed to clients.
• harden it
• expose it to clients.