Transitioning ActivityId Traceability from iTwinJs Deprecated Package to latest iTwinJs

[babarirshad]

In our product, we have been utilizing the @bentley/imodeljs-frontend package (version ~2.19.50) to display ActivityId for frontend client requests. This feature has been integral to error traceability and debugging on the deployed version of product. The previous implementation was as follows:

import { AuthorizedFrontendRequestContext } from "@bentley/imodeljs-frontend";
AuthorizedFrontendRequestContext.current.activityId;

However, with the transition to the latest iTwin.js framework, the @bentley/imodeljs-frontend package has been removed or renamed, and the AuthorizedFrontendRequestContext functionality is no longer provided for frontend use. The change details can be found [here](https://www.itwinjs.org/changehistory/3.0.0#clientrequestcontext-and-authorizedclientrequestcontext-have-been-removed).

In the latest iTwin.js versions, ActivityId is no longer directly accessible from the frontend. Instead:

• ActivityId is available in the @itwin/core-backend package, where it can be accessed through the RpcTrace class. Documentation is available here.
• The ActivityId is now assigned to the X-Correlation-ID HTTP header in frontend requests, as detailed in this guide: [Logging and ActivityIds](https://www.itwinjs.org/learning/rpcinterface/#logging-and-activityids).

Currently, the frontend does not expose this ActivityId directly. For enhanced error traceability and debugging, exposing this value in the frontend package would allow us to maintain the same level of error tracing capabilities without relying on outdated versions of the framework.

Proposed Approach

To align with the latest iTwin.js framework while retaining error traceability:

1. Expose ActivityId in Frontend: Update the frontend package to access the ActivityId assigned to the X-Correlation-ID header in HTTP requests. This will enable us to continue displaying it in the frontend for better debugging.

This approach will future-proof our implementation while enhancing error traceability and maintaining alignment with the latest framework standards.

[tcobbs-bentley]

AuthorizedClientRequestContext was removed to substantially improve the experience of sending messages to the backend. As such, it is not coming back, nor will any replacement. The fact that ActivityId was used for purposes other than logging was unexpected. Additionally, the plan for the future is to entirely remove the RPC system in favor of a REST-based system.

The ActivityId value was never intended to be shown to the end user like you are doing. We would strongly recommend that you stop doing that. However, if showing the value is absolutely critical to the functioning of your application, we will investigate how it might be surfaced.

[babarirshad]

Thank you for your detailed response and for clarifying the rationale behind the removal of AuthorizedClientRequestContext and the transition towards a REST-based system.

We understand that the ActivityId was not originally intended for purposes other than logging. However, the ability to surface the ActivityId in the frontend has been critical for our product, particularly for error traceability and debugging in deployed environments. It has allowed us to quickly identify, isolate, and resolve issues based on client requests, which significantly enhances our ability to support users efficiently.

Could you suggest what should we show to users in case if they get some errors on frontend ? and how do we get useful information from seq logs that usually we do get based on ActivityIds?

[tcobbs-bentley]

I will investigate to try to determine if there is a way to get at the data in X-Correlation-ID.