Provisioning a new ResourceServer results in a panic
#285
Comments
PatrickMilroy
added
kind/bug
iwahbe
added
area/providers
p1
|
Hi @PatrickMilroy. Thanks for pointing this out. I have successfully reproduced (without credentials) with this program: import * as auth0 from "@pulumi/auth0";
const config = {
hostname: "host",
name: "name",
};
const hostname = `${config.hostname}`
const auth0ApiName = `${config.name}-api`
const name = config.name;
const auth0Api = new auth0.ResourceServer(
auth0ApiName,
{
name: `${name} API (Managed by Pulumi)`,
identifier: hostname,
signingAlg: 'RS256',
allowOfflineAccess: true,
tokenLifetime: 86400,
},
{
deleteBeforeReplace: true,
},
)
new auth0.ResourceServerScopes(
`${name}-api-scopes`,
{
resourceServerIdentifier: auth0Api.identifier,
scopes: [
{
name: 'create:foo',
description: 'Create Foos',
},
],
},
) |
|
|
|
I tried reproducing it with terraform and I think this issue is unique to Pulumi. We fail on this line where the provider tries to get a name of (not yet created) server: https://github.com/auth0/terraform-provider-auth0/blob/0269a8792e08ed5d990d3d19996695d6bf144ebe/internal/auth0/resourceserver/resource.go#L299 The state comes from I logged the state: and the so it is indeed empty, which causes the provider to panic. @t0yv0 @iwahbe Do you see a venue to fix this in the bridge? |
|
Sure; GetRawState used to be not supported at all but with pulumi/pulumi-terraform-bridge#1314 we introduced an approximation that sends a non-nil data to GetRawState; for most simple cases this data matches what TF would send and this has improved provider reliability; however a lot of work remains to get it on par or matching identically with what TF sends to GetRawState, along the lines of pulumi/pulumi-terraform-bridge#1282 I'd also be open to look at quick resolution options here such as patching this not to panic if possible but handle the case when state.GetAttr("name") is nil if this can be made to work: |
What is "this" that you suggest patching? |
|
Apologies for lack of clarity. We can patch the upstream codebase to avoid the panic and try to recover from the missing "name" attribute. Perhaps we can go the route of time boxed attempt to fix in the bridge generically and falling back to patching temporarily if that takes longer than we can wait on the fix here. |
Resolve #285 by patching the check upsteam It's my first patch ever, so let me know if I'm doing it wrong.
What happened?
Trying to create a new
ResourceServerresults in following error:Updating existing resources that were created using a previous version of the provider (
2.14.0in this instance) succeeds without issue.Downgrading to
2.22.0resolved this issueExpected Behavior
A new
ResourceServerto be provisioned in the applicable Auth0 TenantSteps to reproduce
In a pulumi project with
"@pulumi/auth0": "2.24.0", Provision a new auth0ResourceServerwith the following configuration:Output of
pulumi aboutAdditional context
Updating existing resources that were created using a previous version of the provider (
2.14.0in this instance) succeeds without issue.Downgrading to
2.22.0resolved this issueContributing
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).
The text was updated successfully, but these errors were encountered: