vcpkg was unable to detect the active compiler's information

Describe the bug
vcpkg fails with and without being bundled by cmake, only on opensuse. This error does not happen on other distros of linux.
Environment

OS: linux opensuse
Compiler: 13.2.1

To Reproduce
Steps to reproduce the behavior:

build guide https://gitlab.com/suyu-emu/suyu/-/wikis/Building-for-Linux
mkdir build; cd build
cmake .. -GNinja -DSUYU_USE_BUNDLED_VCPKG=ON -DSUYU_TESTS=OFF

Expected behavior
to build
Failure logs
-- Configuring x64-linux-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:112 (message):
    Command failed: /home/redhawk/code/suyu/externals/vcpkg/downloads/tools/cmake-3.27.1-linux/cmake-3.27.1-linux-x86_64/bin/cmake /home/redhawk/code/suyu/externals/vcpkg/scripts/detect_compiler -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/redhawk/code/suyu/externals/vcpkg/packages/detect_compiler_x64-linux -DCMAKE_MAKE_PROGRAM=/home/redhawk/code/suyu/externals/vcpkg/downloads/tools/ninja/1.10.2-linux/ninja -DCMAKE_SYSTEM_NAME=Linux -DBUILD_SHARED_LIBS=OFF -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=/home/redhawk/code/suyu/externals/vcpkg/scripts/toolchains/linux.cmake -DVCPKG_TARGET_TRIPLET=x64-linux -DVCPKG_SET_CHARSET_FLAG=ON -DVCPKG_PLATFORM_TOOLSET=external -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE -DCMAKE_VERBOSE_MAKEFILE=ON -DVCPKG_APPLOCAL_DEPS=OFF -DCMAKE_TOOLCHAIN_FILE=/home/redhawk/code/suyu/externals/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON -DVCPKG_CXX_FLAGS= -DVCPKG_CXX_FLAGS_RELEASE= -DVCPKG_CXX_FLAGS_DEBUG= -DVCPKG_C_FLAGS= -DVCPKG_C_FLAGS_RELEASE= -DVCPKG_C_FLAGS_DEBUG= -DVCPKG_CRT_LINKAGE=dynamic -DVCPKG_LINKER_FLAGS= -DVCPKG_LINKER_FLAGS_RELEASE= -DVCPKG_LINKER_FLAGS_DEBUG= -DVCPKG_TARGET_ARCHITECTURE=x64 -DCMAKE_INSTALL_LIBDIR:STRING=lib -DCMAKE_INSTALL_BINDIR:STRING=bin -D_VCPKG_ROOT_DIR=/home/redhawk/code/suyu/externals/vcpkg -DZ_VCPKG_ROOT_DIR=/home/redhawk/code/suyu/externals/vcpkg -D_VCPKG_INSTALLED_DIR=/home/redhawk/code/suyu/build/vcpkg_installed -DVCPKG_MANIFEST_INSTALL=OFF
    Working Directory: /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/x64-linux-rel
    Error code: 1
    See logs for more information:
      /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-CMakeCache.txt.log
      /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-out.log
      /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_configure_cmake.cmake:344 (vcpkg_execute_required_process)
  scripts/detect_compiler/portfile.cmake:18 (vcpkg_configure_cmake)
  scripts/ports.cmake:170 (include)

See logs for more information:
 /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-CMakeCache.txt.log
 /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-out.log
 /home/redhawk/code/suyu/externals/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-err.log

dnf install g++


skyblockmods.com

Add "skyblockmods.com" to the Suspicious Blocklist.
The Site hosts Malicious content which includes Minecraft Token Grabbers.
This side usually spreads on hypixel skyblock by bots. if you install this mod, your account will be used to spread the mod.

Thanks for the Report, I've added it to the Suspicious list :3


Master to Develop merge

Merging all the latest hotfixes into develop.

Conflicts here.

Fixed conflicts in #3766


[HUDI-7466] Add tests to AWSGlueCatalogSyncClient

Change Logs
Continuation of https://github.com/apache/hudi/pull/10604
Scope:

Integration test
.excludeColumnSchema(true) when fetching all partitions to reduce potential overhead

Impact
Describe any public API or user-facing feature change or any performance impact.
No
Risk level (write none, low medium or high below)
If medium or high, explain what verification was done to mitigate the risks.
No
Documentation Update
Describe any necessary documentation update if there is any new feature, config, or user-facing change. If not, put "none".

The config description must be updated if new configs are added or the default value of the configs are changed
Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
ticket number here and follow the instruction to make
changes to the website.

Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Hudi 1.0.0-SNAPSHOT:
[INFO]
[INFO] Hudi ............................................... SUCCESS [  4.304 s]
[INFO] hudi-tests-common .................................. SUCCESS [  5.199 s]
[INFO] hudi-io ............................................ SUCCESS [  7.691 s]
[INFO] hudi-hadoop-common ................................. SUCCESS [  5.569 s]
[INFO] hudi-common ........................................ SUCCESS [17:24 min]
[INFO] hudi-hadoop-mr ..................................... SUCCESS [01:34 min]
[INFO] hudi-sync-common ................................... SUCCESS [  9.393 s]
[INFO] hudi-hive-sync ..................................... SUCCESS [  01:14 h]
[INFO] hudi-aws ........................................... SUCCESS [16:09 min]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:49 h (Wall Clock)
[INFO] Finished at: 2024-03-21T04:54:20+01:00

