chore(deps): bump @opentelemetry/instrumentation from 0.53.0 to 0.54.2

[dependabot]

Bumps @opentelemetry/instrumentation from 0.53.0 to 0.54.2.

Release notes

Sourced from @​opentelemetry/instrumentation's releases.

experimental/v0.54.2

0.54.2

🐛 (Bug Fix)

• fix(instrumentation): Fix wrapping ESM files with absolute path #5094 @​serkan-ozal

experimental/v0.54.1

0.54.1

🐛 (Bug Fix)

• fix(instrumentation-http): skip malformed forwarded headers. #5095 @​pmlanger

experimental/v0.54.0

0.54.0

💥 Breaking Change

• feat(exporter--otlp-)!: rewrite exporter config logic for testability #4971 @​pichlermarc
  • (user-facing) getDefaultUrl was intended for internal use has been removed from all exporters
  • (user-facing) getUrlFromConfig was intended for internal use and has been removed from all exporters
  • (user-facing) hostname was intended for internal use and has been removed from all exporters
  • (user-facing) url was intended for internal use and has been removed from all exporters
  • (user-facing) timeoutMillis was intended for internal use and has been removed from all exporters
  • (user-facing) onInit was intended for internal use and has been removed from all exporters
• feat(otlp-exporter-base)!: do not export functions that are intended for internal use #4971 @​pichlermarc
  • Drops the following functions and types that were intended for internal use from the package exports:
    • parseHeaders
    • appendResourcePathToUrl
    • appendResourcePathToUrlIfNeeded
    • configureExporterTimeout
    • invalidTimeout
• feat(instrumentation-http)!: remove long deprecated options #5085 @​pichlermarc
  • ignoreIncomingPaths has been removed, use the more versatile ignoreIncomingRequestHook instead.
  • ignoreOutgoingUrls has been removed, use the more versatile ignoreOutgoingRequestHook instead.
  • isIgnored utility function was intended for internal use and has been removed without replacement.

🚀 (Enhancement)

• feat(api-logs): Add delegating no-op logger provider #4861 @​hectorhdzg
• feat(instrumentation-http): Add support for Semantic Conventions 1.27+ #4940 #4978 #5026 @​dyladan
  • Applies to client and server spans and metrics
  • Generate spans and metrics compliant with Semantic Conventions 1.27+ when OTEL_SEMCONV_STABILITY_OPT_IN contains http or http/dup
  • Generate spans and metrics backwards compatible with previous attributes when OTEL_SEMCONV_STABILITY_OPT_IN contains http/dup or DOES NOT contain http

🐛 (Bug Fix)

• fix(sampler-jaeger-remote): fixes an issue where package could emit unhandled promise rejections @​Just-Sieb
• fix(otlp-grpc-exporter-base): default compression to 'none' if env vars OTEL_EXPORTER_OTLP_TRACES_COMPRESSION and OTEL_EXPORTER_OTLP_COMPRESSION are falsy @​sjvans

... (truncated)

Commits

• 72c9af9 chore: prepare next release (#5120)
• fe4d368 Fix wrapping ESM files with absolute path (#5094)
• 6f4f3fc chore: prepare next release (#5115)
• 33dbde1 add reset function test for InMemorySpanExporter (#5107)
• 67d7718 fix(instrumentation-http): skip malformed forwarded headers (#5099)
• ce5bbfb chore(deps): update node.js to v22 (#5109)
• 4c0921e docs: update releasing.md to mention npm publish workflow, fix a link to rele...
• 2b73d37 [Fixes # 4533] Replaced cpx2 with local test module (#5077)
• eb3ca4f chore: prepare next release (#5068)
• 6fee82d chore: add @​maryliag to approvers (#5083)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[saidsef]

/code pr

[saidsef]

🤖
In the provided patch for upgrading @opentelemetry/instrumentation from version 0.53.0 to 0.54.2:

1. package-lock.json: The dependency tree in this file under node_modules/@opentelemetry/instrumentation was updated from version 0.53.0 to 0.54.2. Additionally, versions for other dependencies that are linked to @opentelemetry/instrumentation also got updated.

2. package.json: The @opentelemetry/instrumentation version under the 'dependencies' in package.json got updated from "^0.53.0" (meaning any version 0.53.0 and above) to "^0.54.2". This change does not affect installed packages; it just mentions which version will now be installed when running npm install or including the project as a dependency in a new project.

Reviewing the updated code:

• As this is a minor version upgrade, chances of breaking changes are very low. While reviewing the commits, it appears that all direct dependencies are also being updated (such as @opentelemetry/api-logs) which extends to indirect dependencies common in other packages using @opentelemetry/instrumentation.

• This package is built off the OpenTelemetry ecosystem and is used in various npm packages for telemetry, e.g., tracing. The maintainers may consider further repercussions due to changes in newer versions of instrumentations due to either bug fixes, features, or breaking changes.

• Version-specific recommendations for code changes:

  • If you're using specific features or methods from the package's API, they might need to be reviewed and probably updated based on the newer version's API.

  • Check for possible deprecated methods and functions that should be migrated or replaced.

  • It's crucial to review and run tests to ensure that no functionality is broken after migration or updated installation.

• Afterward, you might want to leverage dedicated machines or CI/CD pipelines to perform automated testing across different environments to validate the compatibility and performance of the updated instrumentation.

Simply replace the current installation on your local development machine and follow similar steps as you would to update any other npm dependency. Your team should also consider conducting thorough integration tests and code reviews to be extra sure that the upgrade does not introduce new unexpected behavior or breaking changes in your application. Provide documentation of how your application handles tracing using the new version so that you can easier verify changes when needed.

As an alternative, you might want to run SonarQube or similar to get automated feedback on potential issues like bugs, code smells, style violations, vulnerabilities, etc., before the actual migration.

Please keep the semver principles in mind while considering if to accept or refuse the auto-changelog message. The semver version in the package.json and semantic versions of all dependencies may need to be adjusted accordingly if your 'patch' updates introduces any incompatible changes.

It's also recommended to create a feature branch or similar, make the necessary changes, verify them in a staging environment, and then merge them all in one go before deploying to production, giving yourselves a better chance of identifying potential issues and ensuring a smooth and uninterrupted launch. Make sure all changes you are making are properly commented and that your code changes are adequately tested and documented where necessary. Consider using pair programming or seek feedback from others when working on this task. Be sure to document your process and any assumptions you have made to prevent misunderstandings in the future.

Remember, updating packages should always be done while ensuring that the application remains compatible with the existing setup and architecture to reduce disruption. If specific parts of your application were based on the older version, extra care must be allocated to adapt and maintain that code while transitioning to the new version.

Following these steps will generally help to mitigate potential issues and make the process a bit less risky. After resolving any merge conflicts possible in your project, "npm install" seguid by "npm run build" to rebuild the project post the changes and finally "npm test" to run the tests before pushing the changes.

Remember to always have proper backups when working directly with version control systems such as git as an important precaution. Be sure to verify the cleanup of node_modules and package-lock.json before final commits to avoid any mishaps. Never push failed or untested changes to production level environments.

In peaceful times, consider making incremental changes and staggering your deployments to avoid chaos or disruptions. In times of uncertainty, risk and stress, consider bringing in experts or staggered deployment strategies. Stick to feasible plans and seek advice early on to ensure everything is settled before your project takes a hit. Understand the importance of dependency updates, and prioritize critical projects accordingly.

_{> HuggingFaceH4/starchat2-15b-v0.1 [pr | 0]}