ID attributes need to respect providers that expect numerical IDs

[infin8x]

Based on:

• Several issues with incorrect types in pulumi-linode pulumi-linode#140
• Attaching volumes to droplets fail because of droplet id type mismatch in Python pulumi-digitalocean#218
• golang: ID of a droplet is of type StringOutput incompatible with other Ressources pulumi-digitalocean#244
• C# FirewallArgs.DropletIds Property InputList<int> Droplet.Id Output<string> pulumi-digitalocean#248
• digitalocean provider: type mismatches for 'dropletId' pulumi#4173

[sudhanshuraheja]

I'm getting the same issue with JavaScript as well.

If I try this dropletId: parseInt(dropletThree.id),, on running pulumi up, it shows this change ~ dropletId: 1.92662022e+08 => -9.223372036854776e+18

Is there a workaround available for Javascript?

UPDATE: dropletOne.id.apply(parseInt) works.

[leezen]

I'll add an update here that in general, the solution for now is to use apply (in whatever language you're using) to parse the string into the numeric value.

[solarsoft0]

// convert dropletId from pulumi.ID to pulumi.IntInput
	dropletId := droplet.ID().ToStringOutput().ApplyT(func(id string) int {
		var idInt int
		idInt, err := strconv.Atoi(id)
		if err != nil {
			fmt.Println(err)
			return idInt
		}
		return idInt
	}).(pulumi.IntInput)

[ssboisen]

Is this issue being worked on?

While it can be solved when passing dropletId's on to other resources (like firewall) by using apply it causes problems when modifying a droplet causing a replace. One example would be to modify userData due to cloudinit changes but simply modifying any of the inputs for a droplet causes a panic.

A temporary solution is to destroy the droplet using --target prior to running pulumi up but that's not ideal

[iglu-sebastian]

I'm getting the same issue with JavaScript as well.

If I try this dropletId: parseInt(dropletThree.id),, on running pulumi up, it shows this change ~ dropletId: 1.92662022e+08 => -9.223372036854776e+18

Is there a workaround available for Javascript?

UPDATE: dropletOne.id.apply(parseInt) works.

Unfortunately this does not work. Still hitting issues with JS @pulumi/digitalocean. Any idea how to fix it/workaround?

UPDATE: Seems like pulumi/pulumi#4173 (comment) has a workaround via id.apply(x => Number(x).valueOf())

    panic: interface conversion: interface {} is string, not int
    goroutine 63 [running]:
    github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.SerializeValueForHash(0x14000582680?, {0x101cbf080?, 0x101eee540?}, 0x101033198?)
    	/home/runner/go/pkg/mod/github.com/pulumi/terraform-plugin-sdk/v2@v2.0.0-20220725190814-23001ad6ec03/helper/schema/serialize.go:24 +0x250
    github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.HashSchema.func1({0x101cbf080?, 0x101eee540?})
    	/home/runner/go/pkg/mod/github.com/pulumi/terraform-plugin-sdk/v2@v2.0.0-20220725190814-23001ad6ec03/helper/schema/set.go:44 +0x40
    github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfshim/sdk-v2.v2Schema.SetHash({0x14000d80380?}, {0x101cbf080, 0x101eee540})
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi-terraform-bridge/v3@v3.29.0/pkg/tfshim/sdk-v2/schema.go:180 +0x48
    github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfbridge.visitPropertyValue({0x14000ce15d4, 0xb}, {0x14000701430, 0xa}, {{0x101c9ffc0?, 0x1400096bdb8?}}, {0x101f093a0?, 0x140008357c0}, 0x0, 0x0, ...)
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi-terraform-bridge/v3@v3.29.0/pkg/tfbridge/diff.go:114 +0x5b0
    github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfbridge.doIgnoreChanges({0x101f02110, 0x140004df440}, 0x15?, 0x101efe200?, 0x140005274a0?, {0x0, 0x0, 0x14000ca0ac7?}, {0x101f03ec0, 0x1400019a700})
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi-terraform-bridge/v3@v3.29.0/pkg/tfbridge/diff.go:260 +0x250
    github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfbridge.(*Provider).Diff(0x140004f2480, {0x101efd4a8?, 0x1400073d7d0?}, 0x14000919650)
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi-terraform-bridge/v3@v3.29.0/pkg/tfbridge/provider.go:762 +0x474
    github.com/pulumi/pulumi/sdk/v3/proto/go._ResourceProvider_Diff_Handler.func1({0x101efd4a8, 0x1400073d7d0}, {0x101e50580?, 0x14000919650})
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi/sdk/v3@v3.38.0/proto/go/provider.pb.go:3707 +0x74
    github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc.OpenTracingServerInterceptor.func1({0x101efd4a8, 0x1400073cc90}, {0x101e50580, 0x14000919650}, 0x1400003a0e0, 0x140005962b8)
    	/home/runner/go/pkg/mod/github.com/grpc-ecosystem/grpc-opentracing@v0.0.0-20180507213350-8e809c8a8645/go/otgrpc/server.go:57 +0x30c
    github.com/pulumi/pulumi/sdk/v3/proto/go._ResourceProvider_Diff_Handler({0x101eb5e00?, 0x140004f2480}, {0x101efd4a8, 0x1400073cc90}, 0x140009195e0, 0x140004885e0)
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi/sdk/v3@v3.38.0/proto/go/provider.pb.go:3709 +0x138
    google.golang.org/grpc.(*Server).processUnaryRPC(0x140003821e0, {0x101f04340, 0x14000682340}, 0x14000dd3440, 0x140008873e0, 0x1028a0d68, 0x0)
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.48.0/server.go:1295 +0x9c4
    google.golang.org/grpc.(*Server).handleStream(0x140003821e0, {0x101f04340, 0x14000682340}, 0x14000dd3440, 0x0)
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.48.0/server.go:1636 +0x82c
    google.golang.org/grpc.(*Server).serveStreams.func1.2()
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.48.0/server.go:932 +0x84
    created by google.golang.org/grpc.(*Server).serveStreams.func1
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.48.0/server.go:930 +0x290

[mkatrenik]

@iglu-sebastian nah, it doesn't

[t0yv0]

Per conversation with @iwahbe today, it is now possible to customize the bridge mapping to get acceptable behavior out of the providers, which is being rolled out to Pulumi-managed providers. @iwahbe can we link a few examples, a playbook how to do this for community providers, and close?