Unfortunately, Azure looks to be blocked as before -
@Disabled("HUDI-7475 The tests do not work. Disabling them to unblock Azure CI")
@parisni if it's ok - can I put @Disabled back and we can merge?

if it's ok - can I put @Disabled back and we can merge?

how do you run the integrations tests locally ?  From what I saw here they shouldn't pass. Below is how I do:
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-arm64/ mvn verify -Pintegration-tests -DskipITs=false  -Dspark3.3 -Dscala-2.12 -Drat.skip=false   -pl hudi-aws

I spent few hours trying to make it work best, at the end surrendered, just run locally moto with docker run and run tests through IDE(screen attached)

just run locally moto with docker run and run tests through IDE(screen attached)

what about the command line I provided. I can take a look on your branch if needed

I don't think it's critical, I mean this way or another it passes

From the error logs you have
Error:  DOCKER> [motoserver/moto:5.0.3] "it-aws": Timeout after 10060 ms while waiting on url http://localhost:5010/moto-api/
Error:  DOCKER> Error occurred during container startup, shutting down...

I cloned your branch and reproduce the error locally when running the IT tests.
Turns out you should use port 5000 and not 5010. If you configure the container to the latter, you have to configure moto to use the same. But currently moto listen the former.
In my case, falling back to 5000 port fixed the error, should be the same on azure CI

The log of my tests:

Saw this test - submitted first PR without tests, then @parisni asked for it.
Checked that tests were disabled, so indeed tried to make them work on CI - jus removed @Disabled annotation - it failed
Tried with another port on CI(5010)
Spent about 2 hours trying to make it work
Disabled it back and reverted changes(@Disabled and port).

I can try to just enable it as it's how was before, I'm not familiar with the CI part here, so decided just to ensure tests work as not want to spend much time

with all defaults i see java.util.concurrent.ExecutionException: software.amazon.awssdk.core.exception.SdkClientException: Unable to execute HTTP request: Connection refused: localhost/<IP_ADDRESS>:5000

Is PR this still WIP?

Now it should pass, I'm not familiar with CI setup to fix it unfortunately - at least it was like this before, so it's not completely fixed but definitely it's better than before and there is no risk.

@hudi-bot run azure

Can we make repairing tests a separate effort?

makes sense. thanks for your insight

Is this PR ready for review again?


[MODEL EVALUATION REQUEST] NLPnorth/snakmodel-7b-instruct

Model ID
NLPnorth/snakmodel-7b-instruct
Model type
Decoder model (e.g., GPT)
Evaluation languages

[X] Danish
[ ] Swedish
[ ] Norwegian (Bokmål or Nynorsk)
[ ] Icelandic
[ ] Faroese
[ ] German
[ ] Dutch
[ ] English

Merged model
Not a merged model

Results are live now 🎉


Bug Report: Week 6 Got Crashed

So Went I test for Week 6 they crash Because Of Notes Pixel I think they Need Note Style With  Rating Style

please clarify i cant understand this

This Mean The Note Style Are not responding The in game

basically when the note style is set to pixel, it tries to load an asset that doesn't exist but then immediately crashes i think

basically when the note style is set to pixel, it tries to load an asset that doesn't exist but then immediately crashes i think

It does exist, just only in the week 6 folder

the source code apparently only points to a weeb/ folder and not week6

the source code apparently only points to a weeb/ folder and not week6

So What I Cannot Types Such As Roses And Senpai Also Thorn  in Chart State

isn't this fixed ?

pretty sure this is fixed?


Fix Preprints api taxonomy [OSF-7352]

Purpose
Taxonomy api is broken
Changes
Changes the query to work with django
Side effects
None known
Ticket
[#OSF-7352]
https://openscience.atlassian.net/browse/OSF-7352

glam


Add support for mouse input for multiple monitors

Before it could only do mouse input on first monitor on a multi-monitor setup. Not sure if there'll be any issues with Y coordinates, but should be fine.

Thanks ubbelol! :) I've changed the code a little bit, my second monitor is on the left side, so the offsetX is -1920. Can you confirm this is still working for you correctly?

Yup, seems to work correctly now. :+1:


suggestion: format topojson neighbors the same way as a force links object

Because I am working with both right now, I am wondering why links objects (from d3.force) and neighbors objects (from d3.geo) are structured differently, whereas they are substantially equivalent.
Since neighbors are, to my knowledge, not used directly in any subsequent functions, I would suggest to structure them as links objects.

The most prominent example of topojson.neighbors (the map coloring) uses this structure as a lookup table, something which is not easy to do with a list of links. (IOW, adjacency matrix vs adjacency list.)
It's a bit painful to switch from one representation to the other, in both directions. Here's my method (maybe not the best):
converting neighbors to links is relatively straightforward:
neighbors2links = (neighbors, objects) => d3.merge(
  neighbors
    .map((n,i) => n.map(j => j > i ? { source: objects[i], target: objects[j] } : null)
  .filter(link => !!link))
);

