BufferOption configuration not working as expected

[danigutierrezayuso]

We've seen that the bufferOption on the EmitterConfiguration is not being used to check if an event should be sent directly or not.

When sending a new event the function 'addPayload' from the Emitter class is called, and that function is going to save the event in the 'eventStore' (SQLite in our case) and then is going to call the flush() function directly, so every time a new event is added there will be a new request sending that single event to the server.

Maybe on that addPayload function we should only call the flush function when the number of events saved in the eventStore has reached the bufferOption value. Doing so I think we can have the behavior described in the documentation:

/// Sets whether the buffer should send events instantly or after the buffer
/// has reached it's limit. By default, this is set to BufferOption Default.
@objc
    var bufferOption: BufferOption { get set }

Current behavior After setting the bufferOption configuration to defaultGroup (10 events) the events are being sent one by one.

Expected behavior After setting the bufferOption configuration to defaultGroup (10 events) the events are being sent on requests with a payload containing an array of 10 events.

[matus-tomlein]

Hi @danigutierrezayuso, thanks for reporting this! I agree that the current behaviour is quite unexpected and doesn't fit with the buffer configuration options. It is on radar to revisit this, we'll discuss it in the team soon.

[danigutierrezayuso]

I've created a PR with changes to fix this behavior (it doesn't include any tests though): https://github.com/snowplow/snowplow-ios-tracker/pull/833