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.

Sign up for GitHub

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

Jump to bottom

Hitting internal Node assert running against Node 19.8.0 #12434

Closed
justinvp opened this issue Mar 15, 2023 · 2 comments · Fixed by #12445
Closed

Hitting internal Node assert running against Node 19.8.0 #12434

justinvp opened this issue Mar 15, 2023 · 2 comments · Fixed by #12445
Assignees
@justinvp
Labels
awaiting-upstream Awaiting upstream dependency kind/engineering Work that is not visible to an external user language/javascript resolution/fixed This issue was fixed
Milestone
0.86

Comments

@justinvp
Copy link
Member

For example:

https://github.com/pulumi/pulumi/actions/runs/4421137654/jobs/7751736438#step:32:558

    /opt/hostedtoolcache/node/19.8.0/x64/bin/node[50518]: ../src/module_wrap.cc:599:v8::MaybeLocal<v8::Promise> node::loader::ImportModuleDynamically(v8::Local<v8::Context>, v8::Local<v8::Data>, v8::Local<v8::Value>, v8::Local<v8::String>, v8::Local<v8::FixedArray>): Assertion `(it) != (env->id_to_function_map.end())' failed.
     1: 0xbf9680 node::Abort() [/opt/hostedtoolcache/node/19.8.0/x64/bin/node]
     2: 0xbf96fe  [/opt/hostedtoolcache/node/19.8.0/x64/bin/node]
     3: 0xbaf577  [/opt/hostedtoolcache/node/19.8.0/x64/bin/node]
     4: 0xf5966f v8::internal::Isolate::RunHostImportModuleDynamicallyCallback(v8::internal::MaybeHandle<v8::internal::Script>, v8::internal::Handle<v8::internal::Object>, v8::internal::MaybeHandle<v8::internal::Object>) [/opt/hostedtoolcache/node/19.8.0/x64/bin/node]
     5: 0x13c2ffb v8::internal::Runtime_DynamicImportCall(int, unsigned long*, v8::internal::Isolate*) [/opt/hostedtoolcache/node/19.8.0/x64/bin/node]
     6: 0x18425f4  [/opt/hostedtoolcache/node/19.8.0/x64/bin/node]

19.8.0 was released ~5 hours ago. Previous runs on 19.7.0 don’t hit this assert.

I think for now, we should pin to Node 19.7.0 to unblock CI until we understand what’s going on with Node 19.8.0.
@justinvp justinvp added kind/bug Some behavior is incorrect or out of spec language/javascript labels Mar 15, 2023
@justinvp justinvp mentioned this issue Mar 15, 2023
Merged
@justinvp
Copy link
Member Author

Upstream issue: nodejs/node#47096

@justinvp justinvp added awaiting-upstream Awaiting upstream dependency kind/engineering Work that is not visible to an external user and removed kind/bug Some behavior is incorrect or out of spec labels Mar 15, 2023
bors bot added a commit that referenced this issue Mar 15, 2023
@bors @Frassle
@abhinav @justinvp
Merge #12426 #12433 #12435
985c81c 
12426: filestate/internal: Use stack reference, not name r=abhinav a=abhinav

filestate backend currently operates exclusively with stack names.
All its internal pass around just the stack name, and nothing else.
This makes it a bit difficult to add project support to the backend.

This is a refactor in advance of adding project support,
changing the internals of filestate to pass a stack reference around.
It inspects the reference directly for all its operations.

Note: This contains no behavioral changes.
Name and FullyQualifiedName currently both return just the stack name.
In a future change, once project name is incorporated into the object,
FullyQualifiedName will be able to return `organization/$project/$name`.

Change extracted from #12134


12433: sdk/go: Don't use Provider for type if package doesn't match r=abhinav a=abhinav

In #12296, we started correctly interpreting the Provider argument
per other SDKs. but this introduced a regression:
the Provider field is now set for resources with mismatched types.

This results in a scenario where a provider foo for package X
is passed to a resource bar with package Y,
with the intent of plumbing it to bar's descendants,
but bar attempts to incorrectly use the provider directly.

    foo := NewXProvider()
    bar := NewYThing("bar", Provider(foo))
    // ...
    baz := NewXThing("baz", Parent(bar)) // should use foo

This worked previously, but with #12296, this fails
because NewYThing attempts to use Provider foo directly.

To fix this, we need to prevent NewYThing from using a provider
that does not match the package that it belongs to.
We had to make a similar change to the Python SDK in #12292.

https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927

The regression test is specific to remote component resources
per #12430, but the issue would be caused even for normal component
resources before this.

Resolves #12430


12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=abhinav a=justinvp

Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0.

Part of #12434

Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
bors bot added a commit that referenced this issue Mar 15, 2023
@bors @abhinav @justinvp
Merge #12433 #12435
629f11c 
12433: sdk/go: Don't use Provider for type if package doesn't match r=abhinav a=abhinav

In #12296, we started correctly interpreting the Provider argument
per other SDKs. but this introduced a regression:
the Provider field is now set for resources with mismatched types.

This results in a scenario where a provider foo for package X
is passed to a resource bar with package Y,
with the intent of plumbing it to bar's descendants,
but bar attempts to incorrectly use the provider directly.

    foo := NewXProvider()
    bar := NewYThing("bar", Provider(foo))
    // ...
    baz := NewXThing("baz", Parent(bar)) // should use foo

This worked previously, but with #12296, this fails
because NewYThing attempts to use Provider foo directly.

To fix this, we need to prevent NewYThing from using a provider
that does not match the package that it belongs to.
We had to make a similar change to the Python SDK in #12292.

https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927

The regression test is specific to remote component resources
per #12430, but the issue would be caused even for normal component
resources before this.

Resolves #12430


12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=abhinav a=justinvp

Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0.

Part of #12434

Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
bors bot added a commit that referenced this issue Mar 15, 2023
@bors @justinvp
Merge #12435
c7b54e2 
12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=abhinav a=justinvp

Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0.

Part of #12434

Co-authored-by: Justin Van Patten <jvp@justinvp.com>
bors bot added a commit that referenced this issue Mar 15, 2023
@bors @justinvp
Merge #12435
e5b9595 
12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=justinvp a=justinvp

Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0.

Part of #12434

Co-authored-by: Justin Van Patten <jvp@justinvp.com>
@justinvp justinvp self-assigned this Mar 15, 2023
@justinvp justinvp added this to the 0.86 milestone Mar 15, 2023
@justinvp
Copy link
Member Author

Node v19.8.1 was just released with the fix. Once our release goes out, I'll open a PR to bump Node back to 19.x.

@justinvp justinvp mentioned this issue Mar 15, 2023
Merged
@bors bors bot closed this as completed in 96d4148 Mar 15, 2023
@pulumi-bot pulumi-bot added the resolution/fixed This issue was fixed label Mar 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@justinvp justinvp

Labels
awaiting-upstream Awaiting upstream dependency kind/engineering Work that is not visible to an external user language/javascript resolution/fixed This issue was fixed
Projects
None yet
Milestone
0.86
Development

Successfully merging a pull request may close this issue.

Unpin Node back to 19.x pulumi/pulumi
2 participants
@justinvp @pulumi-bot