When there is an error with sending a POST/GET requests the tracker returns a status code of -1. This makes debugging harder when using containers without inspecting the logs.

The return of the status is done in:

Which defaults to -1 when the status code is not OK 200, instead of the real value.

For comparison the Python tracker returns the status code with the warning message:
https://github.com/snowplow/snowplow-python-tracker/blob/91da00a0549f05169b179c819028409d3d3f7401/snowplow_tracker/emitters.py#L195

This would greatly simplify the use of the Tracker in the snowplow-tracking-cli as it would not need to create any local files to work.

It also corrupts the go modules.

We no longer use Travis CI, we should switch to Github Actions for builds.

This should work exactly like trackUnstructEvent (but is better named).

We should make sure that this is the first method in the tracker documentation for the track methods described.

Is your feature request related to a problem? Please describe.
The Subject is currently only set when the Tracker is initialised. This means, it is impossible to update the Subject safely for a specific event, if one event shouldn't use the same user information that has been set at the Tracker level.

Describe the solution you'd like
Allow a Subject to be set when tracking an event

Describe alternatives you've considered
Creating multiple Tracker instances with the same Emitter. This is a bit of a crazy workaround and is in no way a clean solution to the issue.

Looking at a lot of the forks of this project the most common trend is to remove the SQLite implementation. Getting rid of the dependency bloat is a nice win here as well as making this project more flexible.

This is related to: https://github.com/snowplow/snowplow/issues/2457

Copyright template in licence file needs to be filled out:

Currently only for 2xx

Often we need a way to ensure the queue is empty for killing a short-lived application - as a utility of the Tracker this would make things a lot easier as this logic would not need to be re-implemented in lots of places.

https://goreportcard.com/report/github.com/snowplow/snowplow-golang-tracker

Describe the bug
When running the tracker there are occasional panics thrown which cause the whole application to crash. These occur not in the Tracker itself but in the Emitter transport layer below it - however it might be possible to handle this panic within the Emitter to recover gracefully.

To Reproduce
This is not easy to reproduce but in a long running application I will see crashes consistently every 1-2 days.

Expected behavior
The tracker should not throw a panic performing its core function.

Environment (please complete the following information):

• ECS Fargate on AWS
• Golang 1.13.8
• Container: alpine:3.7

Additional context
The stack trace:

1594737074490,fatal error: concurrent map read and map write
1594737074493,goroutine 1385994 [running]:
1594737074493,"runtime.throw(0x10170e9, 0x21)"
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/runtime/panic.go:774 +0x72 fp=0xc00096ea80 sp=0xc00096ea50 pc=0x42dc02
1594737074493,"runtime.mapaccess1(0xe630a0, 0xc000396060, 0xc00096eb60, 0x19844c0)"
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/runtime/map.go:411 +0x269 fp=0xc00096eac8 sp=0xc00096ea80 pc=0x40da49
1594737074493,"net/http.(*Transport).removeIdleConnLocked(0x1957300, 0xc00116e480, 0x8)"
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/net/http/transport.go:983 +0x1ac fp=0xc00096eba8 sp=0xc00096eac8 pc=0x6bcc4c
1594737074493,"net/http.(*Transport).removeIdleConn(0x1957300, 0xc00116e480, 0xc000080b00)"
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/net/http/transport.go:973 +0x80 fp=0xc00096ec08 sp=0xc00096eba8 pc=0x6bca50
1594737074493,"net/http.(*persistConn).readLoop.func1(0xc00116e480, 0xc00096ed88)"
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/net/http/transport.go:1880 +0x58 fp=0xc00096ec30 sp=0xc00096ec08 pc=0x6ca168
1594737074493,net/http.(*persistConn).readLoop(0xc00116e480)
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/net/http/transport.go:1917 +0x1148 fp=0xc00096efd8 sp=0xc00096ec30 pc=0x6c37b8
1594737074493,runtime.goexit()
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/runtime/asm_amd64.s:1357 +0x1 fp=0xc00096efe0 sp=0xc00096efd8 pc=0x45b151
1594737074493,created by net/http.(*Transport).dialConn
1594737074493,	/home/travis/.gimme/versions/go1.13.8.linux.amd64/src/net/http/transport.go:1580 +0xb0d

https://github.com/snowplow/snowplow-golang-tracker/blob/v2.1.0/go.mod#L13

Does this prevent v2.1 to be installed?

The golang tests are treated as the same package as the actual tracker; it would be good to have a small integration package which treated the tracker as external to ensure reliable behaviour when integrating into other packages.

As database connections are not closed on application exit it can be left in an invalid state.

There seems to be an obscure behavior around not reading the body of a response before closing it that prevents Transport from freeing the connection for re-use.

Describe the bug
This project depends on https://github.com/myesui/uuid ; which appears to have disappeared from the face of Github. The repo 404's and the user themself was apparently created only a week ago? Very strange.

> go mod vendor
go: github.com/snowplow/snowplow-golang-tracker/[email protected] requires
        github.com/myesui/[email protected]: reading github.com/myesui/uuid/go.mod at revision v1.0.0: unknown revision v1.0.0

To Reproduce
Depend on snowplow/snowplow-golang-tracker and run go mod vendor

Expected behavior
Don't depend on non-existent projects

Obviously this isn't your fault, and maybe that repo will come back? Not sure what's going on, but it may be worthwhile depending on a more reliable uuid package regardless. Cheers!

Dep documentation can be found at https://github.com/golang/dep

You can follow this steps to setup dep on the project:

• Install dep on your local machine: brew install dep
• Create the dependency and lock files on the project root folder: dep init
• Add to the makefile a target to ensure that dependencies are meet: dep ensure

On a day to day basis you can upgrade the dependencies running: dep ensure -upgrade -v

Dep places the dependencies on the vendor folder, you can store or not this folder on git. I recommend not storing it to avoid doing commits with large number of files when upgrading the dependencies.

PS: If dep seems to be stuck while resolving dependencies, make sure the your ssh key is unlocked and able to access the git repo.