intermittent test failures with version 2.0

[decathorpe]

I'm trying to build a fedora package for this go library, but I'm getting semi-random test failures, for example:

+ go test -compiler gc -ldflags '' github.com/thejerf/suture
2017/03/02 14:31:47 Supervisor A: A: Failed service 'B' (1.000000 failures of 5.000000), restarting: true, error: "{B B} returned unexpectedly", stacktrace: [unknown stack trace]
2017/03/02 14:31:47 Supervisor Top5: Nested5: Service Service5 failed to terminate in a timely manner
2017/03/02 14:31:47 Supervisor A4: Entering the backoff state.
--- FAIL: TestRemoveService (0.00s)
	suture_test.go:423: Did not detect that the ServiceToken was wrong
2017/03/02 14:31:47 Supervisor A4: A4: Failed service 'B4' (1.000000 failures of 0.500000), restarting: false, error: "{B4 B4} returned unexpectedly", stacktrace: [unknown stack trace]
2017/03/02 14:31:47 Supervisor A4: Exiting backoff state.
2017/03/02 14:31:47 Supervisor Top9: Entering the backoff state.
2017/03/02 14:31:47 Supervisor Top9: Exiting backoff state.
2017/03/02 14:31:47 Supervisor A4: A4: Service &suture.BarelyService{} failed to terminate in a timely manner
2017/03/02 14:31:47 Supervisor A4: A4: Failed service '&suture.BarelyService{}' (1.000000 failures of 1.000000), restarting: true, error: test error, stacktrace: 
2017/03/02 14:31:47 Supervisor Top9: Nested9: Failed service 'Service9' (1.000000 failures of 5.000000), restarting: true, error: "{Service9 Service9} returned unexpectedly", stacktrace: [unknown stack trace]
FAIL
FAIL	github.com/thejerf/suture	0.015s

or a second failure:

+ go test -compiler gc -ldflags '' github.com/thejerf/suture
2017/03/02 14:25:16 Supervisor A4: Entering the backoff state.
2017/03/02 14:25:16 Supervisor A4: A4: Failed service 'B4' (1.000000 failures of 0.500000), restarting: false, error: "{B4 B4} returned unexpectedly", stacktrace: [unknown stack trace]
2017/03/02 14:25:16 Supervisor A4: Exiting backoff state.
2017/03/02 14:25:16 Supervisor A: A: Failed service 'B' (1.000000 failures of 5.000000), restarting: true, error: "{B B} returned unexpectedly", stacktrace: [unknown stack trace]
2017/03/02 14:25:16 Supervisor Top5: Nested5: Service Service5 failed to terminate in a timely manner
2017/03/02 14:25:16 Supervisor A4: A4: Service &suture.BarelyService{} failed to terminate in a timely manner
2017/03/02 14:25:16 Supervisor A4: A4: Failed service '&suture.BarelyService{}' (1.000000 failures of 1.000000), restarting: true, error: test error, stacktrace: 
2017/03/02 14:25:16 Supervisor Top9: Entering the backoff state.
2017/03/02 14:25:16 Supervisor Top9: Exiting backoff state.
2017/03/02 14:25:16 Supervisor Top9: Nested9: Failed service 'Service9' (1.000000 failures of 5.000000), restarting: true, error: "{Service9 Service9} returned unexpectedly", stacktrace: [unknown stack trace]
--- FAIL: TestRemoveService (0.00s)
	suture_test.go:423: Did not detect that the ServiceToken was wrong
FAIL
FAIL	github.com/thejerf/suture	0.014s

Any idea what might be causing this?

[thejerf]

No. I will have to look at this later for you since my workday is starting.

Can you also add your Go version? (I doubt it's an issue but it might help.)

[decathorpe]

Thanks for looking into this!

The 2 failures above are with go 1.8 on fedora rawhide, where the tests fail randomly about 1 out of 6 times. I just did some tests with go 1.7.5, where failures are about this frequent, too.

[thejerf]

I've added a branch called issue_20 to try to resolve this.

This test was trying to ensure that the service tokens for different supervisors are sufficiently isolated from each other that we can detect if you "cross the streams" between two supervisors. I think I just happened to code in a constant in the tests, assuming that the supervisor in the test would never have a particular supervisor ID, that it can in fact sometimes have depending on the order the parallel tests run in. The issue_20 branch has a fix for the test which is a safe fix. If it makes the problem go away, then this may turn out to "just" be a bug in the tests.

Please let me know. If this works I'll put out a 2.0.1.

[thejerf]

Oh, and I just figured out the connection between your name and your avatar. Nice.

[decathorpe]

I'm running a couple of test builds while I'm AFK. But so far, it looks like the change you made fixed the tests.

BTW, I think you're the first one to get that pun ;)

[decathorpe]

Looks good, 20+ succeeded builds. You don't necessarily need to tag a new version, a commit in master is enough for me.

[thejerf]

Thank you for your report.

I do have to push a new tag and release out, though, because Debian has decided to package this, and if my tests have failures, it's only a matter of time before I hear from them. :)

[decathorpe]

Thank you for fixing this so quickly! :)