Feature request: Context hierarchy about browser-sdk HOT 6 CLOSED

The ability to remove global context key has been added to log in v1.15.0 and to rum in v1.20.0.

from browser-sdk.

The idea is similar to MDC (Mapped Diagnostic Context) in Java applications and it would be a nice addition!

from browser-sdk.

Hi @mboogerd!

About context

1. Incrementally add contextual information to my logging, as my code progresses.

Would the logger.addContext (key: string, value: any) suit this need?

2. Remove contextual information when I leave the context for which that data is relevant.

We don't have a specific API to remove specific key/value of the context but you should achieve this behavior by setting a key to undefined.

logger.addContext("foo", undefined)

Let me know if this approach could work for you or if I missed something on your use case.

About console.logs

3. Have console.log statements include the context

Yes, we don't automatically collect console.logs for now, there is an open issue to track this feature: #400

from browser-sdk.

Hi @bcaudan, thanks for your response!

I had not considered that setting a key's value to undefined would effectively clear it, but that makes absolute sense (facepalm moment) and does satisfy part of the need of clearing context. It narrows the difference between what I'm proposing and what is currently offered, but doesn't entirely nullify it. The difference is twofold, in part API convenience and in part preventing maintaining double state.

An example may help to clarify. Consider the following internal context-stack for an imaginary IRC clone:

[{app:my-chat-app, version: 1.0}, {module: chat, user:me}, {activeChannel: myTeamChannel}] might be a stack of partial contexts, individually pushed as you navigate the chat app. The effective total context is the merge of all partial ones, and is the one that would be included with log-messages dispatched from the context. (Of course, internally, you would memoize those merges, but that would make the example bulky)

Convenience

• Pushing an additional layer of context {module: chat, user: me} has a minor convenience benefit over issuing several statements, but
• Popping that layer when leaving the context is more convenient, because I no longer need to be aware of what keys were set, or have to be re-set.

Double state
With the method of clearing up key-value pairs by setting the value to undefined, this is only an issue when multiple levels of context reuse a key. Imagine a context such as [{ nav: admin}, {nav: admin/users}, {nav: admin/users/[user]}]. If I were to leave the context of the configuration of a single user, and return to the list of users, I would have to restore the previous nav: admin/users value in the context. I cannot query the logging context, so I would either:

• have to maintain this as a second bit of state such that this can be restored dynamically, or
• ensure that when I leave the context, a bit of code is triggered that statically knows which value to restore.

Either way, it feels like stuff you want to concern yourself with as little as possible on an application level. Although it is less pressing for me, now that I know you can at least remove part of the context, I do think that managing those contexts incrementally would offer a nice API for users of this library.

from browser-sdk.

Thanks for the details @mboogerd!

I had not considered that setting a key's value to undefined would effectively clear it, but that makes absolute sense

I did not encounter this kind of case before but we should either document this behavior or offer a dedicated API for it.

About the convenience of a single API for adding/removing a set of context key, I totally agree.

We would probably need to put more though on the API but we could have something like:

// single key
logger.addContext("foo", "bar")
logger.removeContext("foo")

// multiple keys
logger.addContext({app:my-chat-app, version: 1.0})
logger.removeContext({app:my-chat-app, version: 1.0})

It will probably not be in our top priorities, but feel free to open a PR for it if you want.

from browser-sdk.

We would probably need to put more though on the API but we could have something like:

// single key
logger.addContext("foo", "bar")
logger.removeContext("foo")

// multiple keys
logger.addContext({app:my-chat-app, version: 1.0})
logger.removeContext({app:my-chat-app, version: 1.0})

It will probably not be in our top priorities, but feel free to open a PR for it if you want.

This would be useful for projects that have used services like TrackJS in the past. TrackJS allows you to add metadata that can be removed when not needed anymore (https://docs.trackjs.com/browser-agent/sdk-reference/agent-methods/#removemetadata). This can be helpful when debugging errors that can be hard to reproduce or to have more context when a known error is triggered.
eg.

function errorHandler(statusBitmap, resourceId) {
    trackJs.addMetadata('statusBitmap', statusBitmap);
    trackJs.addMetadata('resourceId', resourceId);
    console.error('Failed to launch resource');
    trackJs.removeMetadata('statusBitmap');
    trackJs.removeMetadata('resourceId');
}

from browser-sdk.