bug: Destroy RoleOwnershipGrant revert_ownership_to_role_name parameter ignored

[hexDoor]

What happened?

When attempting to destroy RoleOwnershipGrant resource via Python SDK, providing a role for ownership to revert is ignored and defaults to accountadmin.

eg:

snowflake.RoleOwnershipGrant(
    id,
    current_grants="COPY",
    on_role_name="SUBCHILD_ROLE",
    to_role_name="CHILD_ROLE",
    revert_ownership_to_role_name="PARENT_ROLE",
)

Snowflake history reports that ownership grant was attempted to be given to accountadmin rather than parent_role:

GRANT OWNERSHIP ON ROLE "SUBCHILD_ROLE" TO ROLE "ACCOUNTADMIN" COPY CURRENT GRANTS

Expected Behavior

Ownership grant should've been assigned to parent_role.

Steps to reproduce

Unfortunately, I'm limited in how specific I can be.

Obviously we are attempting to destroy a stack of role grants via the pulumi Python SDK with the stack defined through pulumi_snowflake resources.

eg resource:

snowflake.RoleOwnershipGrant(
    id,
    current_grants="COPY",
    on_role_name="SUBCHILD_ROLE",
    to_role_name="CHILD_ROLE",
    revert_ownership_to_role_name="PARENT_ROLE",
)

Output of pulumi about

CLI
Version 3.60.0
Go Version go1.20.2
Go Compiler gc

Host
OS darwin
Version 13.2.1
Arch arm64

This project is written in python: executable='/nix/***/bin/python3' version='3.8.12
'

Current Stack: ***

Note: *** refers to masked information

Additional context

I have a sneaking suspicion that this might just be because pulumi_snowflake is an automated port of the terraform provider but would like a second opinion on this.

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).

[guineveresaenger]

Hi @hexDoor - thank you for filing this bug.

This behavior is almost certainly an upstream bug. You may be able to file an issue in their repository.

Can you confirm that you are using the latest version of this provider?

[hexDoor]

Hi @hexDoor - thank you for filing this bug.

This behavior is almost certainly an upstream bug. You may be able to file an issue in their repository.

Can you confirm that you are using the latest version of this provider?

@guineveresaenger Will do.

We had pinned 0.14.0 but I bumped us up to the latest which i believe is 0.20.0 at time of writing.
This did not fix things unfortunately.

Could we also confirm that it's not an issue from the bridging (code gen from tf to pulumi)?
I've read the relevant code in the terraform repository and this entire feature seems very simple and straightforward (hardcode -> variable).
Snowflake-Labs/terraform-provider-snowflake#1334

I'll also take a look through pulumi internals during work hours to see if this is working correctly as I haven't been able to locate the relevant area of the code base yet.
If anyone has any tips or information to assist me in this, any info would be greatly appreciated.

I don't have the resources at my current disposal to test if the terraform provider is working correctly but I will update this thread accordingly.

[hexDoor]

So this one was a huge misunderstanding.
We assumed that we could introduce these variables into the snowflake resource without having to update state files with up.
Works perfectly fine once we do another up before destroy to update the state files.