Can we set a sessionStorage size limit so that other usages of session storage does not run in QuotaExceededError?

[thoo1]

Is your feature request related to a problem? Please describe.

• our application is using both this library and msal-browser (https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser).
• msal-browser uses session storage to store some intermediate state during its auth flow
• we see in our app, that we are running into QuotaExceededErrors
• which are thrown when we try to use session or local storage and it is already storing a lot of items

Describe the solution you'd like

• I like the feature that application insights js has to stored the unsent telemetry in session storage - it makes log loss less likely
• I'm not sure what to do here but it'd be nice to set a limit on the size of items being stored so we can leave some space for other usages of session storage

Describe alternatives you've considered

• we are thinking of just turning off the session storage usage enableSessionStorageBuffer: false

Additional context current config

      config: {
        instrumentationKey: Environment.config.appInsightsInstrumentationKey,
        endpointUrl: Environment.config.appInsightsEndpointUrl,
        extensions: [this.reactPlugin],
        extensionConfig: {
          [this.reactPlugin.identifier]: { history }
        },
        disableFetchTracking: false,
        disableAjaxTracking: false,
        enableCorsCorrelation: true,
        disableCorrelationHeaders: false,
        enableAutoRouteTracking: true,
        maxAjaxCallsPerView: -1,
        enableResponseHeaderTracking: true,
      }

[thoo1]

also related question, if we do not set a value in our config for onunloadDisableBeacon (and this config is by default false), does this mean that on unload, this package will try to use beacon api to send the unsent telemetry? If so, does this mean that we dont need to use the sessionStorageBuffer, as it is already being sent using beacon api?

[thoo1]

I found the answer to my last question, if you don't set onunloadDisableBeacon: false, it will use xhr on unload to flush the telemetry. I'm guessing this could fail or be interrupted? And that is why the session storage is needed to store the unsent telemetry?

I guess my question is, does using beacon api on unloading make it more probable to flush the telemetry successfully? edit: this article seems to say that synchronous xhr is being disallowed in unload https://web.dev/disallow-synchronous-xhr/

[MSNev]

Currently, there is a hard coded limit on the "number" of events that are temporarily stored in the session storage (of 2000), we could extend this logic to support the serialized "size" of event -- but that's not a small amount of work and is likely to take a while before anyone internal can look at.

On the alternative, You can already disable all session (and local) storage usage

via config it's

• isStorageUseDisabled: true

And manually (globally) by the SDK helper using either of the following

• Utils.disableStorage()
• utlDisableStorage() (better Tree-Shaking version)

[thoo1]

Thanks @MSNev for the suggestion! I have one more question, I noticed that by default on unload, it'll use beacon api. There is a line here to check if the request has been queued or not https://github.com/microsoft/ApplicationInsights-JS/blob/22d3787cb9b328bbf3cab0ee38a686d4779f8031/channels/applicationinsights-channel-js/src/Sender.ts#L582

Do you happen to know when this can return false? I was thinking, if this always returns true, our application can turn off the usage of session storage without losing telemetry between page lifetimes. I couldn't find much documentation online so I figured I'd ask you

Thanks!

[MSNev]

This generally happens if the payload is too large and the browser doesn't want to accept, the size is browser specific -- 64Kb is the typical size. Generally, unless you have REALLY large events or LOTS of events you should not hit this issue

[thoo1]

I see.. I think our application's events are huge, I just took an example and I found the buffer had 200kB of events.. we'll try to dig into why theres so much data here, thanks!

[thoo1]

and just as a follow up, it looks like there is a fallback to use XMLHttpRequest to send the request (I assume theres no size limit here right?). It is also doing this async since synchronous XMLHttpRequest is deprecated (per: https://web.dev/disallow-synchronous-xhr/), does this mean that async XMLHttpRequests in beforeunload can be unsuccessful (as in the request did not go out)?

[MSNev]

Correct, depending on the browser (and version) it may cancel, abort or ignore XHR sync requests during the page unload sequence.

[WenyunZou]

Hi @MSNev, We are having the same problem here. In some user sessions, "AI_sentBuffer" takes nearly 10Mb, leaving no space for other libs. As a result, users cannot get tokens by the msal lib. What is the possible reason for AI_sentBuffer being so large? Is there a workaround without disabling the use of session storage? Thanks.

[MSNev]

This would mean that you have a large number of LARGE events that have been sent to the backend, but we (the SDK) has not received a response for, so we keep it in session storage so that on the next page load (SDK initialization) we attempt to "re-send" the unacknowledged events from the previous events.

@Karlie-777, @siyuniu-ms can you please work with @WenyunZou to determine the excessive size of the event buffer and make sure that there is no issues around response (status codes) causing the events to remain in the session storage.

[Karlie-777]

hi @WenyunZou which version of Application Insights SDK you are using? and do you mind sharing your configs as well? and does this issue only happen recently? and does this issue happen to your most end users or only apply to specific users?

[xysu2024]

@Karlie-777 The version of Application Insights SDK is 2.7.4. Our config is:

config: {
    "instrumentationKey": window.appInsightsInstrumentationKey,
    "endpointUrl": window.appInsightsEndpointUrl,
    "connectionString": window.appInsightsConnectionString
    "disableAjaxTracking": true,
    "disableExceptionTracking": true,
}

Other properties in the config are the default value.