feat: Support setting userId and sessionId manually

[aws-observability]

feat: Support setting userId and sessionId manually

[qhanam]

Hi @crowecawcaw thanks for this; I like your proposal. Would you ever dynamically change the sessionId, or would it be sufficient to set the session Id only on initializing AwsRum?

[crowecawcaw]

For our specific use case, we would only want to set the sessionId at initialization time.

[jffrenc]

For a different use case, we need to dynamically set both sessionId and userId:

We'd like to use RUM for a kiosk use case. In the idle state, no user is logged in. Users can authenticate, take some set of actions, and then log out. The page is never reloaded except after a deployment.

We'd like to have the RUM client initialized the entire time, capturing any errors, events, timings, etc. even when logged out (without associating those with the session/user before or after). We'd also like to set the userId and a new sessionId programmatically every time a user logs in (and reset them when they log out).

We'd like to avoid having to manage multiple instances of the RUM client and possibly lose events or get some other bad behavior because we didn't realize we had to call flush() and disable() (we haven't tested this route yet though, so might not even be correct - just trying to point out there's some danger in using multiple instances since most of the docs assume you'd only create one instance of the client) to destruct the previous instance before creating a new one to avoid duplicate or lost events.

[jakob-lj]

@jffrenc From our point of view: the session in AWS RUM is one user session, which may contain that the user is logged in via various users during that session. The session lifecycle might be:

• logged out
• logged into userId: A
• logged out
• logged into userId: B

Then we would like to catch errors in this lifecycle and put them in relation to each other. We use the metadata feature when adding our custom user identities, and like the fact that we can abstract away in such a matter ^

[williazz]

To summarize, we need the following to close out:

• Statically set user id at initialization time
• Statically set session id at initialization time

In addition, I have also received feedback for

• Dynamically set user id at runtime
• Dynamically set session id at runtime
• Dynamically start, stop, and get current session at runtime