[stream] xclaim and xpending, all options test seems to be flaky

[uki00a]

https://github.com/denodrivers/redis/runs/1523779037

failures:

[stream] xclaim and xpending, all options
Error: -ERR The ID specified in XADD is equal or smaller than the target stream top item

    at tryParseErrorReply (io.ts:194:11)
    at readReply (io.ts:104:7)
    at async RedisImpl.execBulkReply (redis.ts:99:24)
    at async Promise.all (index 0)
    at async stream_test.ts:473:5
    at async withConsumerGroup (stream_test.ts:39:3)
    at async Object.func (stream_test.ts:464:3)
    at async test_util.ts:35:9
    at async asyncOpSanitizer (deno:cli/rt/40_testing.js:36:7)
    at async Object.resourceSanitizer [as fn] (deno:cli/rt/40_testing.js:70:7)

[stream] xinfo
AssertionError: Test case is leaking async ops.
Before:
  - dispatched: 1381
  - completed: 1380
After:
  - dispatched: 1412
  - completed: 1412

Make sure to await all promises returned from Deno APIs before
finishing test case.
    at assert (deno:cli/rt/06_util.js:33:13)
    at asyncOpSanitizer (deno:cli/rt/40_testing.js:46:7)
    at async Object.resourceSanitizer [as fn] (deno:cli/rt/40_testing.js:70:7)
    at async TestRunner.[Symbol.asyncIterator] (deno:cli/rt/40_testing.js:245:13)
    at async Object.runTests (deno:cli/rt/40_testing.js:322:22)
    at async $deno$test.ts:3:1

failures:

	[stream] xclaim and xpending, all options
	[stream] xinfo

[Terkwood]

Oo, interesting, did this test behavior change recently? Or has it been misbehaving for a while now?

[Terkwood]

I see this going back to https://github.com/denodrivers/redis/runs/1523779037?check_suite_focus=true (20 days ago), at least

[Terkwood]

...and even before that. And some other tests are passing in between the failures. So, yes, it's definitely not predictable enough. I'll work on reproducing this locally

[Terkwood]

Not surprisingly, this works locally on an aging MacBook Pro. I would guess that my local environment has a bit more power than the Github Actions environment. My next step would be to look at the timing expectations around the Github Actions test runs... It's been a little while since I've been in this code base, but this seems like a classic integration testing situation 😁 🤓 ⌚

[Terkwood]

We already have delay statements in the run. I would like to push a change set which increases these values and then see how it performs under github actions

await delay(5);

[uki00a]

This worked well on my local machine! (Ubuntu 20.04) I'll look into it too 😉

[Terkwood]

Yeah, I appreciate that Microsoft has given us such a nice tool in Github Actions, but their compute power is limited! I proposed a fix in #165, which apparently passes on the first try here in Githubland. Let me know what you think.