Ask questionsUnable to easily get an integer value from a stack reference

I have two Go-based stacks, one of which has as an output connectivity information to an RDS instance (e.g. host, port, etc), and the other which uses these via a StackReference.

Specifically, in the first stack, I might have something like:

ctx.Export("db-port", pulumi.Int(5432))

and in the other stack, I might try and do something like:

infraStack, _ := pulumi.NewStackReference(ctx, "my-db-stack", nil)

... get the value of `db-port` ...

At this point, I ran into a couple of issues:

  1. There is no GetIntOutput
  2. I tried to do dbPort := infraStack.GetOutput("db-port").(pulumi.IntOutput), which leads to the following error: invalid type assertion:infraStack.GetOutput("db-port").(pulumi.IntOutput) (non-interface type pulumi.AnyOutput on left)
  3. So I thought I'd try and do this with ApplyT, and wrote this code:
infraStack.GetOutput(pulumi.String("db-port")).ApplyT(func(port int) int {
		return port

which gave me this error:

panic: applier must have 1 input parameter assignable from interface {}

Tried to be smarter:

	dbPort := tenant.infraStack.GetOutput(pulumi.String("db-port")).ApplyT(func(port interface{}) int {
		return port.(int)

but still no luck:

panic: interface conversion: interface {} is float64, not int

At this point my assumption was that the integer value got converted to a JSON number, which Go will represent as a float64. I ended up with the following function to make this easier:

func getIntOutput(ref *pulumi.StackReference, key string) pulumi.IntOutput {
	output := ref.GetOutput(pulumi.String(key))
	return output.ApplyT(func(port interface{}) int {
		return int(port.(float64))

which seems to work well enough. But generally it would be good if this were both easier as well as more type-preserving, especially for more complex types (e.g. a map or array) that could be encoded in the output.

Expected behavior

See above.

Current behavior

See above.

Steps to reproduce

See above.

Context (Environment)

See above

Affected feature

Go stack references


Answer questions itay

@lukehoban thanks, that sounds about right. I don't have a particular preference between those two - they would have mostly been equally discoverable. It is a bit odd that you'd have GetStringOutput() and GetOutput().ToXYZ(), but that's OK.

Github User Rank List