Lack of fail over for emitters.

[smentek]

Lets say I want to track unstructEvent link: $trucker->trackUnstructEvent($json, $context, $timestamp);

Now let say I want to do some actions in case it fails. There is no way to do that.

• No Exception that could be catched
• No false flag in return

Nothing. The same for all other calls.

It is like speed would be all we care about here and reliability is nothing. But if speed is what we are focus on should we even write it in PHP? I would prefer slow but readable and safe solution...

After adding Exceptions please remove all 'print_r' from code. What do do with error messages that would be properly set in exceptions should be part of application that uses snowplow-tracker.

[alexanderdean]

Have you looked at the SyncEmitter? https://github.com/snowplow/snowplow-php-tracker/blob/master/src/Emitters/SyncEmitter.php

[smentek]

I'm afraid I did.

What is needed is:

if (!$trucker->trackUnstructEvent($json, $context, $timestamp)) { Here save the the day! }

or even better:

try { $trucker->trackUnstructEvent($json, $context, $timestamp) } catch(ExceptionSnowplowTracker $e) { Here save the the day!

print_r(sprintf('%s - %s', "This is what went wrong: ", $e->getMessage())) }

This: $debug parameter inside SyncEmitter::__construct( whatever here, $debug) should be removed. I do not see any added value from having debugger as part of code going on production.

[alexanderdean]

Thanks for the feedback - scheduled!

[brenton-vidcorp]

I've just been looking into how to gracefully handle failures when using POST and buffer size/batch of 50 events on 0.3.1.

Looks like I could so something like $buffer = $this->emitter->returnBuffer(); $result = $this->emitter->send($buffer);

and do something if the result != true

But then I won't be able to reset the buffer... so any more events I add via track() will cause a flushEvents to trigger and send the events again.

~Unless I'm missing something... The debug flag and using returnRequestResults doesn't seem to do be returning anything despite Sync POST Request Failed: Requests_Exception: cURL error 28: Connection timed out appearing in the debug log.~ Nope that was my bad

I think that if flushEvents or send is getting called somewhere and it fails to flush... that exception should be bubbling out so we can handle and retry/requeue whatever (this would also cause the exception to be generated in trackUnstructEvent.

[adatzer]

Hello @brenton-vidcorp and @smentek ! Thank you very much for your feedback! The lack of fail over is indeed something we have considered and we will rather build a proper buffer and retry mechanism in the php-tracker itself, instead of using exceptions. Also, return values are a somewhat fragile way of information passing in this context, but it would be great if you could share your ideas along so as to understand your use cases better. What do you think?