Tests are failing on macOS

[erf]

Running dart run test --chain-stack-traces yields the following:

00:05 +12 -1: test/cas_test.dart: Test Incr CAS Multiple [E]
  SocketException: Connection failed (OS Error: Too many open files, errno = 24), address = localhost, port = 6379
  dart:io                              Socket.connect
  package:redis/connection.dart 21:19  RedisConnection.connect
  test/main.dart 33:28                 generate_connect
  test/cas_test.dart 29:10             testincrcas
  test/cas_test.dart 18:13             main.<fn>
  ===== asynchronous gap ===========================
  dart:async                           _asyncThenWrapperHelper
  test/cas_test.dart                   main.<fn>

00:05 +13 -1: Some tests failed.

[ra1u]

Hi!

From error report it seems that issue is that, there are too many open sockets. Tests do not close connection after opening so I think, that at some point there are too many open sockets. Do you know what is limit on number of open sockets on your macOS?

We can try this assumptions by running test one by one. Can you run test individually and see if they pass?

dart test test/cas_test.dart

Kind regards, Luka

[erf]

# limit of file descriptors
~/projects/redis-dart % ulimit -n
256

# limit of processes
~/projects/redis-dart % ulimit -u
2666

~/projects/redis-dart % launchctl limit maxfiles
        maxfiles    256            unlimited

cas_test.dart is the only test that fails.

[erf]

If i set N=150 it passes, anything above it fails.

[erf]

It seem you generate a connection for each N, I think that is why it fails. You can't pass the Command from the initial generate_connect? I tried it but got RedisError(ERR MULTI calls can not be nested). Although not sure how CAS works.

[erf]

Why do you run a for loop in most of your tests?

[ra1u]

In cas_test, we generate 300 concurrent connections, to create actual race condition as this cas pattern is about. We test cas behavior when race condition happens.

Loops are in general used to test again larger sample size and test for more realistic use cases. Some failures can be exposed only by such tests.

From your case, we should set N on 100 for cas_test.

[erf]

Ok great. I can make a PR later and change N.

It might be an idea to create separate tests for the both the simplest case in addition to a "for loop" test.

[ra1u]

Thank You for this This issue with failed test is now closed. Feel free to open another issue, pull request or both regarding "for loops" in tests.