Fix 7862

[t0yv0]

Description

Fixes #7862

• Still need to add a test, but with this change the user's problem does not repro.

Checklist

• I have added tests that prove my fix is effective or that my feature works

• I have updated the CHANGELOG-PENDING file with my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Service API version

[t0yv0]

So this algorithm needs to store the state somewhere. Options to put the state in:

• some property of Resource objects (currently _DEPENDENCIES_PROPERTY is exactly that)
• global table (I'm ever-so-slightly worried about leaks and re-entrancy in some auto API cases)
• table scoped to the Pulumi program run that is executing - this would perhaps be ideal, but where do we put such state, which object/class?

[EvanBoyle]

@pgavlin has talked about adding a kv store in the engine as a first class feature in the pulumi RPC interface to service scenarios just like this. But I don't personally have anything against the approach you've taken to solve the customer issue right now.

[t0yv0]

Yeah! Hm. This would indeed come handy one day. However as things stand with Py SDK I'd be a bit worried about relying on async KV store for core functionality.. For example I'd love to first get rid of threading and have a really foolproof async situation. in current design core functionality of Py SDK is to order the RegisterResource calls "right" before they hit the engine.

So far I can think of no downside piggybacking on the Resource prop - we're not ever pickling these objects right.. But if needed/wanted I can also explicitly declare this prop on the Resource class so it's more official this is being used.