make Zoe durable

[Chris-Hibbert]

closes: #4383
refs: #6502

Description

Make Zoe durable.

The prior version passed around many bundles of functions. Those had to be converted to durable facets to be passable.

Security Considerations

Pervasive

Documentation Considerations

seat notifiers (which notified on interim allocations) have been dropped and replaced with a subscriber that only notifies when the seat exits.

The way feeMintAccess is obtained changed.

The methods that allowed requests for internal allocation state (getCurrentAllocationJig) has been dropped. Many of the clients can use getFinalAllocation() instead.

zoe.bindDefaultFeePurse, zoe.makeFeePurse, and zcf.assert() were dropped.

Testing Considerations

Test timing changed in some cases, since Promises can no longer be used.

[erights]

Review so far. I got through all of zcf and everything but zoe itself. Of course, zoe is where the action is, so it will still take significant time to complete.

High level comment so far: I don't understand why zcf needed such radical surgery, since coveredCall-durable.js already demonstrates that zcf is upgradable. If we really were saving all the precious semantic state that the successor needs to revivify a working zcf, then the additional durable things seem like a distraction.

[Chris-Hibbert]

High level comment so far: I don't understand why zcf needed such radical surgery, since coveredCall-durable.js already demonstrates that zcf is upgradable. If we really were saving all the precious semantic state that the successor needs to revivify a working zcf, then the additional durable things seem like a distraction.

This is an important question.

The original Zoe and ZCF shared some state using Promises and bags of functions. It's no longer possible for Zoe to hold onto a loose function, so some things that didn't have to be durable object for the ZCF upgrade case have to be durable In order for Zoe to hold onto them.

[erights]

This review pass done.

[erights]

Just that one remaining issue in the declaration of BundleShape.

LGTM!

[erights]

I think this was more correct before literally taking @kriskowal 's advice.

• @Chris-Hibbert , We still need the { stringLengthLimit: Infinity } to evade the limit check, right?
• @kriskowal , M.partial is deprecated in favor of M.splitArray and M.splitRecord.
• @kriskowal , By using M.partial you're saying that moduleFormat is optional, as did the old code when the first argument to splitRecord was harden({}). But your prose says it is mandatory. Assuming it is mandatory, I removed that first argument to splitRecord below.

So, does the following look right?

export const ModuleFormatBundleShape = M.splitRecord(
  harden({ moduleFormat: M.any() }),
);

export const BundleShape = M.and(ModuleFormatBundleShape, SourceBundleShape);

[erights]

(just edited my suggested code from M.or to M.and)

[Chris-Hibbert]

We still need the { stringLengthLimit: Infinity } to evade the limit check, right?

I believe so. It's still in SourceBundleShape. I don't think it's necessary anywhere else.

export const SourceBundleShape = M.recordOf(
  M.string(),
  M.string({ stringLengthLimit: Infinity }),
);

[Chris-Hibbert]

I pushed this change, and tests are passing now.

@kriskowal with your agreement that this change is correct, I'll merge this PR.

[kriskowal]

Suggested change

	export const SourceBundleShape = M.recordOf(
	M.string(),
	M.string({ stringLengthLimit: Infinity }),
	);
	export const ModuleFormatBundleShape = M.splitRecord(
	harden({ moduleFormat: M.any() }),
	);
	export const BundleShape = M.and(ModuleFormatBundleShape, SourceBundleShape);
	export const BundleShape = M.and(
	M.splitRecord(harden({ moduleFormat: M.string() })),
	M.recordOf(
	M.string(),
	M.string(harden({ stringLengthLimit: Infinity })),
	),
	);

How does splitRecord differ from partial? Is harden necessary there in a way that would apply equally to M.string’s arg?

The bundle shape described in this way applies equally well to source bundles and hash bundles, so the intermediate names are not useful. If we wish to cut finer distinctions, we’ll need shapes for SourceBundle and HashBundle that are the union of supported formats in each case. HashBundle is of the form { moduleFormat: 'endoZipBase64Sha512', endoZipBase64Sha512: string } and SourceBundle is one of { moduleFormat: 'getExports', source: string }, { moduleFormat: 'nestedEvaluate', source: string }, or { moduleFormat: 'endoZipBase64', endoZipBase64: string, endoZipBase64Sha512?: string }.

[Chris-Hibbert]

I switched to this simplified BundleShape, and used it in all the places BundleShape or SourceBundleShape appeared. I'll merge like this.