Impossible to implement custom timeouts

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

pulumi/pulumi#6948
1112 is directly caused by this and does not have a good workaround
1246 is caused by this

pulumi / pulumi-awsx