🐛 Using "excludedActivityUrls" removes resources from view event in RUM

[konradkierus]

Describe the bug
I'm not sure if it's a bug or expected behaviour. I will understand if it's a feature request instead.

Our app, which is SPA, uses some "comet" techniques (that is, streaming or long polling) and we noticed such requests can affect loading time metric (view.loading_time) in RUM.
As described in the docs here loading time is calculated based on page activity.
Our plan was to use excludedActivityUrls to stop affecting views' loading time with "comet"-like requests.
The problem is that excludedActivityUrls removes also resource entries for such requests and they are no longer visible in VIEW event in RUM. It means there is no longer way to monitor these resources performance, for example, if/when request started, possible network errors, possible retries/reconnections and so on.

Expected behavior
Resources should be visible in RUM even if excludedActivityUrls is used.

[cy-moi]

Hi @konradkierus ,
Thank you for reaching out. As the docs described, page activities are calculated base on resource requests and excludedActivityUrls is a list of resources. Hence, resources match the url specified are expected to be excluded.

For us to better understand the case here, could you provide your specific config and the resources you want to include?

[konradkierus]

Hey @cy-moi ,
Thanks for the feedback!

We are using GraphQL over SSE (Server-Sent Events) to send some data from server to client (unidirectional communication).
Clients (Single Page Applications) subscribe for such events to get real time updates from server. The subscription can be initiated in various stages, sometimes also on view load, and can stay open as long as user is on the view. Sometimes connection can be lost and then resubscribed, even if user doesn't leave the screen.

Having ability to monitor such resources (as per https://docs.datadoghq.com/real_user_monitoring/browser/monitoring_resource_performance/ ) would be very useful as we treat SSE connections similar to other XHR or Fetch requests.
But, as I already pointed out, these resources affect view.loading_time metric which can be useful by its own.