Include the framework version with the report metadata #93
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Judoscale.registerAdapter('judoscale-node', null, { | ||
| adapter_version: packageInfo.version, | ||
| language_version: process.version, | ||
| }) |
Member
Author
There was a problem hiding this comment.
Register node-core so we can report its version as well as the node version.
There's a bit of an inconsistency between Ruby/Node & Python here, in that Python only reports platform_version for everything, while Ruby/Node use language_version vs framework_version. I think that's something we should consider to make consistent across the board eventually.
Member
Author
There was a problem hiding this comment.
I kinda like language_version & framework_version, but maybe we don't need that differentiation and can just make it like python does, because we know the version from the core packages represent the language and from the other specific packages it's the framework.
Member
Author
There was a problem hiding this comment.
adamlogic
approved these changes
Feb 4, 2026
| Judoscale.registerAdapter('judoscale-node', null, { | ||
| adapter_version: packageInfo.version, | ||
| language_version: process.version, | ||
| }) |
This will report the fastify/express/bull/bullmq version they're using with each report, so we can more easily troubleshoot things if necessary and also verify version support on our side. This matches the behavior of Ruby/Python packages as well.
This allows us to report its adapter version & node version so we can keep track of versions supported, and it can aid troubleshooting. We need to make sure we skip trying to collect metrics from it though since there's no collector, so the report code was changed slightly to accommodate for that, and tests as well which were relying on the first registered adapter being the one they were testing against (which is no longer true.)
carlosantoniodasilva
force-pushed
the
ca-report-versions
branch
from
d4650e8 to
c6ef8cc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This will report the fastify/express/bull/bullmq version they're using with each report, as well as registering node-core as an adapter without a collector to report its version & node version, so we can more easily troubleshoot things if necessary and also verify version support on our side.
This matches the behavior of Ruby/Python packages as well.