pulumi golang assertion failed when calling network.Subnet.get('my-subnet', vnet.guid)

[asnowfix]

pulumi preview works as expected.

pulumi up --yescrashed the pulumi CLI w/ a failing GoLang assertion

Backtrace with pulumi-v2.5.0:

Updating (hdns-netadm):
     Type                                        Name              Status      Info
     pulumi:pulumi:Stack                         hdns-hdns-netadm  running     read azure:network:Subnet snet-netadm-dns-01
     └─ azure:privatedns:ZoneVirtualNetworkLink  hdns-netadm                   error: azure:privatedns/zoneVirtualNetworkLink:ZoneVirtualNetworkLink resource 'hdns-netadm' has a problem: Missing
panic: fatal: An assertion has failed

goroutine 4190 [running]:
github.com/pulumi/pulumi/sdk/v2/go/common/util/contract.failfast(...)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/sdk/go/common/util/contract/failfast.go:23
github.com/pulumi/pulumi/sdk/v2/go/common/util/contract.Assert(...)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/sdk/go/common/util/contract/assert.go:26
github.com/pulumi/pulumi/sdk/v2/go/common/resource/plugin.(*provider).Read(0xc000c4f320, 0xc0018b0050, 0x4d, 0x0, 0x0, 0x0, 0xc0015a8210, 0x482eacd, 0x4, 0x0, ...)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/sdk/go/common/resource/plugin/provider_plugin.go:724 +0x1011
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*ReadStep).Apply(0xc0015a8270, 0x0, 0x53953e0, 0x23, 0xc0006a1e38, 0x3)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/pkg/resource/deploy/step.go:623 +0xfd
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).executeStep(0xc00073cf00, 0x7, 0x5737ca0, 0xc0015a8270, 0x19, 0xc0011de298)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:271 +0x217
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).executeChain(0xc00073cf00, 0x7, 0xc0011e61e0, 0x1, 0x1)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:221 +0xe6
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).worker.func1(0xc00073cf00, 0x7, 0xc0011e61e0, 0x1, 0x1, 0xc00129e3c0)
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:371 +0xc4
created by github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).worker
        /private/tmp/pulumi-20200625-99450-vnrpxb/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:368 +0x2e3```

backtrace with pulumi-v2.2.1

     Type                 Name              Status      Info
     pulumi:pulumi:Stack  hdns-hdns-netadm  running...  read azure:network:Subnet snet-netadm-dns-01
panic: fatal: An assertion has failed

goroutine 4199 [running]:
github.com/pulumi/pulumi/sdk/v2/go/common/util/contract.failfast(...)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/sdk/go/common/util/contract/failfast.go:23
github.com/pulumi/pulumi/sdk/v2/go/common/util/contract.Assert(...)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/sdk/go/common/util/contract/assert.go:26
github.com/pulumi/pulumi/sdk/v2/go/common/resource/plugin.(*provider).Read(0xc000cef560, 0xc001f88050, 0x4d, 0x0, 0x0, 0x0, 0xc0018fc390, 0x484d7fd, 0x4, 0x0, ...)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/sdk/go/common/resource/plugin/provider_plugin.go:716 +0x1011
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*ReadStep).Apply(0xc0018fc3f0, 0x0, 0x54240ef, 0x23, 0xc001da5e18, 0x3)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/pkg/resource/deploy/step.go:623 +0xfd
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).executeStep(0xc001b29d00, 0x7, 0x57c6c00, 0xc0018fc3f0, 0x19, 0xc0011dd6a8)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:271 +0x217
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).executeChain(0xc001b29d00, 0x7, 0xc0019abca0, 0x1, 0x1)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:221 +0xe6
github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).worker.func1(0xc001b29d00, 0x7, 0xc0019abca0, 0x1, 0x1, 0xc0018822a0)
        /Users/travis/gopath/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:371 +0xea
created by github.com/pulumi/pulumi/pkg/v2/resource/deploy.(*stepExecutor).worker
        /Users/travis/gopath/src/github.com/pulumi/pulumi/pkg/resource/deploy/step_executor.go:368 +0x2fa

[leezen]

Would you be willing and able to share the code you're executing or snippets around where the failure is happening? The failing assertion is a missing ID for the read -- is that guid flowing from an output somewhere else in the program?

[asnowfix]

Let me give a bit more detail: the crash results from an API mis-use (which makes it much less critical), but still it causes a CLI crash, leaving the state file in a bad state... etc.

Here is the scenario:

1. call to network.VirtualNetwork.get(vnet_name, vnet_rg_name) to retrieve a Vnet object. I now know this is not the proper way,
2. this call succeed, returning an object whose .id is a pulumi.Output. calling this id.apply(fn) causes fn to be called with a resource-group ID .. not a Vnet ID
3. when using a pulumi.Output.all(id).apply(fn), is never called
4. Calling network.Subnet.get(subnet_name, vnet.id) always fails (for good reasons: this is not meant)
5. Calling network.Subnet.get(subnet_name, vnet.guid) passes pulumi preview... but crashes pulumi up. The CLI GoLang backtrace is in the issue description above.

Comments:

• Step (1) should simply fail instead or returning something. Even more an object that seems to have a weird behaviour
• Step (5) should not pass "preview"... and of course not crash the CLI. I remind that the way to exist (5) crash is to export the state, fix the JSON (drop the ongoing ops) & re-import.

[leezen]

Thanks for those additional details! That will help with further investigation.

[lukehoban]

There's not a repro here to confirm for sure, but I'm fairly certain this was fixed by #9243. At the very least, that will result in a better error message that would improve debugging of this problem if hit in the future. For now though, I will close as fixed by #9243 and we can open a new issue with more repro details if this is seen again.