to convert links to neighbors we need the nodes to have an index, or create it on the fly:
   links2neighbors = (links, objects) => {
    var neigh = [];
    objects.forEach((d,i) => d.index = i); // create the index
    links.forEach(d => {
      neigh[d.source.index] = (neigh[d.source.index] || []).concat([d.target.index]);
      neigh[d.target.index] = (neigh[d.target.index] || []).concat([d.source.index]);
    });
    return neigh.map((d,i) => neigh[i].sort());
  }

both algorithms are linear (in O(V) and O(V+E)).
Maybe the question is not so much about changing topojson-client than wanting a d3-graph library.

Thanks for the suggestion. As @Fil suggests both representations can be useful in different contexts, so I don’t plan on changing from an adjacency matrix to an adjacency list. Though it might be neat to think about a more fleshed-out topology (or network) API…


Azubu.tv missing PlayerKey

When I'm trying to watch a stream on Azubu, I get this error :
 livestreamer http://www.azubu.tv/SouzaaPlays source
[cli][info] Found matching plugin azubutv for URL http://www.azubu.tv/SouzaaPlays
error: Missing key 'playerKey' in player params
I'm using Archlinux with livestreamer 1.12.2

This is fixed in the development branch, you can get the new plugin here.

Thanks I'll close this issue then

Is there a reason this fix has not been released yet? I mean current azubutv plugin doesn't work period, so there should at least be a bugfix release including this fixed plugin.

@sulami thx

Any update on why this is not released?

Any update on why this is not released?

This commit was pushed into develop branch. Nightly builds are available which contain the latest development code. Master branch was not updated, so there are currently no new releases.

Just installed newest version available on pip, 1.12.2, and this error still occurs.

Like @0880 said. There is currently no new release of livestreamer. Use the Nightly builds  on Windows or use pip install -U git+https://github.com/chrippa/livestreamer.git to get the latest development version via pip.

If you are on MacOS El Captain, you need to run with the flag --ignore-installed six:
(sudo) pip install -U git+https://github.com/chrippa/livestreamer.git --ignore-installed six


cluster instability connect/disconnect

Hello,
I've already posted recently an issue about this, but my kubernetes DNS usage to point to hostnames of each Redis cluster node was wrong.
This was fixed, but I still have my issue of deconnecting/reconnecting and reach the maxRedirections limit.
To best understood, I've added log on each event, and I've logged the concerned IP node, and my object of existing nodes based on "+node" / "-node" events. On "+node" event, I add in the object the IP with the value "1". On "-node" event, I set the value to "0". On "node error", I set the value to "2".
Like that, we can easily see what's happening. I suspect it's a Redis or Kubernetes configuration issue, but my redis cluster info seems to report all is ok:
<IP_ADDRESS>:6379> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:3
cluster_stats_messages_ping_sent:215224
cluster_stats_messages_pong_sent:214986
cluster_stats_messages_fail_sent:65
cluster_stats_messages_sent:430275
cluster_stats_messages_ping_received:214986
cluster_stats_messages_pong_received:215120
cluster_stats_messages_fail_received:28
cluster_stats_messages_received:430134

<IP_ADDRESS>:6379> cluster slots
1) 1) (integer) 0
   2) (integer) 5460
   3) 1) "<IP_ADDRESS>"
      2) (integer) 6379
      3) "cb9b62ea60b58d71a0042b40ec064053c2780ad8"
   4) 1) "<IP_ADDRESS>"
      2) (integer) 6379
      3) "ab3f992b0a2530473259988ba4f7b6d6619d2520"
2) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "<IP_ADDRESS>"
      2) (integer) 6379
      3) "2894e18b3054a0a80aa09ceca11632483f535d0a"
   4) 1) "<IP_ADDRESS>"
      2) (integer) 6379
      3) "bc98490e48cfe91ab514a3f58fbb00446de4d929"
3) 1) (integer) 5461
   2) (integer) 10922
   3) 1) "<IP_ADDRESS>"
      2) (integer) 6379
      3) "2615e821c55bc5f7e54c151ebcab75f060f5efe7"
   4) 1) "<IP_ADDRESS>"
      2) (integer) 6379
      3) "cd3873300f4d46be9d56052662123864d21c2ac6"

Here is the logs:
-====================[ sendmails ]========================-

(node:8) ExperimentalWarning: The ESM module loader is experimental.

HTML template device_confirmation loaded

HTML template spassword_reset loaded

HTML template email_confirmation loaded

2019-02-05T00:45:12.013Z ioredis:cluster status: [empty] -> connecting

Koa Started - Redis client #75

