Open tomatod opened 6 months ago
Thanks for raising this,
I'd appreciate it if someone else could run their eyes over these tests; they may be a bit fragile (have seen a very occasional failure) but were the best I could come up with at the time. I wanted to really exercise autopaho
well as errors are most likely to surface when it's under stress (and the tests did reveal a couple of issues; since fixed).
I think the actual issue here is the context ctx, cancel := context.WithTimeout(context.Background(), longerDelay)
; this probably needs to be longer than a second on low powered kit. Would appreciate any thoughts re a better way of handling this (there will always be a potential for false alerts with time based tests like this when resources are very low; currently my only real thought is to increase the timeouts).
M.
Describe the bug I think this isn't a bug, but it could be reproduced in partical environments especially with low machine resources. So, as a attention, I reported this.
autopaho's main loop of connection manager is terminated in one second at TestQueuedMessage. The part of implemention is the following.
So, if your machine couldn't finish the test in one secode, the connection manager would be terminated and test would be failed in result.
To reproduce
go test -coverprofile /tmp/autopaho_coverage.out -race -tags=unittest ./autopaho/ -v -count 1 -run TestQueuedMessages
(I often use this low spec machine outside...)
Debug output Hire is an example result of the above test command.
Expected behaviour Test is desired to pass without depending on environments.