-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(daemon): Undeniable host INFO tool #1916
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks plausible. I don't see any correctness issues.
without tests, I defer to others to approve
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see types for these interfaces. I'd also suggest that because we control all these keys (no user specified keys), they don't need to be capitalized
eval
SOURCE
WORKER
ENDOWMENTS
import-unsafe
SPECIFIER
WORKER
POWERS
import-bundle
WORKER
BUNDLE
POWERS
guest
HOST
web-bundle
BUNDLE
POWERS
d149e64
to
c369498
Compare
ae27dc1
to
1362fd8
Compare
b4ba0f9
to
aeac064
Compare
- Updates INFO-related internals to refer to "inspector" instead of "info". - Adds types for different "known" inspectors (e.g. for `eval` formulas). - Lower-cases known inspector special names (e.g. `bundle`).
7f4adfb
to
585e17d
Compare
packages/daemon/test/test-endo.js
Outdated
// TODO: This test verifies existing behavior when pet-naming workers. | ||
// This behavior is undesirable. | ||
test('eval-mediated worker name', async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went for a passing test rather than test.failing()
because the test could otherwise start to fail for an unexpected reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue for this: #2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We like embedding links to issues in the code, especially for something like this.
/** | ||
* @param {string} petName - The pet name to inspect. | ||
* @returns {Promise<import('./types').KnownEndoInspectors[string]>} An | ||
* inspector for the value of the given pet name. | ||
*/ | ||
const lookup = async petName => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have types for the individual known inspectors (see types.d.ts
), but due to the indirection between the petName
argument and the formulaType
, it is difficult (impossible?) to map the petName
to the "correct" return type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. We can’t be more specific than a union of all known inspector types. Lookup in general has this limitation. For some Endo APIs, we could overload a formula type argument and provide guarantees of specific types, to make some casts unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -1,10 +1,11 @@ | |||
const { quote: q } = assert; | |||
|
|||
const numberlessFormulasIdentifiers = new Set([ | |||
'pet-store', | |||
'host', | |||
'endo', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could add a comment that these are sorted, to maintain that invariant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll defer this to when I look into our lint configs.
packages/daemon/test/test-endo.js
Outdated
// TODO: This test verifies existing behavior when pet-naming workers. | ||
// This behavior is undesirable. | ||
test('eval-mediated worker name', async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We like embedding links to issues in the code, especially for something like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whee
585e17d
to
4b45a7a
Compare
Problem: Commands like
endo make counter.js --name counter
implicitly create a unique worker for the counter. This makes it impossible to address the worker for follow-up commands, like aneval
co-located with thecounter
.This change introduces an undeniable
INFO
name to all hosts that allows the host to address the values used to create pet named values. For example,INFO -> counter -> worker
addresses the worker that was used to createcounter
. Until we have pet name path lookup (#1915), you need multiple invocations ofE()
to perform of depth greater than 1, for example:This facility is intended to compose well with follow-up changes for inspecting a worker’s log or copy one of these “unnamed” capabilities to a name.