2018-09-26 06:29:27 +02:00
|
|
|
// Copyright 2016-2018, Pulumi Corporation.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
// tslint:disable
|
|
|
|
|
|
|
|
import * as assert from "assert";
|
2021-01-14 21:36:52 +01:00
|
|
|
import { Output, all, concat, interpolate, output, unknown, secret, unsecret, isSecret } from "../output";
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
import { Resource } from "../resource";
|
2018-09-26 06:29:27 +02:00
|
|
|
import * as runtime from "../runtime";
|
|
|
|
import { asyncTest } from "./util";
|
|
|
|
|
2019-03-06 02:06:57 +01:00
|
|
|
interface Widget {
|
|
|
|
type: string; // metric | text
|
|
|
|
x?: number;
|
|
|
|
y?: number;
|
|
|
|
properties: Object;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This ensures that the optionality of 'x' and 'y' are preserved when describing an Output<Widget>.
|
|
|
|
// Subtle changes in the definitions of Lifted<T> can make TS think these are required, which can
|
|
|
|
// break downstream consumers.
|
|
|
|
function mustCompile(): Output<Widget> {
|
|
|
|
return output({
|
|
|
|
type: "foo",
|
|
|
|
properties: {
|
|
|
|
whatever: 1,
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
// mockOutput returns a value that looks like an Output, but allows for greater control over its behavior. This can be
|
|
|
|
// used to simulate outputs from downlevel SDKs.
|
|
|
|
function mockOutput(isKnown: boolean | Promise<boolean>, value: any | Promise<any>): any {
|
|
|
|
isKnown = isKnown instanceof Promise ? isKnown : Promise.resolve(isKnown);
|
|
|
|
value = value instanceof Promise ? value : Promise.resolve(value);
|
|
|
|
|
|
|
|
return {
|
|
|
|
__pulumiOutput: true,
|
|
|
|
isKnown: isKnown,
|
|
|
|
isSecret: Promise.resolve(false),
|
|
|
|
promise: () => value,
|
|
|
|
resources: () => new Set<Resource>(),
|
|
|
|
|
|
|
|
apply(callback: any): any {
|
|
|
|
return mockOutput(isKnown, value.then(async (v: any) => {
|
|
|
|
if (!isKnown) {
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
return callback(v);
|
|
|
|
}));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-26 06:29:27 +02:00
|
|
|
describe("output", () => {
|
|
|
|
it("propagates true isKnown bit from inner Output", asyncTest(async () => {
|
2019-04-17 07:20:01 +02:00
|
|
|
runtime._setIsDryRun(true);
|
2018-09-26 06:29:27 +02:00
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const output1 = new Output(new Set(), Promise.resolve("outer"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const output2 = output1.apply(v => new Output(new Set(), Promise.resolve("inner"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set())));
|
2018-09-26 06:29:27 +02:00
|
|
|
|
|
|
|
const isKnown = await output2.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2018-09-26 06:29:27 +02:00
|
|
|
|
|
|
|
const value = await output2.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "inner");
|
2018-09-26 06:29:27 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates false isKnown bit from inner Output", asyncTest(async () => {
|
2019-04-17 07:20:01 +02:00
|
|
|
runtime._setIsDryRun(true);
|
2018-09-26 06:29:27 +02:00
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const output1 = new Output(new Set(), Promise.resolve("outer"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const output2 = output1.apply(v => new Output(new Set(), Promise.resolve("inner"), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set())));
|
2018-09-26 06:29:27 +02:00
|
|
|
|
|
|
|
const isKnown = await output2.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, false);
|
2018-09-26 06:29:27 +02:00
|
|
|
|
|
|
|
const value = await output2.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "inner");
|
2018-09-26 06:29:27 +02:00
|
|
|
}));
|
|
|
|
|
2019-10-28 19:39:52 +01:00
|
|
|
it("can not await if isKnown is a rejected promise.", asyncTest(async () => {
|
2019-04-17 07:20:01 +02:00
|
|
|
runtime._setIsDryRun(true);
|
2018-09-26 06:29:27 +02:00
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const output1 = new Output(new Set(), Promise.resolve("outer"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const output2 = output1.apply(v => new Output(new Set(), Promise.resolve("inner"), Promise.reject(new Error("foo")), Promise.resolve(false), Promise.resolve(new Set())));
|
2018-09-26 06:29:27 +02:00
|
|
|
|
2019-10-28 19:39:52 +01:00
|
|
|
try {
|
|
|
|
const isKnown = await output2.isKnown;
|
|
|
|
assert.fail("Should not reach here");
|
|
|
|
}
|
|
|
|
catch (err) {
|
|
|
|
}
|
2018-09-26 06:29:27 +02:00
|
|
|
|
|
|
|
try {
|
|
|
|
const value = await output2.promise();
|
2019-10-28 19:39:52 +01:00
|
|
|
assert.fail("Should not reach here");
|
2018-09-26 06:29:27 +02:00
|
|
|
}
|
|
|
|
catch (err) {
|
|
|
|
}
|
|
|
|
}));
|
2019-01-16 20:03:25 +01:00
|
|
|
|
2019-04-13 01:59:18 +02:00
|
|
|
it("propagates true isSecret bit from inner Output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const output1 = new Output(new Set(), Promise.resolve("outer"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const output2 = output1.apply(v => new Output(new Set(), Promise.resolve("inner"), Promise.resolve(true), Promise.resolve(true), Promise.resolve(new Set())));
|
2019-04-13 01:59:18 +02:00
|
|
|
|
|
|
|
const isSecret = await output2.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isSecret, true);
|
2019-04-13 01:59:18 +02:00
|
|
|
|
|
|
|
const value = await output2.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "inner");
|
2019-04-13 01:59:18 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("retains true isSecret bit from outer Output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const output1 = new Output(new Set(), Promise.resolve("outer"), Promise.resolve(true), Promise.resolve(true), Promise.resolve(new Set()));
|
|
|
|
const output2 = output1.apply(v => new Output(new Set(), Promise.resolve("inner"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set())));
|
2019-04-13 01:59:18 +02:00
|
|
|
|
|
|
|
const isSecret = await output2.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isSecret, true);
|
2019-04-13 01:59:18 +02:00
|
|
|
|
|
|
|
const value = await output2.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "inner");
|
2019-04-13 01:59:18 +02:00
|
|
|
}));
|
|
|
|
|
2020-04-02 22:01:29 +02:00
|
|
|
describe("apply", () => {
|
|
|
|
function createOutput<T>(val: T, isKnown: boolean, isSecret: boolean = false): Output<T> {
|
|
|
|
return new Output(new Set(), Promise.resolve(val), Promise.resolve(isKnown), Promise.resolve(isSecret),
|
|
|
|
Promise.resolve(new Set()));
|
|
|
|
}
|
|
|
|
|
|
|
|
it("can run on known value during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), 1);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on known awaitable value during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on known known output value during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on known unknown output value during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces unknown default on unknown during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces unknown default on unknown awaitable during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces unknown default on unknown known output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces unknown default on unknown unknown output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), 1);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known awaitable during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known known output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known unknown output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown awaitable during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown known output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown unknown output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates secret on known known output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates secret on known unknown output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("does not propagate secret on unknown known output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", true, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, false);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("does not propagate secret on unknown unknown output during preview", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", false, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, false);
|
|
|
|
assert.strictEqual(await r.promise(), undefined);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on known value", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), 1);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on known awaitable value", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on known known output value", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("can run on unknown known output value", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces known on unknown", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), 1);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces known on unknown awaitable", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces known on unknown known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("produces unknown on unknown unknown output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), 1);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known awaitable", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on known known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => v + 1);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), 1);
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown awaitable", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => Promise.resolve("inner"));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("preserves secret on unknown known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates secret on known known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", true, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates secret on known unknown output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, true);
|
|
|
|
const r = out.apply(v => createOutput("inner", false, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates secret on unknown known output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", true, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, true);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("propagates secret on unknown uknown output", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(false);
|
|
|
|
|
|
|
|
const out = createOutput(0, false);
|
|
|
|
const r = out.apply(v => createOutput("inner", false, true));
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r.isKnown, false);
|
|
|
|
assert.strictEqual(await r.isSecret, true);
|
|
|
|
assert.strictEqual(await r.promise(), "inner");
|
2020-04-02 22:01:29 +02:00
|
|
|
}));
|
|
|
|
});
|
|
|
|
|
2019-08-06 06:53:39 +02:00
|
|
|
describe("isKnown", () => {
|
2019-12-17 23:11:45 +01:00
|
|
|
function or<T>(output1: Output<T>, output2: Output<T>): Output<T> {
|
2019-08-06 06:53:39 +02:00
|
|
|
const val1 = output1.promise();
|
|
|
|
const val2 = output2.promise();
|
|
|
|
return new Output<T>(
|
2019-12-18 04:04:09 +01:00
|
|
|
new Set([...output1.resources(), ...output2.resources()]),
|
2019-08-06 06:53:39 +02:00
|
|
|
Promise.all([val1, val2])
|
|
|
|
.then(([val1, val2]) => val1 || val2),
|
|
|
|
Promise.all([val1, output1.isKnown, output2.isKnown])
|
|
|
|
.then(([val1, isKnown1, isKnown2]) => val1 ? isKnown1 : isKnown2),
|
|
|
|
Promise.all([val1, output1.isSecret, output2.isSecret])
|
2019-12-18 04:04:09 +01:00
|
|
|
.then(([val1, isSecret1, isSecret2]) => val1 ? isSecret1 : isSecret2),
|
|
|
|
Promise.all([output1.allResources!(), output2.allResources!()])
|
|
|
|
.then(([r1, r2]) => new Set([...r1, ...r2])));
|
2019-08-06 06:53:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
it("choose between known and known output, non-secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve("foo"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve("bar"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "foo");
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between known and known output, secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve("foo"), Promise.resolve(true), Promise.resolve(true), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve("bar"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "foo");
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between known and unknown output, non-secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve("foo"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "foo");
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between known and unknown output, secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve("foo"), Promise.resolve(true), Promise.resolve(true), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "foo");
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between unknown and known output, non-secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve("bar"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "bar");
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between unknown and known output, secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve("bar"), Promise.resolve(true), Promise.resolve(true), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, "bar");
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between unknown and unknown output, non-secret", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, undefined);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between unknown and unknown output, secret1", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(true), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, undefined);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between unknown and unknown output, secret2", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(true), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, undefined);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("choose between unknown and unknown output, secret3", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(true), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(undefined), Promise.resolve(false), Promise.resolve(true), Promise.resolve(new Set()));
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const result = or(o1, o2);
|
|
|
|
|
|
|
|
const isKnown = await result.isKnown;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(isKnown, false);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const value = await result.promise();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(value, undefined);
|
2019-08-06 06:53:39 +02:00
|
|
|
|
|
|
|
const secret = await result.isSecret;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(secret, true);
|
2019-08-06 06:53:39 +02:00
|
|
|
}));
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
it("is unknown if the value is or contains unknowns", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve(unknown), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o2 = new Output(new Set(), Promise.resolve(["foo", unknown]), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
|
|
|
const o3 = new Output(new Set(), Promise.resolve({"foo": "foo", unknown}), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await o1.isKnown, false);
|
|
|
|
assert.strictEqual(await o2.isKnown, false);
|
|
|
|
assert.strictEqual(await o3.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("is unknown if the result after apply is unknown or contains unknowns", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
2019-12-18 04:04:09 +01:00
|
|
|
const o1 = new Output(new Set(), Promise.resolve("foo"), Promise.resolve(true), Promise.resolve(false), Promise.resolve(new Set()));
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
const r1 = o1.apply(v => unknown);
|
|
|
|
const r2 = o1.apply(v => [v, unknown]);
|
|
|
|
const r3 = o1.apply(v => <any>{v, unknown});
|
|
|
|
const r4 = (<any>o1.apply(v => unknown)).apply((v: any) => v, true);
|
|
|
|
const r5 = (<any>o1.apply(v => [v, unknown])).apply((v: any) => v, true);
|
|
|
|
const r6 = (<any>o1.apply(v => <any>{v, unknown})).apply((v: any) => v, true);
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await r1.isKnown, false);
|
|
|
|
assert.strictEqual(await r2.isKnown, false);
|
|
|
|
assert.strictEqual(await r3.isKnown, false);
|
|
|
|
assert.strictEqual(await r4.isKnown, false);
|
|
|
|
assert.strictEqual(await r5.isKnown, false);
|
|
|
|
assert.strictEqual(await r6.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
}));
|
2019-08-06 06:53:39 +02:00
|
|
|
});
|
|
|
|
|
2019-01-16 20:03:25 +01:00
|
|
|
describe("concat", () => {
|
|
|
|
it ("handles no args", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = concat();
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles empty string arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = concat("");
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles non-empty string arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = concat("a");
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles promise string arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = concat(Promise.resolve("a"));
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles output string arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = concat(output("a"));
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles multiple args", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = concat("http://", output("a"), ":", 80);
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "http://a:80");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("interpolate", () => {
|
|
|
|
it ("handles empty interpolation", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = interpolate ``;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles no placeholders arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = interpolate `a`;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles string placeholders arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = interpolate `${"a"}`;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles promise placeholders arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = interpolate `${Promise.resolve("a")}`;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles output placeholders arg", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = interpolate `${output("a")}`;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "a");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it ("handles multiple args", asyncTest(async () => {
|
2019-02-01 03:08:17 +01:00
|
|
|
const result = interpolate `http://${output("a")}:${80}/`;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result.promise(), "http://a:80/");
|
2019-01-16 20:03:25 +01:00
|
|
|
}));
|
|
|
|
});
|
2019-03-06 02:06:57 +01:00
|
|
|
|
2021-01-14 21:36:52 +01:00
|
|
|
describe("secret operations", () => {
|
|
|
|
it("ensure secret", asyncTest(async () => {
|
|
|
|
const sec = secret("foo");
|
|
|
|
assert.strictEqual(await sec.isSecret, true)
|
|
|
|
}));
|
|
|
|
it("ensure that a secret can be unwrapped", asyncTest(async () => {
|
|
|
|
const sec = secret("foo");
|
|
|
|
assert.strictEqual(await isSecret(sec), true)
|
|
|
|
|
|
|
|
const unsec = unsecret(sec);
|
|
|
|
assert.strictEqual(await isSecret(unsec), false)
|
|
|
|
assert.strictEqual(await unsec.promise(), "foo")
|
|
|
|
}));
|
|
|
|
});
|
|
|
|
|
2019-03-06 02:06:57 +01:00
|
|
|
describe("lifted operations", () => {
|
|
|
|
it("lifts properties from inner object", asyncTest(async () => {
|
|
|
|
const output1 = output({ a: 1, b: true, c: "str", d: [2], e: { f: 3 }, g: undefined, h: null });
|
|
|
|
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await output1.a.promise(), 1);
|
|
|
|
assert.strictEqual(await output1.b.promise(), true);
|
|
|
|
assert.strictEqual(await output1.c.promise(), "str");
|
2019-03-06 02:06:57 +01:00
|
|
|
|
|
|
|
// Can lift both outer arrays as well as array accesses
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.deepStrictEqual(await output1.d.promise(), [2]);
|
|
|
|
assert.strictEqual(await output1.d[0].promise(), 2);
|
2019-03-06 02:06:57 +01:00
|
|
|
|
|
|
|
// Can lift nested objects as well as their properties.
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.deepStrictEqual(await output1.e.promise(), { f: 3 });
|
|
|
|
assert.strictEqual(await output1.e.f.promise(), 3);
|
2019-03-06 02:06:57 +01:00
|
|
|
|
|
|
|
assert.strictEqual(await output1.g.promise(), undefined);
|
|
|
|
assert.strictEqual(await output1.h.promise(), null);
|
|
|
|
|
|
|
|
// Unspecified things can be lifted, but produce 'undefined'.
|
|
|
|
assert.notEqual((<any>output1).z, undefined);
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await (<any>output1).z.promise(), undefined);
|
2019-03-06 02:06:57 +01:00
|
|
|
}));
|
|
|
|
|
|
|
|
it("prefers Output members over lifted members", asyncTest(async () => {
|
|
|
|
const output1 = output({ apply: 1, promise: 2 });
|
|
|
|
assert.ok(output1.apply instanceof Function);
|
|
|
|
assert.ok(output1.isKnown instanceof Promise);
|
|
|
|
}));
|
|
|
|
|
|
|
|
it("does not lift symbols", asyncTest(async () => {
|
|
|
|
const output1 = output({ apply: 1, promise: 2 });
|
|
|
|
assert.strictEqual((<any>output1)[Symbol.toPrimitive], undefined);
|
|
|
|
}));
|
|
|
|
|
|
|
|
it("does not lift __ properties", asyncTest(async () => {
|
|
|
|
const output1 = output({ a: 1, b: 2 });
|
|
|
|
assert.strictEqual((<any>output1).__pulumiResource, undefined);
|
|
|
|
}));
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
it("lifts properties from values with nested unknowns", asyncTest(async () => {
|
|
|
|
runtime._setIsDryRun(true);
|
|
|
|
|
|
|
|
const output1 = output({
|
|
|
|
foo: "foo",
|
|
|
|
bar: unknown,
|
|
|
|
baz: Promise.resolve(unknown),
|
|
|
|
qux: mockOutput(false, undefined),
|
|
|
|
});
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await output1.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result1 = output1.foo;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result1.isKnown, true);
|
|
|
|
assert.strictEqual(await (<any>result1).promise(/*withUnknowns*/ true), "foo");
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result2 = output1.bar;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result2.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result2).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result3 = output1.baz;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result3.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result3).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result4 = output1.qux;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result4.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result4).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result5 = (<any>output1.baz).qux;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result5.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result5).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const output2 = output([ "foo", unknown, mockOutput(false, undefined) ]);
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await output2.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result6 = output2[0];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result6.isKnown, true);
|
|
|
|
assert.strictEqual(await (<any>result6).promise(/*withUnknowns*/ true), "foo");
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result7 = output2[1];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result7.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result7).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result8 = output2[2];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result8.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result8).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const output3 = all([ unknown, mockOutput(false, undefined), output([ "foo", unknown ])]);
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await output3.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result9 = output3[0];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result9.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result9).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result10 = output3[1];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result10.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result10).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result11 = output3[2];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result11.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result12 = (<any>result11)[0];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result12.isKnown, true);
|
|
|
|
assert.strictEqual(await (<any>result12).promise(/*withUnknowns*/ true), "foo");
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result13 = (<any>result11)[1];
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result13.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result13).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const output4 = all({
|
|
|
|
foo: unknown,
|
|
|
|
bar: mockOutput(false, undefined),
|
|
|
|
baz: output({ foo: "foo", qux: unknown }),
|
|
|
|
});
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await output4.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result14 = output4.foo;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result14.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result14).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result15 = output4.bar;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result15.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result15).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result16 = output4.baz;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result16.isKnown, false);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result17 = (<any>result16).foo;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result17.isKnown, true);
|
|
|
|
assert.strictEqual(await (<any>result17).promise(/*withUnknowns*/ true), "foo");
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
|
|
|
|
const result18 = (<any>result16).qux;
|
2020-10-21 19:21:47 +02:00
|
|
|
assert.strictEqual(await result18.isKnown, false);
|
|
|
|
assert.strictEqual(await (<any>result18).promise(/*withUnknowns*/ true), unknown);
|
Propagate inputs to outputs during preview. (#3327)
These changes restore a more-correct version of the behavior that was
disabled with #3014. The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.
By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.
Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.
These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
callback should be run even if the result of the apply contains
unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values
The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.
In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.
These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.
Fixes #3190.
2019-11-11 21:09:34 +01:00
|
|
|
}));
|
2019-03-06 02:06:57 +01:00
|
|
|
});
|
2018-09-26 06:29:27 +02:00
|
|
|
});
|