2019-02-05T00:45:12.021Z ioredis:cluster resolved hostname redis-cluster-0.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:45:12.021Z ioredis:cluster resolved hostname redis-cluster-1.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:45:12.021Z ioredis:cluster resolved hostname redis-cluster-2.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:45:12.021Z ioredis:cluster resolved hostname redis-cluster-4.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:45:12.021Z ioredis:cluster resolved hostname redis-cluster-3.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:45:12.021Z ioredis:cluster resolved hostname redis-cluster-5.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:45:12.024Z ioredis:cluster:connectionPool Reset with [ { port: 6379, host: '<IP_ADDRESS>' },

{ port: 6379, host: '<IP_ADDRESS>' },

{ port: 6379, host: '<IP_ADDRESS>' },

{ port: 6379, host: '<IP_ADDRESS>' },

{ port: 6379, host: '<IP_ADDRESS>' },

{ port: 6379, host: '<IP_ADDRESS>' } ]

2019-02-05T00:45:12.026Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:12.026Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1}

2019-02-05T00:45:12.027Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:12.027Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.027Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:12.028Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.028Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:12.028Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.028Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:12.028Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.028Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:12.028Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.029Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:12.030Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:12.031Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:12.031Z ioredis:cluster:subscriber selected a subscriber <IP_ADDRESS>:6379

2019-02-05T00:45:12.032Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: [empty] -> wait

2019-02-05T00:45:12.032Z ioredis:cluster:subscriber started

2019-02-05T00:45:12.036Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:12.036Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:12.037Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:12.037Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:12.037Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:12.038Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:12.038Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:12.041Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:12.041Z ioredis:cluster cluster slots result [0]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:12.042Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:12.043Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:12.043Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:12.044Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:12.044Z ioredis:cluster:connectionPool Change role of <IP_ADDRESS>:6379 to slave

2019-02-05T00:45:12.044Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:12.044Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:12.044Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:12.044Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.045Z ioredis:cluster:connectionPool Change role of <IP_ADDRESS>:6379 to slave

2019-02-05T00:45:12.045Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:12.045Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:12.045Z ioredis:cluster status: connecting -> connect

2019-02-05T00:45:12.045Z ioredis:cluster status: connect -> ready

redis connect

2019-02-05T00:45:12.048Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:12.048Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> setex([ 'write-test-75', '10', '75' ])

2019-02-05T00:45:12.049Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:12.049Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:12.049Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:12.049Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:12.050Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:12.050Z ioredis:connection set the connection to readonly mode

2019-02-05T00:45:12.050Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:12.050Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:12.050Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:12.050Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:12.051Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:12.051Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:12.051Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:12.052Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:12.052Z ioredis:connection set the connection to readonly mode

2019-02-05T00:45:12.052Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:12.052Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:12.052Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:12.053Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:12.054Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:12.054Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:12.054Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:12.054Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:12.054Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:12.054Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> setex([ 'write-test-75', '10', '75' ])

2019-02-05T00:45:12.055Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:12.055Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:12.055Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:12.056Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> get([ 'write-test-75' ])

2019-02-05T00:45:17.050Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:17.051Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:17.051Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:17.052Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:17.052Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:17.052Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:17.053Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:17.053Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:17.053Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:17.053Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:17.054Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:17.054Z ioredis:cluster cluster slots result [0]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:17.054Z ioredis:cluster cluster slots result [1]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:17.055Z ioredis:cluster cluster slots result [2]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:17.055Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:17.056Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:17.056Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:17.056Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:17.056Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:17.056Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:17.056Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:17.056Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

2019-02-05T00:45:17.057Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:17.057Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:17.058Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:17.058Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:17.058Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:22.052Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:22.053Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:22.061Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:22.061Z ioredis:cluster cluster slots result [0]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:22.061Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:22.062Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:22.062Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:22.063Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:22.063Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:22.063Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:22.063Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:22.063Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:22.063Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:22.063Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:22.063Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:22.063Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:22.064Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:22.064Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:22.064Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:22.065Z ioredis:cluster:subscriber subscriber has left, selecting a new one...

2019-02-05T00:45:22.065Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: wait -> close

2019-02-05T00:45:22.065Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:22.065Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: close -> end

2019-02-05T00:45:22.065Z ioredis:cluster:subscriber selected a subscriber <IP_ADDRESS>:6379

2019-02-05T00:45:22.065Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: [empty] -> wait

2019-02-05T00:45:27.066Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:27.073Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:27.079Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:27.086Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:27.086Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:27.086Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:27.086Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:27.086Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:27.087Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:27.087Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:27.091Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:27.091Z ioredis:cluster cluster slots result [0]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:27.091Z ioredis:cluster cluster slots result [1]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:27.092Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:27.093Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:27.093Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:27.093Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:27.094Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:27.094Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:27.094Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:27.094Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:27.094Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

2019-02-05T00:45:27.095Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:27.095Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:27.097Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:27.098Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:27.098Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:27.098Z ioredis:cluster:subscriber subscriber has left, selecting a new one...

2019-02-05T00:45:27.098Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: wait -> close

2019-02-05T00:45:27.098Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:27.098Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: close -> end

2019-02-05T00:45:27.098Z ioredis:cluster:subscriber selected a subscriber <IP_ADDRESS>:6379

2019-02-05T00:45:27.098Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: [empty] -> wait

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:32.080Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:32.085Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:32.088Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:32.088Z ioredis:cluster cluster slots result [0]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:32.088Z ioredis:cluster cluster slots result [1]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:32.088Z ioredis:cluster cluster slots result [2]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:32.089Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:32.089Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:32.089Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:32.089Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:32.089Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:32.089Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:32.090Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:32.090Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:32.091Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:32.091Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:32.092Z ioredis:cluster:subscriber subscriber has left, selecting a new one...

