Yes, the sampling applies to the whole session, and sampleRate impact all events (resourceSampleRate impact only resource events).

Just a headsup, Web Vitals will soon be available out-of-the-box in RUM. Stay tuned.

Hey @Tony-Proum I've been playing around with this some more and wanted to follow up. As mentioned in my previous note, I think there may be multiple issues at play here, and I want to ensure we can provide a solution while avoiding introducing any other edge cases or complexities.

I do have reservations around adding "forceNew" to additional places, if its indeed the only viable option, it's something we can definitely add, but I think it should be one of the later solutions attempted. There have been edge cases in the past, where forceNew was triggered in error on the monitor resource (for example when switching between metric and query types) that caused users to lose monitor history unnecessarily.

I've been looking into this and testing with the config you provided. As you noted, there is a link both between Monitors and the SLO, and between the SLO and Dashboards. Both monitor and slo have a force flag at the api layer that was introduced to allow this to be bypassed. (This is available today in the Go client, but its not yet in terraform for the SLO resource - https://github.com/DataDog/datadog-api-client-go/blob/master/api/v1/datadog/api_service_level_objectives.go#L367)

To propose an alternative, would having the force flag available in terraform on the SLO resource also address your workflow? The steps there would be to apply the force = true field to the monitor and slo resource prior to changes if you're comfortable with deleting a monitor/slo thats used somewhere. Let me know what you think, and I appreciate you working to get this issue resolved!

@bcaudan Follow up question - if our RUM config has { ..., resourceSampleRate: 5, sampleRate: 5 } will calls to addUserAction also be sampled at that same rate? Or will we track actions for all users where that code runs?

See DataDog/datadog-api-spec#692

See DataDog/datadog-api-spec#692

Codecov Report

Merging #592 (c686384) into master (b79ab78) will increase coverage by 0.00%. The diff coverage is 66.66%.

Codecov Report

Merging #553 (00acdd7) into master (c7be9aa) will decrease coverage by 0.03%. The diff coverage is 60.00%.

Motivation

Not trace cancelled requests because they lack backend information.

Changes

Set request.traceId to undefined if the request was cancelled.

Testing

Added unit tests to ensure that traceId is removed from the LifeCycleEventType.REQUEST_COMPLETED event when the request.status == 0.

I have gone over the contributing documentation.

<samp> Azure Pipelines successfully started running 1 pipeline(s).<br>

</samp>

/azp run

<samp> Azure Pipelines successfully started running 1 pipeline(s).<br>

</samp>

/azp run

<!-- ** Requirements for Contributing to this repository **

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue at the time.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING. -->

What does this PR do?

<!--

What inspired you to submit this pull request? Link to the issue describing the bug that you're fixing.

If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request. Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug.

We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.

-->

Additional Notes

<!-- Anything else we should know when reviewing? -->

Review checklist

Please check relevant items below:

• [ ] This PR includes all newly recorded cassettes for any modified tests.

• [ ] This PR does not rely on API client schema changes.

  • [ ] The CI should be fully passing.

• [ ] Or, this PR relies on API schema changes and this is a Draft PR that includes tests.

  • Note: CI shouldn't be run on this Draft PR, as its expected to fail without the corresponding schema changes.

See DataDog/datadog-api-spec#692

<!-- ** Requirements for Contributing to this repository **

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING. -->

What does this PR do?

<!--

What inspired you to submit this pull request? Link to the issue describing the bug that you're fixing.

If there is not yet an issue for your bug, please open a new issue and then link to that issue in your pull request. Note: In some cases, one person's "bug" is another person's "feature." If the pull request does not address an existing issue with the "bug" label, the maintainers have the final say on whether the current behavior is a bug.

We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the code here recently, so please walk us through the concepts.

-->

Additional Notes

<!-- Anything else we should know when reviewing? -->

Review checklist

Please check relevant items below:

• [ ] This PR includes all newly recorded cassettes for any modified tests.

• [ ] This PR does not rely on API client schema changes.

  • [ ] The CI should be fully passing.

• [ ] Or, this PR relies on API schema changes and this is a Draft PR to include tests for that new functionality.

  • Note: CI shouldn't be run on this Draft PR, as its expected to fail without the corresponding schema changes.

See DataDog/datadog-api-spec#692