Azure Typescript Stack tries to deploy resources twice

[sebs]

Expected Behavior

I have a ts stack that breaks the deploy after trying to deploy resources twice in one go.

1. npm run build (only tsc compile)
2. npm run test
3. npm run snyth
4. npm run deploy (resources are deployed)

Actual Behavior

1. npm run build (only tsc compile)
2. npm run test
3. npm run snyth
4. npm run deploy

  │ Error: creating Storage Account (Subscription: "123
              │ Resource Group Name: "rg-me"
              │ Storage Account Name: "saname"): storage.AccountsClient#Create: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> Code="StorageAccountAlreadyTaken" Message="The storage account named saname is already taken."
              │ 
              │   with azurerm_storage_account.saname (saname),
              │   on cdk.tf.json line 99, in resource.azurerm_storage_account.saname (saname):
              │   99:       }
              │ 

1. The name choose is globally available (the first deploy of resource works)
2. The cdk.tf.json does only include one of those
3. Deleting the created resources and trying again creates the same error
4. local backend deploy ends with the same error

Stuff that is different to examples (or there was a lack of them and I had to come up with things)

1. I build to ./lib in order to have a explicit compile step and no generated js and interface files.
2. I do require from the downloaded stuff in './gen' and not the node packages.

Steps to Reproduce

1. npm run build (only tsc compile)
2. npm run test
3. npm run snyth
4. npm run deploy (resources are not deployed)

Versions

language: typescript OS: osx "cdktf": "0.19.0-pre.5", "constructs": "10.2.70",

Providers

┌───────────────┬──────────────────┬───────┬────────────┬──────────────┬─────────────────┐ │ Provider Name │ Provider Version │ CDKTF │ Constraint │ Package Name │ Package Version │ ├───────────────┼──────────────────┼───────┼────────────┼──────────────┼─────────────────┤ │ azuread │ 2.42.0 │ │ ~> 2.41 │ │ │ ├───────────────┼──────────────────┼───────┼────────────┼──────────────┼─────────────────┤ │ azurerm │ 3.73.0 │ │ ~> 3.71 │ │ │ ├───────────────┼──────────────────┼───────┼────────────┼──────────────┼─────────────────┤ │ azurestack │ 1.0.0 │ │ ~> 1.0 │ │ │ └───────────────┴──────────────────┴───────┴────────────┴──────────────┴─────────────────┘

Gist

No response

Possible Solutions

No response

Workarounds

No response

Anything Else?

No response

References

No response

Help Wanted

• [X] I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[ansgarm]

to deploy resources twice

Are these two resource definitions? Do they maybe have properties that need to be unique? Could you share some code of these (presumably two azurerm_storage_account) resource definitions?

[sebs]

There is only one definition ...

    const storageAccountName = this.nameIt.nameKebap('storage-account');
    const storageAccount = new StorageAccount(this, storageAccountName, {
      name: this.nameIt.shortnameLowerCase('storage-account'),
      location: 'North Europe',
      resourceGroupName: credentials.resourceGroupName,
      accountTier: "Standard",
      accountReplicationType: "LRS"
    });

[sebs]

that was my mistake in this case.
I will close

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.