fix: remove repository topic from state if it doesnt exist in GitHub anymore

[felixlut]

---

Before the change?

• When running terraform plan on a configuration including a repository_topic resource when the repository itself has been deleted outside of terraform, you get a 404 Not Found error.

After the change?

• When running terraform plan on a configuration including a repository_topic resource when the repository itself has been deleted outside of terraform, terraform will simply remove the topics from its state. This makes it easier to deal with drifts. My use-case is that I use repository_topic as a standalone resource without a standalone repository resource, and instead reads a datasource for the repo.

Pull request checklist

• Tests for the changes have been added (for bug fixes / features)
  • No idea how to properly test this
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

• Yes
• No

---

[nickfloyd]

Thanks @felixlut your use case and approach definitely seem reasonable. I am tempted to make this a "breaking change" because it changes the current behavior of the provider - whereas previously a 404 was expected now you get an info log and passthrough. Let me chat with @kfcampbell about this and get his take on it. I like the change I just don't want to end up harming other's implementations that assume they will see a 404 and take action on that. Though, unlikely, I still want to do the due diligence.

[felixlut]

Thanks @felixlut your use case and approach definitely seem reasonable. I am tempted to make this a "breaking change" because it changes the current behavior of the provider - whereas previously a 404 was expected now you get an info log and passthrough. Let me chat with @kfcampbell about this and get his take on it. I like the change I just don't want to end up harming other's implementations that assume they will see a 404 and take action on that. Though, unlikely, I still want to do the due diligence.

Thank you for your reply!

Yes, I agree, this is actually a breaking change. I missed it while creating the PR, my apologies 😅

I think it shouldn't be too hard to add an argument in the resource for avoiding the breaking change if you want. Something along the lines of strict_deletion or similar, which would only do the passthrough on false. The argument would be true by default. The default behavior would then always be that it doesn't do the passthrough. I'll leave that decision to you guys. Important note to make is that I created the topic resource just a couple of weeks back, so the usage cannot be too high, which makes me lean towards breaking change to not have a long-living issue (strict_deletion can always be added retroactively)

[felixlut]

Hey! Any update on this?

[nickfloyd]

Hey @felixlut I'm still trying to gather up some details and see if there are any other breaking changes out there that we could get in. Hashicorp has a strong recommendation of not having more than one major version bump aper year that I want to be sensitive to and @kfcampbell is currently out until next week - I want to make sure he's had a moment to look over the potential of a major bump as well.

Apologies for the delay on this - we'll get it in as soon as we have a better idea of what we can meaningfully ship with this change set. Thank you for the patience on this.

[felixlut]

@nickfloyd no issue, just wanted to know it wasn't completely forgotten!

I've been running a fork of your provider since the opening of this PR, and want to get back to stable waters. On the positive side, this change has been tested for a bit 😅

[kfcampbell]

@felixlut we'd love to publish a new major version in the near future (next couple months?) pending our team's capacity to do so. Thanks for your persistence here!

[kfcampbell]

I'm going to merge this PR into our v6 branch before cutting a new major version. Please see #2091 to follow this changeset on its journey towards release!