Impossible to implement custom timeouts

[t0yv0]

It appears impossible to implement a a user-defined
customTimeouts option for slow-to-create resources such
as awsx:ecs:FargateService.

Solution attempts

Resource Transformation

Adding a transformation was attempted in #1118 but does not actually work. The option is accepted but ignored by the
system, so gRPC Create calls on the underlying resource are not receiving the desired customTimeout value, and indeed
the provided node hook does not execute at all.

The root cause is pulumi/pulumi#6948 - the platform does not yet support this.

Stack Transformation

A similar approach to #1118 is to install a Stack-level transformation. Initially this looked hopeful as the custom Node
code started to get executed for aws:ecs:Service, however it remains misleading. The code executes but the underlying
gRPC Create call is unaffected and the transformed resource options are silently dropped.

Setting customTimeouts on CustomResource options

Currently is is possible to set customTimeouts on the wrapping Component Resource. Unfortunately this does not generate
any warnings but gets silently dropped. The documentation states that these options are not supported for Component
Resources. There is a comment in the CompoonentResource constructor:

        // Explicitly ignore the props passed in.  We allow them for back compat reasons.  However,
        // we explicitly do not want to pass them along to the engine.  The ComponentResource acts
        // only as a container for other resources.  Another way to think about this is that a normal
        // 'custom resource' corresponds to real piece of cloud infrastructure.  So, when it changes
        // in some way, the cloud resource needs to be updated (and vice versa).  That is not true
        // for a component resource.  The component is just used for organizational purposes and does
        // not correspond to a real piece of cloud infrastructure.  As such, changes to it *itself*
        // do not have any effect on the cloud side of things at all.
        super(type, name, /*custom:*/ false, /*props:*/ remote || opts?.urn ? args : {}, opts, remote);

Thus the provider implementation cannot get a hold of the customTimeouts set in the program.

Adding a typed input for CustomTimeouts

Another option would be adding a new typed input to wrapper resources and translating it to the customTimeouts option on
the underlying resource. A naive option to do this resulted in the input data being available as a Promise<string> to
the Component Resource constructor, which is not compatible with setting the Resource Option that needs to be an
unwrapped string. Perhaps there is an option somewhere to make this argument plain.

References

• Support transformations for multi-language components pulumi#6948
• Timeout while waiting for state to become 'tfSTABLE' (last state: 'tfPENDING', timeout: 20m0s) #1112 is directly caused by this and does not have a good workaround
• TestLbWithSubnets flaky #1246 is caused by this

[t0yv0]

pulumi/pulumi#15843 can be an answer here waiting for the fix.