2019-02-05T00:45:32.092Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: wait -> close

2019-02-05T00:45:32.092Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:32.092Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: close -> end

2019-02-05T00:45:32.092Z ioredis:cluster:subscriber selected a subscriber <IP_ADDRESS>:6379

2019-02-05T00:45:32.092Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: [empty] -> wait

2019-02-05T00:45:32.093Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:32.093Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:32.093Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:37.091Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:37.094Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:37.096Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:37.096Z ioredis:cluster cluster slots result [0]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:37.097Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:37.097Z ioredis:cluster cluster slots result [2]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:37.098Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:37.098Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:37.098Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:37.098Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:37.098Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:37.098Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:37.098Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:37.099Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1}

2019-02-05T00:45:37.099Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:37.099Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:37.100Z ioredis:cluster:subscriber subscriber has left, selecting a new one...

2019-02-05T00:45:37.100Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: wait -> close

2019-02-05T00:45:37.100Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:37.100Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: close -> end

2019-02-05T00:45:37.100Z ioredis:cluster:subscriber selected a subscriber <IP_ADDRESS>:6379

2019-02-05T00:45:37.101Z ioredis:redis status[<IP_ADDRESS>:6379 (ioredisClusterSubscriber)]: [empty] -> wait

2019-02-05T00:45:37.102Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:37.102Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:37.102Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:42.094Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:42.096Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:42.097Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:42.100Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:42.100Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:42.100Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:42.100Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:42.101Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:42.101Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:42.101Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:42.103Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:42.103Z ioredis:cluster cluster slots result [0]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:42.104Z ioredis:cluster cluster slots result [1]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:42.104Z ioredis:cluster cluster slots result [2]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:42.104Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:42.104Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:42.104Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:42.104Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:42.104Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:42.104Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:42.105Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:42.105Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:45:42.105Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:42.105Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:42.106Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:42.106Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:42.106Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:47.100Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:47.101Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:47.101Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:47.104Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:47.104Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:47.104Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:47.104Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:47.104Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:47.104Z ioredis:connection set the connection to readonly mode

2019-02-05T00:45:47.104Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:47.104Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:47.104Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:47.106Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:47.107Z ioredis:cluster cluster slots result [0]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:47.107Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:47.107Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:47.107Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:47.107Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:47.107Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:47.107Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:47.108Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:47.108Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:47.108Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:47.108Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:47.108Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:47.108Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:47.110Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:47.110Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:47.110Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:52.102Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:52.102Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:52.102Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:52.104Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:52.104Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:52.104Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:52.104Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:52.104Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:52.105Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:52.105Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:52.106Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:52.106Z ioredis:cluster cluster slots result [0]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:52.106Z ioredis:cluster cluster slots result [1]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:52.106Z ioredis:cluster cluster slots result [2]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:52.107Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:52.107Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:52.107Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:52.107Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:52.107Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:52.107Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:52.107Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:52.107Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:52.108Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:52.108Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:52.109Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:52.109Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:52.109Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:57.108Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:45:57.108Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:45:57.108Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:57.109Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:45:57.109Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:45:57.110Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:45:57.110Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:45:57.110Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:45:57.110Z ioredis:connection set the connection to readonly mode

2019-02-05T00:45:57.110Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:45:57.110Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:45:57.110Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:45:57.112Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:45:57.112Z ioredis:cluster cluster slots result [0]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:57.112Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:57.113Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:45:57.113Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:45:57.113Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:57.113Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:45:57.113Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:45:57.113Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:57.113Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:45:57.113Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:45:57.114Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

2019-02-05T00:45:57.114Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:45:57.114Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:45:57.115Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:45:57.115Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:45:57.115Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:46:02.108Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:46:02.109Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:46:02.109Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:46:02.111Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:46:02.111Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:46:02.111Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:46:02.111Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:46:02.111Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:46:02.112Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:46:02.112Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:46:02.113Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:46:02.113Z ioredis:cluster cluster slots result [0]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:02.113Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:02.113Z ioredis:cluster cluster slots result [2]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:02.114Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:46:02.114Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:46:02.114Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:46:02.114Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:46:02.114Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:46:02.115Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:46:02.115Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:46:02.115Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:46:02.116Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:46:02.116Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:46:02.127Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:46:02.128Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:46:02.128Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:46:07.114Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:46:07.115Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:46:07.115Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:46:07.116Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:46:07.116Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:46:07.117Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:46:07.117Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:46:07.117Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:46:07.117Z ioredis:connection set the connection to readonly mode

2019-02-05T00:46:07.117Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> readonly([])

2019-02-05T00:46:07.117Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:46:07.117Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:46:07.118Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:46:07.118Z ioredis:cluster cluster slots result [0]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:07.118Z ioredis:cluster cluster slots result [1]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:07.118Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:07.119Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:46:07.119Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:46:07.119Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:46:07.119Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:46:07.119Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:46:07.119Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:46:07.119Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:46:07.119Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

2019-02-05T00:46:07.119Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:46:07.119Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:46:07.120Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:46:07.120Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:46:07.120Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:46:12.120Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:46:12.120Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:46:12.120Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:46:12.121Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connecting -> connect

2019-02-05T00:46:12.122Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> auth([ 'PASSWORD' ])

2019-02-05T00:46:12.122Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: connect -> ready

2019-02-05T00:46:12.122Z ioredis:connection set the connection name [client-sendmails-75]

2019-02-05T00:46:12.122Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> client([ 'setname', 'client-sendmails-75' ])

2019-02-05T00:46:12.122Z ioredis:connection send 1 commands in offline queue

