Skip to content
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

fix(resources): wait for async attributes for detecting resources #4687

Merged
merged 5 commits into from
Oct 11, 2024

Conversation

ziolekjj
Copy link
Contributor

@ziolekjj ziolekjj commented May 8, 2024

Which problem is this PR solving?

Recently, HostDetector was added as default for detectors in NodeSDK, this produces the error message: Accessing resource attributes before async attributes settled, as detectResourcesSync is not waiting for async attributes to be resolved for HostDetector, what causes the lack of machine_id passed to it.

Fixes #4638

Short description of the changes

I've updated the test case for the issue and added an await statement to wait for async attributes to be resolved for the detectResourcesSync function.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I've added unit tests, the configuration for reproducing is described in the linked issue #4638

  • Updated a test to detect-resources.test.ts to reflect the behavior of the HostDetector with async attributes

Copy link

linux-foundation-easycla bot commented May 8, 2024

CLA Signed

The committers listed above are authorized under a signed CLA.

@ziolekjj ziolekjj changed the title fix(opentelemetry-resources): wait for async attributes for detecting resources fix(resources): wait for async attributes for detecting resources May 8, 2024
@ziolekjj ziolekjj force-pushed the resources-async branch from 20f2799 to a7044f3 Compare May 8, 2024 17:23
@ziolekjj ziolekjj marked this pull request as ready for review May 8, 2024 17:23
@ziolekjj ziolekjj requested a review from a team May 8, 2024 17:23
Copy link

@MichalZalecki MichalZalecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tested the change locally. It solved the issue, the message is not logged and host.id is present on spans 👌

@ziolekjj
Copy link
Contributor Author

ziolekjj commented Jul 1, 2024

Hey @pichlermarc, sorry for mentioning you; I'm not sure who would be the best person to ask for a review here, It still requires a code owner approval, is everything good here? I am happy to help with pushing this forward

Copy link

github-actions bot commented Sep 9, 2024

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Sep 9, 2024
@github-actions github-actions bot removed the stale label Sep 23, 2024
@vNNi
Copy link

vNNi commented Sep 25, 2024

any update for this MR?

today i'm using this workaround: #4638 (comment)

but after the merge of this change, i would like to remove them.

@david-luna david-luna requested a review from a team as a code owner October 3, 2024 15:31
Copy link

codecov bot commented Oct 3, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.27%. Comparing base (859c0ef) to head (c64eee7).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4687      +/-   ##
==========================================
+ Coverage   93.26%   93.27%   +0.01%     
==========================================
  Files         317      317              
  Lines        8194     8195       +1     
  Branches     1640     1641       +1     
==========================================
+ Hits         7642     7644       +2     
+ Misses        552      551       -1     
Files with missing lines Coverage Δ
...es/opentelemetry-resources/src/detect-resources.ts 65.30% <100.00%> (+0.72%) ⬆️

... and 1 file with indirect coverage changes

@david-luna david-luna added this pull request to the merge queue Oct 3, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Oct 3, 2024
@david-luna
Copy link
Contributor

david-luna commented Oct 11, 2024

Failure on @opentelemetry/shim-opentracing tests which seems unrelated
ref: https://github.com/open-telemetry/opentelemetry-js/actions/runs/11258351446/job/31405500619?pr=4687

 1 failing

  1) OpenTracing Shim
       TracerShim
         starting spans
           translates span options correctly:

      AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

+ 1728646076298.6538
- 1728646076298.6536
                   ^
      + expected - actual

      -1728646076298.6538
      +1728646076298.6536
      
      at Context.<anonymous> (test/Shim.test.ts:266:16)
      at processImmediate (node:internal/timers:483:21)

@david-luna david-luna added this pull request to the merge queue Oct 11, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Oct 11, 2024
@david-luna david-luna added this pull request to the merge queue Oct 11, 2024
Merged via the queue into open-telemetry:main with commit 6be903a Oct 11, 2024
21 checks passed
Annosha pushed a commit to Annosha/opentelemetry-js that referenced this pull request Oct 19, 2024
pxaws added a commit to aws-observability/aws-otel-js-instrumentation that referenced this pull request Oct 30, 2024
*Issue #, if available:*

*Description of changes:*

Due to a
[bug](open-telemetry/opentelemetry-js#4687) in
upstream, the `detectResourcesSync` doesn't wait for the async
attributes. This happens if we use the async version of some resource
detector. The
[fix](open-telemetry/opentelemetry-js#4687) is
in another upstream release. We don't want to upgrade the upstream
version for now. To avoid this issue, we switch to the sync version of
the detectors and this should have no impact for the functionalities (as
`detectResourcesSync` waits for all async detectors anyway and works for
both sync and async detectors). In the future, even if we upgrade
upstream version, we don't need to switch back to async detectors.


By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

How to handle "Accessing resource attributes before async attributes settled" errors
5 participants