finally nearing the end of this saga/debugging nig...
# automation-api
b
finally nearing the end of this saga/debugging nightmare.. thankfully automation IS debuggable šŸ˜„ It seems it reacted to a simple condition that
pulumi-cli
did not! WHY there's a difference between the two in this case, I have NO idea, the config is the same regardless. Deep in the code where I create storageAccounts, I had this:
Copy code
} else if (!saConfiguration.common.hasOwnProperty("subnetReference")) {
Naturally, this is no good when
.common
does not exist on
saConfiguration
, as was the case with this stack. Pulumi-cli doesn't care apparently. However, changing it to this made everything work just fine:
Copy code
} else if (!saConfiguration.common?.hasOwnProperty("subnetReference")) {
(adding a
?
to the .common). How the hell this relates to error code 4294967295 is still a mystery though. Anyway.. now I get to go thorugh a few thousand lines of code and try to see if I have any more of these potentially invalid references.. sigh..
l
the pulumi cli executes your code via ts-node by default. Is that also how you're configuring your automation api program? This could explain the discrepancy. Would be worth logging out the values of saConfiguration in both cases just to be sure.
b
I'm guessing that's the reason - I switched from ts-node to tsc build & run to get it working more natively in pipelines.. but it was technically correct- common was not set on saConfiguraton (using the same stack config on both cases, that's the point) and should technically have errored out both times šŸ™‚
now on to the next issue - but I'm hoping that might be a tsc vs ts-node thing as well: previewing stack Error: The Pulumi runtime detected that 904 promises were still active at the time that the process exited.
that doesn't even occur when i do tsc build & run locally.. heh.
nah, actually - everything is weird everywhere now. I'm going to have to bow my head in shame until I pinpoint exactly what's going weird.
Copy code
// end of ts-node <http://stack.info|stack.info>() - exactly the same as for tsc version. 
    'azure:storageAccount': {
      value: '{"accounts":{"storage01":{"subnetReference":"sz4"}},"common":{"config":{"allowSharedKeyAccess":false}}}',
      objectValue: [Object],
      secret: false
    },
    'azure:subnets': {
      value: '{"sz2":{"serviceEndpoints":[{"service":"Microsoft.Storage"}]}}',
      objectValue: [Object],
      secret: false
    }
  },
  result: 'succeeded',
  endTime: 2021-03-27T10:47:22.000Z,
  resourceChanges: { delete: 11, same: 12 }
}
previewing stack
{ create: 1, delete: 1, same: 9, update: 2 }

[n10272-infratest-k8s] c:\<path>\baseline-infra (feature/pulumi-infratest -> origin) (baseline-infra)
Ī» pulumi preview --suppress-outputs
Previewing update (dev.infra.infratesting):
     Type                 Name                                   Plan
     pulumi:pulumi:Stack  baseline-infra-dev.infra.infratesting

Resources:
    12 unchanged
given the exact same stack config - somehow automation wants me to update 2 and pulumi cli has 12 unchanged. I'll dig a bit morte
Yeah - you're right - there's -definetely- something weird about how automation is reading stack config.
When running the debugger, it complained about my pulumi.requireObject("<configname>") stuff. it looks to me like it's somehow trying to set default values for at least /some/ things..
l