Seems like this upgrade finally kills being able to use datadog trace (dd-trace) and probably any other package that relies on async-hooks. Or is there any reason to believe this crash can be fixed?
TypeError: Cannot read property 'Symbol(ddResourceStore)' of undefined
at Scope._init (...node_modules/dd-trace/packages/dd-trace/src/scope/async_resource.js:70:33)
at emitInitNative (internal/async_hooks.js:207:43)
at emitInitScript (internal/async_hooks.js:475:3)
Hi, dd-trace team implemented a workaround to work with node-fibers on Node.js 12. I’m not sure if a new workaround needs to be implemented for Node.js 14 or not.
Could you please open a question in their repo? If they have questions for us they will get in contact with me Thanks.
Hi @a4xrbj1, before I ask a question here let me say very clearly: I really love datadog and at Meteor we use their services to monitor many of our components, mostly our Go components that provide Proxies, Schedulers, Image builders, Automatic Certificates and everything in our infrastructure.
Now my honest question, what exactly are you tracking with dd-trace that you are not able to track with APM? This is a very honest question from someone that already scaled many Meteor apps in productions and I never used dd-trace, probably I’m missing something.
In my optimizations and monitoring cases Meteor APM + Memory Profiler package + CPU Profiler package where enough to me but I would like to understand more the usage of dd-trace with Meteor apps, I’m sure they are offering something that is great for Node.js apps in general
We describe a little bit on how to understand problems with your container in this package of Galaxy (cloud) Guide Container environment | Galaxy Docs
Specifically in these paragraphs:
One important tool to identify bottlenecks is the Meteor APM as it shows to you the Methods and Publications running. Specially in cases where you have spikes in CPU usage keep an eye as well in background jobs, maybe they are consuming all your CPU and then your container becomes unhealthy. Node.js is single threaded so is very important to be aware of heavy CPU operations in your app, mainly if you run background job tasks in the same app your users use the UI.
You can also profile your CPU as you would in any Node.js project, this package can help you to generate a profile and send it to S3. If your problem is related with memory you could use this package to get heap dumps from your container.
Again, I’m not advising against datadog, I just want to understand more what they are offering to you and Meteor users in general. I really love their services
My bad, I read DataDog and jumped (because I was just praising them in today’s Meteor meetup presentation where I presented my Electron app.
Not using dd-trace (or rather DataDog APM) so it’s actually not a problem (for me).
We use them mainly for log file handling and monitoring of our Fargate, Lambda and MongoDb.
Besides we don’t use pub/sub for many collections, only a few which have very little data (if at all) and thus APM isn’t a tool that we need in general.
We like dd-trace because it integrates so well with all other datadog data like log events, but I can’t say that it’s essential so rather than staying behind on Meteor I guess we will just stop using it.
Alternatives like Monti are not worth setting up for us now (it was great and we used it before moving all things to Datadog), and Galaxy was never an option for various reasons.
Beta 3 is out! The major addition is removal of deprecated code from before Meteor 1.0 days in packages. Together with other changes this lead to major version bump on accounts-base , accounts-password and oauth . If you have packages that depend on these they will have to be updated to handle this major version bump.
You can update as usual using: meteor update --release 2.3-beta.3
But you might need to be a bit more permissive with your packages this time around: meteor update --allow-incompatible-update --all-packages --release 2.3-beta.3
Working on beta.4 right now to resolve any remaining issues with version conflicts. Packages that depend on accounts-base , accounts-password and oauth will need to update to allow for the major bump. Easiest approach would be to use api.versionsFrom(['2.2', '2.3']) (once 2.3 is released) or something along those lines. I will start preparing this for MCP packages this weekend so that we can release new versions that are compatible with 2.3 on the day of the release. We can have a release party…
Hello,
I am following your advise to try the 2.3-beta.5
meteor update --release 2.3-beta.5
leads to this :
Changes to your project's package version selections from updating the release:
accounts-base* upgraded from 1.9.0 to 2.0.0-beta230.5
accounts-password* upgraded from 1.7.1 to 2.0.0-beta230.5
alanning:roles* downgraded from 3.2.3 to 1.2.10
babel-compiler upgraded from 7.6.1 to 7.6.2-beta230.5
browser-policy added, version 1.1.0
browser-policy-common added, version 1.0.11
browser-policy-content added, version 1.1.1
browser-policy-framing added, version 1.1.0
cosmos:browserify removed from your project
ddp-client upgraded from 2.4.1 to 2.5.0-beta230.5
ddp-rate-limiter upgraded from 1.0.9 to 1.1.0-beta230.5
ddp-server upgraded from 2.3.3 to 2.4.0-beta230.5
deanius:promise* downgraded from 3.1.3 to 2.3.1
dynamic-import upgraded from 0.6.0 to 0.7.0-beta230.5
ecmascript upgraded from 0.15.1 to 0.15.2-beta230.5
email upgraded from 2.0.0 to 2.1.0-beta230.5
http removed from your project
launch-screen upgraded from 1.2.1 to 1.3.0-beta230.5
meteor-base upgraded from 1.4.0 to 1.5.0-beta230.5
meteortesting:browser-tests* downgraded from 1.3.4 to 0.2.0
meteortesting:mocha* downgraded from 2.0.1 to 0.5.1
meteortesting:mocha-core removed from your project
minimongo upgraded from 1.6.2 to 1.7.0-beta230.5
mizzao:timesync removed from your project
mizzao:user-status* downgraded from 1.0.0 to 0.5.0
mongo upgraded from 1.11.1 to 1.12.0-beta230.5
okgrow:promise added, version 0.9.0
practicalmeteor:mocha-core added, version 1.0.1
promise upgraded from 0.11.2 to 0.12.0-beta230.5
service-configuration upgraded from 1.0.11 to 1.1.0-beta230.5
socket-stream-client upgraded from 0.3.3 to 0.4.0-beta230.5
srp removed from your project
webapp upgraded from 1.10.1 to 1.11.0-beta230.5
* These packages have been updated to new versions that are not backwards
compatible.
rationalk: updated to Meteor 2.3-beta.5.
The downgrade is a bug that I’m trying to figure out. My guess right now is that it is downgrading to an old version that doesn’t have any version restrains (hence it is super old). I’m submitting PRs to all the packages that I see reported with this issue, for betas and rc the fix is to have them locally and fix the versioning there. After the release of 2.3 it will be up to the package maintainers to get their package dependencies into order.
Thanks for your work on this.
I think that after the release of 2.3 I will need to download locally all the packages you forked instead of using original ones. Especially for packages that are not updated anymore. Am I right ?
For those that are not maintained anymore yes. MCP packages will be up to date within hour after the release. From you list this for example includes mizzao:user-status and alanning:roles. For the rest of packages it will depend on the maintainers if they merge and publish my fixes.
This is why community feedback is so important, if some deprecation removals are affecting many packages we could post-pone them but we need feedback to make this decision
Meteor 2.3-beta.0 is out.
Thanks.