-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
stream.eventNames() broken on 21.2.0+ #51302
Comments
I will try to fix this one |
@juanarbol do you mind if you share how are you planning to approach this issue, do you paln to make changes on the default undefined values or add something/ enhacement that caters to them the undefined listeners so that it won't cause events to be as one? i'm just curious |
I don't know yet, I will figure that out later. |
I suspect eventNames() is called a lot less frequently than the benefits of that pre-allocation PR, so I would suggest changing eventNames to do a more rigorous check that the keys are not only there but also are non-empty arrays. |
Hey @Qard can you pls tell me a instance where we are using the |
@juanarbol I was looking into the issue, and I found myself creating a PR. I'm not sure if it's the right way to do it, but I would like to know how you will fix it. |
Version
v21.2.0
Platform
Darwin COMP-JX471G9FQQ 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 arm64 arm Darwin
Subsystem
streams
What steps will reproduce the bug?
Use
stream.eventNames()
on a stream and you'll find it reports having event listeners for events which it does not actually have listeners for due to this _events pre-allocation change which released in 21.2.0.How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior? Why is that the expected behavior?
stream.eventNames()
should only return names of events for which there actually are listeners.What do you see instead?
All expected event types report having listeners because it's based on
Reflect.ownKeys(...)
which will see the explicitundefined
keys as present and assume that means there are listeners for that event name.Additional information
No response
The text was updated successfully, but these errors were encountered: