[BUG] trackTrace with ICustomProperties does not allow numeric values

[mrobst]

trafficstars

I'm using applicationinsights-web with an Angular application. When logging a trace message using a custom properties object, any values which are not strings are ignored (with no error message). If I intercept the properties object and convert the values to strings then all the values are logged as expected. As far as I understand the index signature { key: string]: any } should allow numeric values to be logged?

Example of logging code with the workaround in place:

logTrace(
    message: string,
    severityLevel: SeverityLevel,
    properties?: { [key: string]: any }
  ) {
    // convert the properties object into keys with only string values
    Object.keys(properties).forEach(k => { properties[k] = properties[k].toString() })

    this.appInsights.trackTrace(
      { message: message, severityLevel: severityLevel },
      properties
    );
  }

Steps to Reproduce

• Windows/Chrome
• "@microsoft/applicationinsights-web": "^2.7.0"
• SDK initialised like this:

this.appInsights = new ApplicationInsights({
    config: {
      connectionString: config.connectionStringAI,
      enableAutoRouteTracking: true,
      disableFetchTracking: false, 
      enableUnhandledPromiseRejectionTracking: true, 
    },
  });
  this.appInsights.loadAppInsights();
  this.appInsights.addTelemetryInitializer((envelope) => {
    envelope.data.appVersion = environment.appVersion;
    envelope.tags['ai.cloud.role'] = 'IonicAngularApp'; 
  });

Issues #1737 and #1057 may be related?

Expected behavior Numeric or boolean or other types should be logged against object keys (strings) in object with type ICustomProperties

[MSNev]

I believe the issue with #1737 was that there where 2 instances of the SDK getting loaded which actually ended up using different definitions of the trackTrace implmentation (v1 for backward compatibility signature and v2 with the custom properties).

And #1057 looks like it was related to another signature issue where the arguments being passed down where incorrect and they got lost.

I had a quick look at the code and it "looks" like it should be working as when serializing the map it checks for a toString method and will call it.

I'll need to create a test using you example above, but is it possible for you to supply some simplified input / outputs in the meantime as it might be a little bit before I get some cycles to dig deeper (create a repro and debug into it).

We do have some logging that might also shine some light into whats going on, but they will be mostly silent by default.

Can you try these to see if they help identify

• enable the logging by setting the enableDebugExceptions to true (will throw an exception on error)
• set the loggingLevelConsole to 2 (Warning)
• Try using the new chrome extension which exposes some of the internal debug logging
• Try using the original "inline" debug plugin (for debug / local debugging only) which also directly exposes the internal workings (this will be refactored at some point to display more like the chrome-extension)

[mrobst]

Hi, I've enabled the logging via enableDebugExceptions: true and set the loggingLevelConsole to 2 but I don't get any additional info in the console. I've also installed the chrome extension but I don't see very much in here with the default configuration.

For testing I used this call:

 this.appInsights.trackTrace(
      { message: 'Test data types', severityLevel: SeverityLevel.Verbose },
      {
        string: 'Test',
        number: 123,
        numberAsString: '123',
        bool: false,
      }
    );

Once the trace is available in application insights it shows this in the custom properties without the "number" property:

(I'm adding the app version as a telemetry initializer in envelope.data.appVersion.

Hope this helps to look into it further?

thanks Marcus

[baxxos]

The properties interface is defined in a way that allows us to pass in any kind of value - e.g. a deeply nested object, but from my experience, it only works reliably with strings. More complex values will either get flattened, stringified or ignored altogether.

Example:

appInsights?.trackTrace({
  message,
  severityLevel: SeverityLevel.Information,
  properties: {
    level1: { level2: { level3: 'level3value' } },
  },
})

results in:

It would be nice to define the ICustomProperties in a way that would reflect only the supported data types or describe the value processing behavior in documentation.

[MSNev]

@Karlie-777 can you please investigate this a bit further (create a repro and a unit test for the issue and then address any issues).

For reference get flattened, stringified or ignored altogether. is the design but the ignored should be causing some logging / failures (for exceptions), this may only currently be documented in the code so we should add this somewhere more visible as per @baxxos suggestion.

I don't think we want to change the ICustomProperties to be specific as I'm aware of several internal / external users the use the get flattened (JSON.stringify()) functionality of the any aspect.

[Karlie-777]

Hi @mrobst Do the numeric properities shown in your dev environment if you use the following way to send trace events?

logTrace(
    message: string,
    severityLevel: SeverityLevel,
    prop?: { [key: string]: any }
  ) {
    // convert the properties object into keys with only string values
    Object.keys(prop).forEach(k => { prop[k] = prop[k].toString() })

    this.appInsights.trackTrace(
      { message: message, severityLevel: severityLevel , properties: prop },
    );
  }

If you put the properties outside base data object, numeric values will be recognized as measurement rather than properties and therefore they will be ignored in trackTrace payload. Please let me know if this works for you😊