2019-02-05T00:46:12.122Z ioredis:redis write command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

2019-02-05T00:46:12.123Z ioredis:cluster cluster slots result count: 3

2019-02-05T00:46:12.123Z ioredis:cluster cluster slots result [0]: slots 10923~16383 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:12.123Z ioredis:cluster cluster slots result [1]: slots 5461~10922 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:12.123Z ioredis:cluster cluster slots result [2]: slots 0~5460 served by <IP_ADDRESS>:6379,<IP_ADDRESS>:6379

2019-02-05T00:46:12.123Z ioredis:cluster:connectionPool Reset with [ { host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: false },

{ host: '<IP_ADDRESS>', port: 6379, readOnly: true } ]

2019-02-05T00:46:12.123Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:46:12.124Z ioredis:cluster:connectionPool Disconnect <IP_ADDRESS>:6379 because the node does not hold any slot

2019-02-05T00:46:12.124Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> close

2019-02-05T00:46:12.124Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:46:12.124Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

2019-02-05T00:46:12.124Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as slave

2019-02-05T00:46:12.124Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:46:12.124Z ioredis:cluster:connectionPool Connecting to <IP_ADDRESS>:6379 as master

2019-02-05T00:46:12.124Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: [empty] -> wait

redis +node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:46:12.125Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: ready -> close

2019-02-05T00:46:12.125Z ioredis:connection skip reconnecting since the connection is manually closed.

2019-02-05T00:46:12.125Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: close -> end

redis -node <IP_ADDRESS> {<IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0, <IP_ADDRESS>: 1, <IP_ADDRESS>: 0, <IP_ADDRESS>: 0}

2019-02-05T00:46:17.122Z ioredis:cluster getting slot cache from <IP_ADDRESS>:6379

2019-02-05T00:46:17.122Z ioredis:redis status[<IP_ADDRESS>:6379 (client-sendmails-75)]: wait -> connecting

2019-02-05T00:46:17.122Z ioredis:redis queue command[<IP_ADDRESS>:6379 (client-sendmails-75)]: 0 -> cluster([ 'slots' ])

/home/node/app/src/app.js:283

app._redis._nodes[data.options.host] = 2

^

ReferenceError: data is not defined

at Cluster.app._redis.on (/home/node/app/src/app.js:283:23)

at Cluster.emit (events.js:182:13)

at /home/node/node_modules/ioredis/built/cluster/index.js:341:27

at Timeout.redis.cluster.utils_1.timeout (/home/node/node_modules/ioredis/built/cluster/index.js:569:24)

at Timeout.run (/home/node/node_modules/ioredis/built/utils/index.js:150:22)

at ontimeout (timers.js:438:13)

at tryOnTimeout (timers.js:300:5)

at listOnTimeout (timers.js:263:5)

at Timer.processTimers (timers.js:223:10)

-====================[ sendmails ]========================-

(node:20) ExperimentalWarning: The ESM module loader is experimental.

HTML template device_confirmation loaded

HTML template password_reset loaded

HTML template email_confirmation loaded

2019-02-05T00:46:24.723Z ioredis:cluster status: [empty] -> connecting

Koa Started - Redis client #75

2019-02-05T00:46:24.733Z ioredis:cluster resolved hostname redis-cluster-0.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:46:24.733Z ioredis:cluster resolved hostname redis-cluster-2.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:46:24.733Z ioredis:cluster resolved hostname redis-cluster-1.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:46:24.733Z ioredis:cluster resolved hostname redis-cluster-3.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:46:24.733Z ioredis:cluster resolved hostname redis-cluster-5.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

2019-02-05T00:46:24.733Z ioredis:cluster resolved hostname redis-cluster-4.redis-cluster.redis.svc.cluster.local to IP <IP_ADDRESS>

Thanks for your help

I close the issue, I suppose it's a redis configuration issue.


Add support for schedule event

Applicable spec: n/a
Overview
The GitHub schedule event handling is added to the pre-job script and the preparation of an additional end-to-end test is added.
The schedule event can only be triggered on the main branch, so in order to implement the end-to-end test, the schedule event tests need to be merged into the main branch beforehand.
Rationale
A self-hosted runner should handle the schedule event.
Checklist

[x] The charm style guide was applied
[x] The contributing guide was applied
[x] The changes are compliant with ISD054 - Managing Charm Complexity
[x] The documentation is generated using src-docs
[x] The documentation for charmhub is updated.
[x] The PR is tagged with appropriate label (urgent, trivial, complex)

@yhaliaw , could you please have a look if you are happy with the schedule test approach. This would currently mean that a schedule workflow would run every 5 minutes.
We may need an additional cleanup mechanism (deleting old workflow runs that did not run the did not trigger the schedule event test job due to lack of corresponding end-to-end tests branches).
An alternative approach would be to test the main branch only once a day or so, but then we would not be immediately alerted when a pr breaks schedule event support, which may be fine as we do not immediately promote releases to stable.

