feat: Add basic logging support for browser-telemetry. #736
Conversation
|
@launchdarkly/js-sdk-common size report |
|
@launchdarkly/js-client-sdk-common size report |
|
@launchdarkly/js-client-sdk size report |
|
|
||
| private _setLogger() { | ||
| this._logger = | ||
| this._options.logger ?? ((this._client as any)?.logger as MinLogger) ?? fallbackLogger; |
There was a problem hiding this comment.
So, basically in the 4.x SDK there is a logger property, but in 3.x there is not.
Additionally error monitoring should always be initialized as early as possible, which is before the SDK (there are also some inter-dependencies that require this order). As a result we need some intermediate logging.
| this._pendingEvents.push({ type, data: event }); | ||
| if (this._pendingEvents.length > this._maxPendingEvents) { | ||
| // TODO: Log when pending events must be dropped. (SDK-915) | ||
| if (!this._eventsDropped) { |
There was a problem hiding this comment.
Generally whenever a max is hit it will be hit many times. This will just log once to avoid creating log spam. This situation will generally represent misconfiguration where the client is not being registered.
Or something terribly wrong in the users application.
| return breadcrumb === undefined ? undefined : filter(breadcrumb); | ||
| } | ||
|
|
||
| function applyBreadcrumbFilters( |
There was a problem hiding this comment.
This moved to be a private member of the BrowserTelemetryImpl for access to a logger.
| breadcrumb, | ||
| ); | ||
| } catch (e) { | ||
| if (!this._breadcrumbFilterError) { |
There was a problem hiding this comment.
If the filter was wrong once, then it will likely remain wrong, so we don't want to log spam in that situation.
packages/telemetry/browser-telemetry/src/BrowserTelemetryImpl.ts
Outdated
Show resolved
Hide resolved
🤖 I have created a release *beep* *boop* --- <details><summary>browser-telemetry: 0.1.0</summary> ## [0.1.0](browser-telemetry-v0.0.9...browser-telemetry-v0.1.0) (2025-01-22) ### ⚠ BREAKING CHANGES * Updated AI config interface. ([#697](#697)) ### Features * Add basic logging support for browser-telemetry. ([#736](#736)) ([2ef1486](2ef1486)) * Add browser telemetry options. ([#675](#675)) ([c8352b2](c8352b2)) * Add browser-telemetry API types. ([#669](#669)) ([89967ee](89967ee)) * Add DOM collectors. ([#672](#672)) ([4473a06](4473a06)) * Add http collectors. ([#673](#673)) ([6e60ddc](6e60ddc)) * Add singleton support for browser-telemetry. ([#739](#739)) ([68a3b87](68a3b87)) * Add stack trace parsing. ([#676](#676)) ([ca1dd49](ca1dd49)) * Add support for breadcrumb filtering. ([#733](#733)) ([5c327a1](5c327a1)) * Add support for the session init event. ([320c07d](320c07d)) * Add the ability to filter errors. ([#743](#743)) ([5cffb2b](5cffb2b)) * Export browser-telemetry initialization method. ([d1b364e](d1b364e)) * Implement browser telemetry client. ([#691](#691)) ([db74a99](db74a99)) * Make browser-telemetry specific inspector type. ([#741](#741)) ([14ecdb3](14ecdb3)) * Random uuid for telemetry package. ([#689](#689)) ([4cf34f9](4cf34f9)) * Rename initializeTelemetryInstance to initTelemetryInstance for consistency with initTelemetry. ([257734f](257734f)) * Source maps with inline sources for browser-telemetry. ([#735](#735)) ([1656a85](1656a85)) * Updated AI config interface. ([#697](#697)) ([cd72ea8](cd72ea8)) * Vendor TraceKit ([d1b364e](d1b364e)) ### Bug Fixes * Clear pending events buffer when registered. ([#727](#727)) ([b6ad7df](b6ad7df)) * Export BrowserTelemetry, BrowserTelemetryInspector, and ImplementsCrumb. ([257734f](257734f)) * Fix breadcrumb filter option parsing. ([#742](#742)) ([833f4ce](833f4ce)) * Remove BrowserTelemetry until more types are available. ([#671](#671)) ([796b8a3](796b8a3)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Adds the ability to specify a logger and to also use the base SDK logger when possible. The base SDK of a 3.x version does not expose the logger, but 4.x will.
There is a minimal replication of the warning level of the logging interface to allow compatibility with both the 3.x SDK and the 4.x SDK.
Prefixing is done at message time instead of as part of the logger. Potentially it could be ideal to do it in the logger, but this approach makes it clear that the interpolation supported by most browser loggers will not come into play. (Where if the logger does this prefixing it is either complex or you lose the sprintf style formatting support.)
Some earlier log messages has been added, but a logger instance was not yet available.