VastParser#trackErrorEvent() mutates DEFAULT_EVENT_DATA

[Matt Seeley]

Hi DM humans 👋:)

Reading through the source I found the following usage of Object.assign:

vast-client-js/src/parser/vast_parser.js

Lines 80 to 86 in 19223a0

 trackVastError(urlTemplates, errorCode, ...data) { 
   this.emit( 
     'VAST-error', 
     Object.assign(DEFAULT_EVENT_DATA, errorCode, ...data) 
   ); 
   util.track(urlTemplates, errorCode); 
 } 

Object.assign will transform then return the first argument, in this case DEFAULT_EVENT_DATA.

The current approach is only safe if the data argument has a fixed interface. Usages of trackErrorEvent in the parser provider different data shapes. So, if trackErrorEvent is called twice then the second call can contain data from the first call. It may not be typical for a parser to emit multiple errors but it looks like a parser instance can be long lived and asked to parse multiple vastXml objects.

Anyway, easy fix is to provider an empty object as the first param Object.assign({}, ... or shift to a spread syntax.

The same behavior is also present in VastClient:

vast-client-js/src/vast_client.js

Line 95 in 707e854

 options = Object.assign(this.defaultOptions, options); 

I think it would be unexpected for get(url, optionsA) to change this.defaultOptions such that get(url, optionsB) winds up using a mix of defaultOptions, optionsA, and optionsB.

[Matt Seeley]

If it's helpful, here's a CodePen that demonstrates the underlying issue.

[Sara Jegorova]

Hi, you're definitely right, we are mutating DEFAULT_EVENT_DATA and this.defaultOptions. Using spread syntax would be quite alright as a fix. Would you be interested in contributing to our amazing vast-client? If so, please follow our contributing guidelines. Great job in spotting this :)

[Matt Seeley]

Hi @kobawan, sure thing. I'm happy to.