@yhaliaw , could you please have a look if you are happy with the schedule test approach. This would currently mean that a schedule workflow would run every 5 minutes. We may need an additional cleanup mechanism (deleting old workflow runs that did not run the did not trigger the schedule event test job due to lack of corresponding end-to-end tests branches).
An alternative approach would be to test the main branch only once a day or so, but then we would not be immediately alerted when a pr breaks schedule event support, which may be fine as we do not immediately promote releases to stable.

A test every 5 mins seems quite frequent. Is there a reason for it? Would a test every hour cause any problems?

@yhaliaw , could you please have a look if you are happy with the schedule test approach. This would currently mean that a schedule workflow would run every 5 minutes. We may need an additional cleanup mechanism (deleting old workflow runs that did not run the did not trigger the schedule event test job due to lack of corresponding end-to-end tests branches).
An alternative approach would be to test the main branch only once a day or so, but then we would not be immediately alerted when a pr breaks schedule event support, which may be fine as we do not immediately promote releases to stable.

A test every 5 mins seems quite frequent. Is there a reason for it? Would a test every hour cause any problems?

The end-to-end test (not included in this draft PR) triggered by a PR will have to wait for the schedule. So if we set it to one hour, the end-to-end test would take a very long time.

The end-to-end test is now implemented by using a different repo for the schedule test. The PR description has been updated.


compileText function signature changed

The "compileText" function does not work anymore as shown in the example, the signature is different. Breaks legacy code.

Finally merged the v2 branch into master and added a lot of README stuff reflecting the changes.


[FasterLog] Linux crash during long-running tests

The FasterLogSample program (with latest from master) is incredibly stable on Windows with both the native PInvoke-based LocalStorageDevice and the FileStream-based .NET core compatible ManagedLocalStorageDevice. However, when we run it on Linux (actual Linux - WSL is not supported), the program crashes during a scan after a while.
My suspicion is: when we commit frequently so that there may be more than one commit within the same page, the first partial page commit may be getting persisted on disk only after the second commit, leading to zeroes in the log. In the code, we make sure the first flush's callback is called before the second adjacent flush is issued, so I am not sure why this would occur. Is there some write caching going on? Here is how we create the file: https://github.com/microsoft/FASTER/blob/98889aeea31041aa03c056c61abfd3e559d53a21/cs/src/core/Device/ManagedLocalStorageDevice.cs#L362
It appears that there is a problem with ManagedLocalStorageDevice in the assumptions it makes on Linux. If any Linux .NET core folks have ideas here, let us know.
To repro on Linux:
cd FASTER/cs/playground/FasterLogSample
# update file path in Program.cs
dotnet run

Tracked the issue to this: if we issue more than one WriteAsync call in parallel, on non-Windows, using the same log handle, the writes seem to get corrupted, with zero bytes present. This seems to occur only with frequent commits, which causes many partial pages to be flushed to storage.
As a solution, we have now made it so that a WriteAsync on non-Windows prevents any other WriteAsync being issued on the same handle, until the first WriteAsync enters its completion callback. This restores correct behavior for the long-running testcase above.
A clearer understanding of async file IO and .NET core on non-Windows is left for future investigation.


How to prevent access tokens being added on particular addresses?

BaseAddressAuthorizationMessageHandler looks like it requires AccessTokens on any address that is within the base address.
Forgive me if this is described within and I missed it, but I am looking for how best to support certain server API routes being accessed without being logged in. How is this done?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9816eaee-5eff-c3c8-5d58-e2c02c760a00
Version Independent ID: 60992d09-2a04-1d10-4c85-9642b20ff0e3
Content: Secure an ASP.NET Core Blazor WebAssembly hosted app with Azure Active Directory
Content Source: aspnetcore/security/blazor/webassembly/hosted-with-azure-active-directory.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @guardrex
Microsoft Alias: riande

support certain server API routes being accessed without being logged in

Configure a named HttpClient for it ...
https://docs.microsoft.com/en-us/aspnet/core/security/blazor/webassembly/additional-scenarios?view=aspnetcore-3.1#unauthenticated-or-unauthorized-web-api-requests-in-an-app-with-a-secure-default-client

@taylorchasewhite You could also write your own AuthorizationMessageHandler, and be explicit on the urls that require authorization.
public sealed class CustomAuthorizationMessageHandler : AuthorizationMessageHandler
{
    public CustomAuthorizationMessageHandler(
        IAccessTokenProvider provider,
        NavigationManager navigation
        )
        : base(provider, navigation)
    {
        var authorizationRequiredUrls = new[]
        {
            getAbsoluteUrl("api/Product/"),
            getAbsoluteUrl("api/Account/")
        };

        ConfigureHandler(authorizationRequiredUrls);

        string getAbsoluteUrl(string relativeUrl)
        {
            return $"{navigation.BaseUri}{relativeUrl}";
        }
    }
}


Fix concurrency in ES client message buffer

"fatal error: concurrent map writes"
/go/src/github.com/infrawatch/sg-core/plugins/application/elasticsearch/main.go:95
/go/src/github.com/infrawatch/sg-core/pkg/bus.go:65 calls Application callbacks as a goroutine which results in concurrency in ReceiveEvent(). I've added a mutex to protect access.

