-
Notifications
You must be signed in to change notification settings - Fork 146
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
lookup: add hapi #436
lookup: add hapi #436
Conversation
Hard Requirements
Soft RequirementsAt least one of:
|
82de876
to
6fbb359
Compare
I see that there's a few builds failing on Node 8 which look to be related to the fixes that we have pending in hapijs/hapi#3507 around steams which once those changes land clear up the 3rd failing test for Node 8. Specifically the test The other two for Node 8 I'm able to reproduce successfully on my machine (Fedora 24) and I'll dig into them further. As for the failures that we are seeing with some Node 6 tests I'm not able to reproduce them on either of my machines (Fedora 24 and Windows 10). Those will need to be investigated further to see what's amiss. |
Note that this shouldn't be landed until we have green CI runs. |
Note that master had some issues with a recent change that worked on node 8 but broke on 4 and 6. Basically, when calling |
@hueniverse what's the tracking issue of that? I would like to take a look. There was a bug that was fixed in Node 8.1.3 (nodejs/node#13850), and there is another one in zlib that I am going to land this week if no one object (nodejs/node#14330). |
Tests are failing on some machines. It seems that
|
Do the hapi tests require |
Currently, yes. It looks like a few of them spawn it. |
@nodejs/build are we able to get lsof on host machines? |
What is the status here? |
Looks like it needs an issue opening in the build repo to see if we can get |
I've also opened a PR against hapi to allow the tests to pass when lsof does not exist. |
It seems like this could maybe land given that @cjihrig's patch is in hapi now? Or is there anything else outstanding? Would be nice to have hapi in CitGM. |
@targos would you be so kind and start a new CITGM? Seems like it is now outdated. |
And would someone be so kind and change the title to remove the |
There's still the issue of tests depending on the presence of
|
I'm happy to make sure hapi gets into citgm and making sure that future failures get resolved/reported to hapi. As for the latest errors. @devinivy it might be good to decide on how to relay breakage, do I just ping (Slack or here) or open up an issue on the hapi repo? |
I can confirm these failures on my MacOS 11.1 node 14.15.4. |
The |
For those following along, there are some proposed fixes for the osx, aix, and lsof-related failures here: hapijs/hapi#4221 🤞 |
@targos those fixes landed in hapi, so we should be ready for another run. I wasn't able to reproduce the issues on all platforms because I do not have access to them, but I made an effort to reduce or eliminate timing dependence in these failing tests, and I cleaned-up the lsof-related problems. If after the run any issues remain on OSX or AIX, is there any way we could utilize the citgm CI to help debug them? |
Is it still supposed to fail on Node.js 15 ?
|
In node 15.5.0 there was a change that broke hapi hapijs/hapi#4208 nodejs/node#33035. This change to node was reverted in 15.6.0, and hapi's test suite was fixed. Now on 15.7.0 it seems there's a new issue. I can reproduce it locally so I will check it out from the hapi perspective, but it does seem like it relates to some change in 15.7.0 (possibly nodejs/node#36821?). |
Seems very likely. Hapi relies on the And the failing test relies on the signal. |
@nodejs/http ^ |
That link looks at |
Yeah, confusingly it registers on 'aborted', and forwards it as 'abort'. |
Just thinking out loud here. The order in which the
I'll try to verify on the failing test, though. |
@dnlup: I think this has to do with server side, not client side. |
I'd suggest we try a revert of nodejs/node@708728d to see if that resolves the issue. |
Just checking in: is there anything we can do on the hapi side to help move this forward, or is this being looked into on the node side to determine whether the cause of the new failure in 15.7.0 was nodejs/node@708728d? |
Apologies for the late reply. The failing test seems to be in |
Diggin a little bit further, before the change what happened was:
While with the changes:
This makes sense to me on the Node side. I have to dig on the hapi side. You would be faster than me @devinivy on that part, assuming these pieces of information are useful in any way. |
@dnlup hey, no sweat. Will take a look on the hapi side, thanks! |
@dnlup node v15.7.0 did uncover a bug on our end! The issue for us wasn't the double emit of abort, but the timing between abort and close (they now seems to happen in the same tick, more info in hapijs/hapi#4234.) We were able to ship a fix in hapi v20.1.1. We are ready for another CI run 🤞 👍 |
@devinivy Great news you were able to find the problem and fix it. Thank you! |
Once this is green we can land it (needs a CI run first).
Checklist