-
Notifications
You must be signed in to change notification settings - Fork 44
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
Duplicate underscore panic #62
Comments
Slightly different version also panics:
|
Problem solved. environment: {
variables: { "HITS_TABLE": hits.name },
}, Seems like not panicking, and emitting an error (e.g. |
Please add a example to the documentation |
@byteSamurai The registry (at the time of writing this) does include an example which demonstrates the correct usage of |
Today, I encountered a similar symptom:
Used packages:
This happened during refactoring of a large code-base and I can't really pinpoint where or when the error is raised during the deployment. Therefore I'm not able to reproduce this in a small example. Facts I currently know:
Any suggestion on how I could debug this any further and how to pinpoint when/where this assertion fails during the deployment? edit: completed pasted diagnostics message (resource & error were missing) |
Thanks for reporting this! Coincidentally the panic assertion was removed in a recent release, not yet incorporated into the AWS provider: And we've also made a series of improvements to the name routine in recent pull requests, we may just need to work with the providers team to repro your bug and see if the recent changes resolve. |
@woeps could you help us reproduce by finding a minimal program or set of resources that, when you add them to your program, cause the panic? |
@AaronFriel I'd like to try, but without any hint on where I should start looking into this, I feel like it would be impossible to find the right combination to repro this issue. - We have a quite complex / large codebase. Is there any way to get some hint on where or when the assertion fails during a deployment? e.g. trace? Edit: I won't be able to update the node package |
@woeps Usually there should be one resource implicated in causing the panic. It'd be helpful if you could list the SDK and provider versions with the output of The fix I applied in #742 requires providers to upgrade to use it, and doesn't require the Pulumi engine (CLI) or core SDK to be updated, so you may be able to opt in to the fix here by updating the providers without updating Regarding your edit: if there's a breaking change in code serialization & you haven't already made an issue, please report this on https://github.com/pulumi/pulumi! Our customers rely on function serialization and we take breaks seriously. Just to make sure though, can you check to see if you're using Node 19.2 or 19.3? There was an upstream issue in V8 and Node that broke function serialization, and we requested that to be reverted. That was fixed in Node 19.4, see: |
@AaronFriel I ran
That's good to know! I wasn't quite sure, how independent these two packages were. PS: I updated my previous message containing the pasted error message to include all of the "diagnostics" message. I guess |
Given the age of the issue, the fact that the triggering assert is no longer present in our code base (and we have completely rewritten the relevant function), and the lack of a reproduction, and that there has been no new information in the last 4 months, I'm going to close as no-repro. If you see this issue again, please re-open this issue or raise a fresh issue. |
I defined the following (which I'm guessing is wrong in some way, haven't gotten that far):
Apparently the
"HITS_TABLE"
key is being transformed by our name mangling, leading to:The text was updated successfully, but these errors were encountered: