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

cloudflare_record: check record.Priority using the API, not the schema #992

Merged
merged 1 commit into from
Mar 14, 2021

Conversation

jacobbednarz
Copy link
Member

Following on from the changes in 2.19.0 (and 2.19.1 to actually ship the
change), a regression was introduced that is inadvertantly causing a
panic due to the d.GetOkExists failing to accurately determine when to
apply the record.Priority value to the state.

d.GetOkExists is documented as:

GetOkExists can check if TypeBool attributes that are Optional with
no Default value have been set.

While the value isn't a bool, it acts similarly as 0 in this context is
both a valid value and a zero value for the field.

To combat the panic, I've swapped the check to instead compare the value
provided by the API to determine whether or not we want to set it. This
approach wasn't initially taken as the API used to return 0 in all cases
where the value wasn't explicitly set and the underlying library would
ignore it. Hopefully, with MX records allowing 0, this is no longer an
issue going forward.

Closes #988

@jacobbednarz jacobbednarz force-pushed the use-api-nil-check-instead-of-schema branch from f198158 to fc77add Compare March 11, 2021 23:45
Following on from the changes in 2.19.0 (and 2.19.1 to actually ship the
change), a regression was introduced that is inadvertantly causing a
panic due to the `d.GetOkExists` failing to accurately determine when to
apply the `record.Priority` value to the state.

`d.GetOkExists` is documented as:

> GetOkExists can check if TypeBool attributes that are Optional with
> no Default value have been set.

While the value isn't a bool, it acts similarly as 0 in this context is
both a valid value and a zero value for the field.

To combat the panic, I've swapped the check to instead compare the value
provided by the API to determine whether or not we want to set it. This
approach wasn't initially taken as the API used to return 0 in all cases
where the value wasn't explicitly set and the underlying library would
ignore it. Hopefully, with MX records allowing 0, this is no longer an
issue going forward.

Closes #988
@jacobbednarz jacobbednarz force-pushed the use-api-nil-check-instead-of-schema branch from fc77add to 5daf453 Compare March 12, 2021 03:00
@Ka1wa
Copy link

Ka1wa commented Mar 12, 2021

Worked for our repository. Crashed with 2.19.1.

@jacobbednarz
Copy link
Member Author

Thank you @Ka1wa! Just for posterity, could you post what record type and it's configuration in case down the track we dig further into the cause?

@aybabtme
Copy link

I saw the same issue with only A records and no priority set on that block.

@jacobbednarz jacobbednarz merged commit 9349099 into master Mar 14, 2021
@jacobbednarz jacobbednarz deleted the use-api-nil-check-instead-of-schema branch March 14, 2021 20:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Plan crashes with provider 2.19.1
3 participants