Panic: fatal: An assertion has failed #11464
Labels
kind/bug
Some behavior is incorrect or out of spec
resolution/duplicate
This issue is a duplicate of another issue
Comments
stefaneacsu147
added
kind/bug
Frassle
added
resolution/duplicate
|
Duplicate of #11391 I think. |
3 tasks
bors bot
added a commit
that referenced
this issue
Dec 6, 2022
11475: Handle replacements of resources marked for deletion r=Frassle a=Frassle <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This required getting state into a bit of unusual failure mode, but clearly people are hitting this (see #11391 and #11464). If we replace a resource with create before delete semantics, and then fail to delete it we end up with two copies of the resource in state, but one copy will have the "delete" flag set. If we then manage to trigger another resource to replace with delete before replace semantics that has the first resource as a dependent we would hit an assertion about Delete and PendingReplace both being set the same, if you just removed that asset then state management got confused and left the first resource in the state file even after it had really been deleted. So now we track if we've seen a pendingDelete for a resource via the state pointer not the URN (so we can handle the multiple state objects) and don't trigger a DeleteReplacement, but a plain Delete if the resource is already flagged to Delete. Fixes #11391 ## Checklist <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Service, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version <!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. --> Co-authored-by: Fraser Waters <fraser@pulumi.com>
bors bot
added a commit
that referenced
this issue
Dec 6, 2022
11475: Handle replacements of resources marked for deletion r=Frassle a=Frassle <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This required getting state into a bit of unusual failure mode, but clearly people are hitting this (see #11391 and #11464). If we replace a resource with create before delete semantics, and then fail to delete it we end up with two copies of the resource in state, but one copy will have the "delete" flag set. If we then manage to trigger another resource to replace with delete before replace semantics that has the first resource as a dependent we would hit an assertion about Delete and PendingReplace both being set the same, if you just removed that asset then state management got confused and left the first resource in the state file even after it had really been deleted. So now we track if we've seen a pendingDelete for a resource via the state pointer not the URN (so we can handle the multiple state objects) and don't trigger a DeleteReplacement, but a plain Delete if the resource is already flagged to Delete. Fixes #11391 ## Checklist <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Service, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version <!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. --> Co-authored-by: Fraser Waters <fraser@pulumi.com>
bors bot
added a commit
that referenced
this issue
Dec 7, 2022
11475: Handle replacements of resources marked for deletion r=Frassle a=Frassle <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This required getting state into a bit of unusual failure mode, but clearly people are hitting this (see #11391 and #11464). If we replace a resource with create before delete semantics, and then fail to delete it we end up with two copies of the resource in state, but one copy will have the "delete" flag set. If we then manage to trigger another resource to replace with delete before replace semantics that has the first resource as a dependent we would hit an assertion about Delete and PendingReplace both being set the same, if you just removed that asset then state management got confused and left the first resource in the state file even after it had really been deleted. So now we track if we've seen a pendingDelete for a resource via the state pointer not the URN (so we can handle the multiple state objects) and don't trigger a DeleteReplacement, but a plain Delete if the resource is already flagged to Delete. Fixes #11391 ## Checklist <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Service, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version <!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. --> 11494: Jazzyfresh/codegen python nonstring secrets r=jazzyfresh a=jazzyfresh <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description Fixes incorrectly generated python code when secret is a non-string type. <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Fixes #11278 ## Checklist <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Service, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version <!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. --> Co-authored-by: Fraser Waters <fraser@pulumi.com> Co-authored-by: Jasmine Dahilig <jasmine@pulumi.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
Steps to reproduce
Tried to do
pulumi previewandpulumi upand got the following error. I updated the Pulumi version but the issue still persists after the update.Expected Behavior
The preview and up to work as intended
Output of
pulumi aboutAdditional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: