Incorrect schema format is set in the Payload

[yalisassoon]

The good folks at mParticle spotted this whilst working on integrating Snowplow with their platform - Jonathan Almeida (@jonalmeida) - can you take a look please?

---

There might be a bug in the trackScreenView code. The version I have from Github reads:

payload.setSchema( this.baseSchemaPath + "/contexts/" + this.schemaTag + Version.VERSION);

This led to an exception, possibly in the Jackson JSON libraries.

I fixed it with this line:

payload.setSchema( this.baseSchemaPath + "/contexts/" + this.schemaTag + "/" + Version.VERSION);

[jonalmeida]

Thanks! Yes, this is fixed in develop. So when we do a cut-over for 0.5.0 this should make it's way there.

[alexanderdean]

Okay cool - Yali please raise the other bug and we will get this fixed in time for the 050 too

[jonalmeida]

For tracking purposes, this is the commit that fixed the issue b8d2220

[yalisassoon]

An update from the guys at mParticle:

---

Very likely the bug I reported is different from what I reported. This is because I saw a similar exception after adding the ‘/’.
My confusion is likely due to the Github source using different string formats.
For example the test code uses this line which does contain the ‘/’:

payload.setSchema("iglu:com.snowplowanalytics.snowplow/payload_data/jsonschema/1-0-0");

Whereas, other code does not add the slash between the schema and the version:

this.contextSchema = vendor + "/contexts/" + schemaTag + version;

In reality, the exception could be due to the contents of ‘data’ being a JSON object and not a string, and the payload.getMap() call in trackScreenView is expecting to return a HashMap<String, String>
Here’s the contents of the payload from my call to trackScreenView

{"schema":"iglu:com.snowplowanalytics.snowplow/contexts/jsonschema0.4.0","data":{"id":"test","name":"Screen 1"}}

As a result of the exception, the screen parameters (in ‘data’) are getting removed and won’t be in the call to Snowplow.

---

[alexanderdean]

Let's hold off on the 0.5.0 release until Jonathan Almeida (@jonalmeida) can clarify what is going on here

[jonalmeida]

Sorry I didn't get back sooner. Yes, this is a separate issue from what them mentioned. It was because of how the kv-values were not properly stringified - this is fixed as well.

trackScrewView now uses the TrackerPayload class to create it's payload which makes use of ObjectMapper.writeValueAsString(map) to take care of creating the correct string.

Definitely worth doing the cutover for 0.5.0, since it's got a bunch of bug fixes in it.

[alexanderdean]

Thanks Jonathan Almeida (@jonalmeida) - I will crack on with the release...

[alexanderdean]

Done, closing