Hi,
after upgraded to meteor 3.4 and node 22 i get error Error: querySrv ECONNREFUSED wher running locally.
NODE_OPTIONS=–dns-result-order=ipv4first
does not help.
What should i do? thanks.
Hi,
after upgraded to meteor 3.4 and node 22 i get error Error: querySrv ECONNREFUSED wher running locally.
NODE_OPTIONS=–dns-result-order=ipv4first
does not help.
What should i do? thanks.
Which Meteor version are you upgrading from?
Did you add the Rspack package, or did you just run meteor update --release 3.4 and keep using the Meteor bundler?
Do you have any minimal reproduction repository?
i run meteor update, then added rspack, error came before rspack too.
(post deleted by author)
so wtf is this again dns: fix Windows SRV ECONNREFUSED regression by correcting c-ares fallback detection by NotVivek12 · Pull Request #61453 · nodejs/node · GitHub !!! i will never update anything again since these kind of bullshit is released.
So, the regression seems to come from the Node upgrade. It’s on their side to fix it.
About Meteor, yes, you can skip the Rspack update and just ensure everything works as it did in 3.4, then try to migrate to Rspack if you wish. Anyway, if this is a Node issue, Meteor can’t fix it until a new Node version is released. Most likely it will be addressed in a Meteor 3.4.x patch or in 3.5, once the Node fix is available.
but meteor cannot be updated to 3.4 until this works so this is useless update from your side
rspack has nothing to do with this.
here is fix to windows users
create dns-fix.js somewhere
dns.setServers(['1.1.1.1', '8.8.8.8']);
and start your script
set MYDIR=%CD%
SET NODE_OPTIONS=--require=%MYDIR%\dns-fix.js --dns-result-order=ipv4first
meteor run
Well, I completely disagree with that statement. Releases must move forward when there are no reports or clear evidence of major failures. Regressions can appear later, and we can’t cover every existing use case, especially minor ones. Still, we will do what it takes to fix them once identified, and add regression test coverage.
Regarding your specific issue, it was introduced on Node’s end and it only happens on Windows and under certain conditions. I use Windows myself and have been testing Meteor 3.4 throughout the whole development cycle, and I never hit this regression. I tested broadly far too many use case scenarios in Meteor 3.4, specially given the critical update this was on bundler updates. I just tested again on Windows to double check, even using --dns-result-order=ipv4first. New apps on 3.4 work fine for me.
That said, there are scenarios where this issue can happen (like yours), but this is on Node’s side to fix in this specific case. Meteor 3.4 went through long beta and RC periods. You could have helped by testing your failing case and reporting it earlier. We have repeatedly mentioned how important testing assistance is. Since this depends on Node (a regression from them), we would have released anyway, or provided a workaround on Meteor’s side if reported. We cannot block everyone else for a Windows-only issue on certain circumstances that already has a workaround, especially given the improvements shipped in 3.4, which many others helped us test and that are working fine on their end.
That said, thanks for sharing the workaround here, straight from the GitHub issue. It will help others who run into this problem. We will track the issue to know when it is fixed on Node’s end and bump it on Meteor’s side as well, hopefully within the Meteor 3.4.x series.
We will keep improving our process and aim to get more help testing these specific cases, while continuing to support everyone with new updates to improve the experience in Meteor and modernize it. In return, we ask for patience and assistance.
Thank you for your reply. I accept your disagreement. I get very frustrated since suddenly things dont work, even i have since Meteor 1.4.