Large integer config value unexpectedly translated to scientific notation

[t0yv0]

What happened?

Large integer config value unexpectedly translated to scientific notation - tried to use randomization for an AWS security group name threaded through the Config system but the resulting unexpected transformation rendered the generated name invalid and ended up in a confusing error message. Generally this behavior looks unexpected.

Example

name: project
runtime: yaml
config:
  randSuffix:
    type: string
outputs:
  name: securitygroup${randSuffix}

Using something like this:

pulumi config set randSuffix 1048576

Results in:

Outputs:
    name: "securitygroup1.048576e+06"

Output of pulumi about

CLI          
Version      3.111.1
Go Version   go1.22.1
Go Compiler  gc

Plugins
NAME  VERSION
yaml  unknown

Host     
OS       darwin
Version  14.4
Arch     x86_64

This project is written in yaml

Current Stack: anton-pulumi-corp/project/dwev

TYPE                 URN
pulumi:pulumi:Stack  urn:pulumi:dwev::project::pulumi:pulumi:Stack::project-dwev


Found no pending operations associated with dwev

Backend        
Name           pulumi.com
URL            https://app.pulumi.com/anton-pulumi-corp
User           anton-pulumi-corp
Organizations  anton-pulumi-corp, moolumi, pulumi
Token type     personal

No dependencies found

Pulumi locates its logs in /var/folders/gk/cchgxh512m72f_dmkcc3d09h0000gp/T/com.apple.shortcuts.mac-helper// by default

Additional context

N/A

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[t0yv0]

I have a workaround where I stick a letter into randSuffix so not a blocker.

[tgummerer]

Yeah this config stuff in yaml is unfortunately quite awkward. We're passing the config values through from pulumi/pulumi, where be base the type on the value instead of the type that's specified in the yaml template. And we're passing it over the wire as property values, which I believe are always floats, so that's how you end up with the scientific notation.

Eventually we should take another look at the whole config system for pulumi-yaml, since right now it's clearly quite awkward.

[t0yv0]

Well float64 representation does not have to be lossy here, JavaScript engines represent numbers as f64 and yet:

console.log(String(1024*1024))
1048576

Perhaps debugging this particular program could help find the place where the conversion is garbling the data.

[pierskarsenbarg]

We've just had someone message into support where they're having this issue and as such are blocked on creating resources where they need to pass in an ID.

So using the following as Pulumi.yaml:

name: yaml-config
runtime: yaml

config:
  infraAlertsSlackChannelId:
    type: string
  projectId:
    type: string

resources:
  alert-policy:
    type: gcp:monitoring:AlertPolicy
    properties:
      combiner: OR
      conditions:
        - conditionThreshold:
            comparison: COMPARISON_GT
            duration: 60s
            filter: resource.type="pubsub_subscription" AND resource.labels.subscription_id="my-subscription" AND metric.type="pubsub.googleapis.com/subscription/num_undelivered_messages"
          displayName: Dead Letters Exceeded Threshold
      displayName: My Dead Letter Count Alert
      notificationChannels:
        - "projects/${projectId}/notificationChannels/${slackChannelId}"
      project: ${projectId}

And then the Pulumi.dev.yaml:

config:
  gcp:project: pulumi-ce-team
  yaml-config:infraAlertsSlackChannelId: "12345678909876543212"
  yaml-config:projectId: pulumi-ce-team

fails because of the converting to a number