✨ [RUM-10144] apply context defined just after init to events generated during init #3592
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
Motivation
Usually, context (global/user/account/feature flags etc.) is defined just after calling
RUM.init(), which is an issue because events that are generated duringinit()will not have this context.For now, this is only problematic for View events: RUM.init() generates a first View event that is missing the context defined right after. It is usually fine, as we can expect a RUM View Update to be generated at some point later. But sometimes no View Update happen for some reason (connectivity error, browser exiting abruptly...). In those cases, it is unexpected that the View isn't including the context.
This issue will be more pronounced when we'll start to collect errors that happen before init (in a future PR). In this case, we'll want the context to apply to those events (for example, to clearly identify which user was affected by such early error).
Changes
This PR fixes this issue by slightly delaying the events assembly. It uses a new data structure,
BufferedObservable, that will be used to progressively replace theBoundedBufferand what we call "pre start strategies". ThisBufferedObservableis asynchrone, so we leverage this fact to delay the assembly.Test instructions
In the sandbox, define a user just after
init():Using the devtools extension, look at individual View events by unchecking
Show only the latest View eventin the "Events" tab.When loading the sandbox URL, all View events should contain the
@usr.id, even the very first View.Checklist