feat(orchestrator): membrane-friendly timerUtils

[0xpatrickdev]

refs: #9449

Description

Towards the goal of membrane compatibility. TimerUtils are not an endowment for orchestrate, nor currently consumed in an async flow, but is consumed by exos/local-orchestration-account.js. It's also planned to be consumed by exo/scosmos-orchestration-account.js

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	4c68b4e
Status:	✅  Deploy successful!
Preview URL:	https://4ee8317e.agoric-sdk.pages.dev
Branch Preview URL:	https://pc-resumable-timer-utils.agoric-sdk.pages.dev

View logs

[turadg]

There's a bug in the brand cache.

Also I think I misspoke in calling chainHub resumable in my recent PR. It's returning vows (and thus satisfies 9449) but I think resumable is a higher bar, with durable facets for the watcher callback object. I didn't encounter problems until I used the real vowTools for when and watch instead of the module imports.

bug was fixed

Refactored to use asVow and durable watcher handlers, so this review is too stale

[dckc]

is an exo for timerUtils really worthwhile? How about making getTimeoutTimestampNS a stateless helper function?

Have it return take an optional timerBrand and return { timestamp, timerBrand } so that the caller can cache the timerBrand if they like. The returned timerBrand would be undefined unless (a) the caller provided it or (b) this function needed to look it up.

[0xpatrickdev]

is an exo for timerUtils really worthwhile? How about making getTimeoutTimestampNS a stateless helper function?

Have it return take an optional timerBrand and return { timestamp, timerBrand } so that the caller can cache the timerBrand if they like. The returned timerBrand would be undefined unless (a) the caller provided it or (b) this function needed to look it up.

My understanding of #9449 is that we'll run into an issue since getTimeoutTimestampNS makes a remote call with E. #9541 is likely the better approach for this scenario - since this is indeed stateless helper function - but that's not ready yet. This code might have a short lifespan but seems necessary towards unblocking us on #9281.

[dckc]

My understanding of #9449 is that we'll run into an issue since getTimeoutTimestampNS makes a remote call with E.

I'd like to see a test to show that there is such an issue.

I don't think either the calling vat nor the timer service can be upgraded during a call to getCurrentTimestamp(). Surely that's not among the issues we need to address urgently.