Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a keep_error_code #54

Closed
wants to merge 3 commits into from
Closed

Add a keep_error_code #54

wants to merge 3 commits into from

Conversation

nicotruc
Copy link

@nicotruc nicotruc commented Dec 8, 2020

When program return error with the specified error code, the data source doesn't throw any Terraform error, and keep result from previous apply.

This may be used for program that can only be executed once.

When this parameter is set, a script that return the specified error code should not throw a Terraform error, and should keep its previous result
Add a keep_error_code attribute, so when script return the specified code, it doesn't throw a Terraform error and keep results from previous apply
@ghost ghost added size/XS labels Dec 8, 2020
Base automatically changed from master to main February 1, 2021 17:26
@bflad
Copy link
Contributor

bflad commented Dec 22, 2021

Hi @nicotruc 👋 Thank you for submitting this.

Data sources in Terraform are intentionally refreshed every run, so therefore exiting early without calling d.Set() on the attributes can leave those attributes unset in the Terraform state and other configuration references. This can cause unexpected Terraform CLI errors. Adding an argument which conditionally could cause those configuration issues would likely lead to practitioner confusion.

The current solution for handling "run once" behaviors in Terraform is using a resource, which may or may not live outside this particular provider. #5 can be used to track any discussions and efforts in that area.

Another potential solution within the existing data source may be to allow non-0 exit status codes to continue the data source logic, instead of returning early. In that implementation, the result attribute can still be correctly filled in. In that implementation, it'd likely be best to accept a set of integers as the attribute, e.g.

"success_exit_status_codes": {
	Description: "Successful exit status codes. By default, the data source will error on non-zero exit status codes.",
	Optional:    true,
	Type:        schema.TypeSet,
	Elem:        schema.Schema{Type: schema.TypeInt},
},

Since this pull request implements behavior that is less than desirable in this data source, I'm going to close this for now. If you are interested in the above suggestion, we are happy to take a fresh look. Thanks again, @nicotruc.

@bflad bflad closed this Dec 22, 2021
Copy link
Contributor

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants