[Bug]: Error: reading RAM Resource Share (arn:aws:/ram/:eu-west-2:xxxxxx:resource-share/"xxxxxx): couldn't find resource

[Viktork25]

Terraform Core Version

1.1.0

AWS Provider Version

5.14.0

Affected Resource(s)

Error: reading RAM Resource Share (arn:aws:/ram/:eu-west-xxxxxxx:resource-share/xxxxx): couldn't find resource

Expected Behavior

We are trying to connect our transit gateway with a share transit gateway which has auto acceptance in place.The ram share-resource should be working and not tainted as it turns up and have a full transit gateway attachment shared

Actual Behavior

The ram share-resource fails and says that cannot be finded but ch checking the AWS Console, that share-resource is active and is already accepted.

Relevant Error/Panic Output Snippet

Error: reading RAM Resource Share (arn:aws:/ram/:eu-west-2:xxxxxxxxxxxxxx:resource-share/"xxxxxxxxxxxxxxxxxxxxxxx): couldn't find resource

Terraform Configuration Files

module.vpc_eu_west_2[0].aws_/ram/_resource_share_accepter.this[0] is tainted, so must be replaced

+/- resource “aws_ram_resource_share_accepter” “this” {

 ~ id = “arn:aws:ram:eu-west-2:xxxxxxxx:resource-share/xxxxxxxxxxxxx” -> (known after apply)

 ~ invitation_arn = “arn:aws:/ram/:eu-west-2:xxxxxxxxxxxx:resource-share-invitation/xxxxxxxxxxxxxxx” -> (known after apply)

 ~ receiver_account_id = “xxxxxxxx” -> (known after apply)

 ~ resources = [

 - “arn:aws:ec2:eu-west-2:xxxxxxxxxxxxxx:transit-gateway/tgw-000000000000”,

 ] -> (known after apply)

 ~ sender_account_id = “xxxxxxxxxxx” -> (known after apply)

 ~ share_id = “rs-xxxxxxxdddddddddddd” -> (known after apply)

 ~ share_name = “T-SHARE” -> (known after apply)

 ~ status = “ACTIVE” -> (known after apply)


 # (1 unchanged attribute hidden)

Steps to Reproduce

1. New transit gateway ram-share
2. Auto accepted from share account
3. Ram share is active
4. Rerun the pipeline to have the attachment and create the transit gateway in the receiver account

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[justinretzolk]

Hey @Viktork25 👋 Thank you for taking the time to raise this! Are you able to provide a sample Terraform configuration that exhibits this behavior, as well as debug logging? There's often helpful context in there for for whoever winds up looking into this.

[avakil95]

Hello, we are experiencing this same issue.

The odd thing is, when the resource is attempted to get created, it does indeed accept the resource share invitation but fails to create with the error:
Error: reading RAM Resource Share (arn:aws-us-gov:ram:us-gov-west-1:XXXXXXXXX:resource-share/XXXXX-XXXXXXX): couldn't find resource

When I run an apply on the resource again, terraform thinks the resource is tained and wants to replace it. If I apply the resource, the same error occurs and it never thinks the resource is fully created.

I'm on Terraform v1.5.7 and AWS provider version 5.13.0, but I've also tried AWS provider version 5.32.1 and the same thing happens.

[Ilhicas]

Having the exact same error on version 5.16 and terraform 1.5.7
There are several references #18332 that state the same issue which was fixed in 3.38

Its also fixable by using a sleep condition (awful approach) but

`resource "time_sleep" "wait_15_seconds" {
depends_on = [ "some_module" , "resource", "etc" ]

create_duration = "15s"
}`

Then proceed to depend on it on the resource_share_accepter resource

This leads to the idea that issue is a race condition when resources are created within a few seconds apart

[alexanderphoenix]

It seems for us it isn't a matter of waiting.

We have the same error couldn't find resource as the one in the original post shows, however the invitation was in fact found and accepted.

Re-deploying is met with a invitation not found message, which is to be expected since the original invitation was accepted and therefore isn't there any longer. The resource itself is marked as tainted and wants the resources within it to be replaced, procedure that ends up in failure.

The only way past this problem is to untaint the resource, after which everything is hunky dory:

terraform untaint module.ram_share.aws_ram_resource_share_accepter.subscriber

Resource instance module.ram_share.aws_ram_resource_share_accepter.subscriber has been successfully untainted.

We tried introducing the delay as mentioned in the previous comment and also in the example on the time_sleep documentation here, however this did not solve the problem for us, we were still having to perform the procedure I mentioned above.

A time delay and invitation checking are surely good to have, however there is a chance it may only solve part of the problem.

Tested with tf 1.5.7 and aws provider 5.29.0

[github-actions]

This functionality has been released in v5.37.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

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