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

Ensure we still read/refresh remote state when activate is set to false. #345

Merged
merged 1 commit into from
Dec 16, 2020

Conversation

phamann
Copy link
Member

@phamann phamann commented Dec 13, 2020

TL;DR

Fixes an edge case in the fastly_service_* resources, in which we don't refresh remote state if the activate field is set to false. This was introduced in #269, when we refactored the service resources to the "block" model and introduced the base service definition interface.

What?

After a couple of bug reports related to activate = false via Fastly support, we investigated further and found that if a configuration has the activate field set to false AND it has no previous active version the state wasn't being read. This manifested itself as a runtime error in certain situations, such as another resource referencing the state in its configuration.

It turns out we were assuming that the service will always have an active version number greater than 0 within the Read method and gating the read on that condition.

Fixes: hashicorp/terraform#27258

Note:

I've ran the tests I introduced in this PR to confirm this fixes the issue. However still ned to run the full suite before merging, which I'll try and do in the coming days.

// service version details call. This is to ensure we still read all of the
// state below.
shouldActivate := d.Get("activate").(bool)
if s.ActiveVersion.Number == 0 && isImport || !shouldActivate {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on the fence if this this is the cleanest way of solving this, or instead changing the gate on read conditional logic on line 165. Thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's talk through the alternative implementation first before we go ahead and approve/merge this changeset.

@phamann phamann force-pushed the phamann/dictionary-active branch from 4392401 to 356f8d8 Compare December 14, 2020 19:24
@phamann
Copy link
Member Author

phamann commented Dec 16, 2020

As discussed with @Integralist separately, this is now ready to merge and full acceptance test suite is passing (other than some unrelated WAF ones which are broken due to external API changes).

@phamann phamann merged commit 34f6fdf into master Dec 16, 2020
@phamann phamann deleted the phamann/dictionary-active branch December 16, 2020 09:41
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.

Unable to use 'for' expression with TypeSets with computed attributes
2 participants