Graceful handling of 409 Conflict when creating duplicate column about terraform-provider-honeycombio

[kvrhdn]

Hi Tyler, thank you for your contributions! This request seems reasonable, I'm actually wondering why it doesn't already work that way... I'll check out your PRs in the next few days, at the latest end of next week.

[jharley]

Hi, @mattjw!

The logic changed in v0.12.0 of the provider as it started doing column deletes and the behaviour of what amounted to "automatic import" is not a normal -- and arguably a dangerous -- Terraform workflow.

For the same reason, I'm pretty against any sort of allow_preexisting or create_if_missing options as I don't think they match the general Terraform workflow.

[mattjw]

Hi 👋. Has there been a regression with this feature? I've hit a similar 409 error mentioned by the OP, which happens when Terraform tries to provision a column that exists already:

│ Error: 409 Conflict: Could not add or update the column: column already exists with this key_name or alias.
│
│   with honeycombio_column.myservice_columns["mycolumn"],
│   on honeycomb-dashboards.tf line 68, in resource "honeycombio_column" "myservice_columns":
│   68: resource "honeycombio_column" "myservice_columns" {

This is with v0.15.0 (June 2023) of the provider.

Thanks.

One other suggestion: If the provider does support this "fail gracefully if the column exists" behaviour, I wonder if it should be optional with a flag like allow_preexisting = true (or a better name :)).

[mattjw]

@jharley thanks for the reply. And that makes perfect sense. It did seem a little unusual to me too.

One a related topic, I was wondering if it's possible for the provider to validate the presence of required columns at plan-time? Rather than waiting to get a nasty surprise at apply?

Let me know what you think, and if there's appetite for this I'm happy to raise a feature enhancement request. (Presumably as an issue in this repo?)

[jharley]

We've discussed it a fair bit internally. There is more nuance to it than you may initially expect.

For example: what if the column is being made in the same plan-apply run? How do you detect that properly from inside of a query or derived column and handle the validation case? What about ordering of creation?

That said: I probably should have already opened an issue to show that we are aware of the pain point but it's a difficult thing to solve well. You're more than welcome to open an feature request :)