I've tested this and it fixes the problem; I can put 100k logs through the system and it doesn't crash, whereas before the fix (and when my fix didn't include protection for the initialization on L95) it would reliably crash before the first 10k. I am planning to compare it vs. https://github.com/infrawatch/sg-core/pull/53 (developed concurrently) to see if there are any performance differences. I would expect this one to be faster anyways, but it's worth a shot just to see.

I'll be testing https://github.com/infrawatch/sg-core/pull/53 and will prefer it if there is no obvious penalty.

The golang recommendation is to lock data types rather than methods because it helps to keep future developers from introducing concurrency bugs

Lol - except we already did that and the bug came anyways, right?

No? Not sure where you mean

No? Not sure where you mean

I mean we already had a locked datatype at hand, but the concurrency bug appeared anyways since it wasn't used. I understand you meant something slightly different.
In any case, I'm trying to pull together a lab to test this today. Hope to merge by EOD

Closed in favor of https://github.com/infrawatch/sg-core/pull/53


Update some extension icon

Description

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

This should actually be split into separate PRs so the authors can approve. Do you want me to do that?


feature/BA-961

Bootstrap 4 Styling - Update capabilities module
Fixes BA-961

I made the required change in my local branch and pushed to Dev.


Readonly attribute reduces the height of the input

The read-only attribute reduces the height of the input if the input has no value

fixed by adding a default min-height


Bypass RSEs out of quota for RelVal input data placement in MSTransferor

Impact of the new feature
MSTransferor
Is your feature request related to a problem? Please describe.
Yes, right now RSEs quota (and rucio account) are shared between central production and release validation, thus a busy central production requiring a large volume of input data might block relval input data placement from happening.
Describe the solution you'd like
The expected short-term solution is:

identify RelVal workflows in MSTransferor and skip the check on RSEs out of quota, meaning a rule will be created regardless whether there is enough quota or not;
in addition to that, we decided to somehow "mark" those rules, such that we can add some input data cleanup logic to distinguish them. Nick suggested the usage of the meta rule attribute for that. We could use something like:

meta=dict(workflow_type="RelVal")

and a value of Production otherwise (or Processing, I'm not really sure!)
Describe alternatives you've considered
A longer term solution will be a account and quota separation for central production and release validation.
Additional context
This has been discussed and agreed on the Rucio Transition meeting.

It might be better to use workflow_group=relval or workflow_group=processing, just so we can avoid overloading the term "workflow type" or "request type", which has different meanings.


Error for filenames containing any character outside of acceptable character set

In order to conform to CDS standards, generate an error for any filename that contains a character outside of the following set:
a-z
A-Z
0-9
period(.)
dash (-)
underscore (_)

@alexeliotlash going to work on this one next.  can you confirm this is still needed?

this is now in progress.  See new validation messages at:  https://hdash.website-us-east-1.linodeobjects.com/index.html

This is now fixed and deployed!


pointer_to_array deprecated to unsafe_wrap

When running the test batteries (e.g. smallcrushTestU01), I get the following error:
ERROR: LoadError: LoadError: UndefVarError: pointer_to_array not defined

Hopefully changing pointer_to_array to unsafe_wrap(Array, ...) is the right fix here.
I did this somewhat blindly.
Hoping someone can confirm this is correct.
Also added a test for smallcrushTestU01, which doesn't take too long.

Thanks. There was an issue with the inner constructor syntax on 0.7 that made the tests fail so I added a fix for that.


Prefer OTLP object fields over attributes on ingest

Today, we can overwrite actual OTLP fields with attributes that have the same name. For example, name is how Honeycomb tracks a span name, but if you have a custom field called name, then this overrides the span's name on the event that we create.
Because of how Honeycomb's event model works, events are just a collection of fields, and we don't distinguish between those that came from OTLP vs. those that are attributes. And in our code, we first copy over the OTLP fields, and then the attributes. The attributes can override.
We should copy over the OTLP fields at the end instead. This has the downside of technically being a breaking change -- however, the reason for overriding these names may not be intentional by users.

Using the K8s Attributes Processor from the Collector, we had a team add a name label the pods of a service. This resulted in all spans being named the pod name in traces, because the Processor had copied the pod label to a resource attribute, and then in the UI that resource attribute, name, overwrote the name being sent as a Span attribute by the service.


ci: fix multus installation

[x] Make sure you have followed Kube-OVN Code Style.

What type of this PR

CI

Which issue(s) this PR fixes:
Fixes #(issue-number)
WHAT

🤖 Generated by Copilot at fa7858e
Updated MULTUS_IMAGE in Makefile to use snapshot tag. This is to test kube-ovn with the latest multus-cni version.

🤖 Generated by Copilot at fa7858e

MULTUS_IMAGE changed
To test kube-ovn with snapshot
MULTUS_YAML same

HOW

🤖 Generated by Copilot at fa7858e

Update multus-cni image to use snapshot tag (link)

Any issue with the multus stable image?

We are using yaml from the master branch, which has changed the image tag from stable to snapshot.
This patch is supposed to fix the occasional multus installation failure:
https://github.com/kubeovn/kube-ovn/actions/runs/4624461863/jobs/8179433733