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

NodeDestroyResource needs to be referencable #23822

Merged
merged 2 commits into from
Jan 10, 2020

Conversation

jbardin
Copy link
Member

@jbardin jbardin commented Jan 9, 2020

The change in #23696 removed the NodeAbstractResource methods from the
NodeDestroyResource type, in order to prevent other resource behaviors,
like requesting a provider.

While this node type is not directly referenced, it was implicitly
ordered against the module cleanup by virtue of being a resource node.
The ReferenceTransformer uses the GraphNodeReferenceable and
GraphNodeSubPath interfaces to add nodes to the reference map, so we
need to re-add the relevant methods.

Since there's no good entry point to test this ordering at the moment,
add static checks for the interfaces, and document where these
interfaces are required.

Fixes #23821

@jbardin jbardin requested a review from a team January 9, 2020 19:03
@ghost ghost added the sdkv1 [PRs only] Marks changes that may potentially need to be ported to the plugi nSDK label Jan 9, 2020
Copy link
Contributor

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

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

🤔 This does make me wonder what other optional interface checks might be lurking for this, but I don't know of any to suggest specifically, so LGTM to the extent that I follow your line of reasoning. 😁

@jbardin
Copy link
Member Author

jbardin commented Jan 9, 2020

Looks like those "other optional interface checks" include targeting. I'll look into what's happening there.

@jbardin jbardin force-pushed the jbardin/destroy-resource-deps branch from a2cbd40 to 5fabb2a Compare January 9, 2020 19:33
@jbardin
Copy link
Member Author

jbardin commented Jan 9, 2020

Being a GraphNodeReferenceable, but not directly referenceable requires that a node also implement RemovableIfNotTargeted

The change in #23696 removed the NodeAbstractResource methods from the
NodeDestroyResource type, in order to prevent other resource behaviors,
like requesting a provider.

While this node type is not directly referenced, it was implicitly
ordered against the module cleanup by virtue of being a resource node.

Since there's no good entry point to test this ordering at the moment,
@jbardin jbardin force-pushed the jbardin/destroy-resource-deps branch from 5fabb2a to a6cdfad Compare January 10, 2020 17:53
While the NodeDestroyResource type should not be a
GraphNodeProviderConsumer, we're going to avoid uncovering more hidden
behavior by explicitly skipping provider creation and connections in the
provider transformers.

This should be removed when more in-depth testing can be done during a
major release cycle.
@jbardin jbardin force-pushed the jbardin/destroy-resource-deps branch from 353a4c5 to 4aa8a1c Compare January 10, 2020 21:29
@jbardin
Copy link
Member Author

jbardin commented Jan 10, 2020

Rather than risk discovering any more hidden behaviors associated with this type, add a GraphNodeNoProvider interface which will cause the Provider creation and connection to be skipped.

Copy link
Contributor

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

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

Agreed that this isn't very pretty, but I'm glad we have a way to do it that minimizes the risk of unintended regressions for now, so that we can defer the more risky change for a time when we are more ready to look at this problem holistically.

@jbardin jbardin merged commit 7500fa7 into master Jan 10, 2020
@jbardin jbardin deleted the jbardin/destroy-resource-deps branch January 10, 2020 22:15
@ghost
Copy link

ghost commented Mar 28, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Mar 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
sdkv1 [PRs only] Marks changes that may potentially need to be ported to the plugi nSDK
Projects
None yet
Development

Successfully merging this pull request may close these issues.

leftover module in state that should have been removed
2 participants