Add Twirp support

See kolide/launcher#245.

Is there any update on this potentially shipping? AIUI this would be a significant usability improvement for people attempting to deploy on AWS.

@patrickod I'd love to land this, but we need the PR to not pin to forks of Launcher and Go-Kit.

From @groob to @austinylin in Slack on April 27, 2018 on the topic of landing this PR:

Hey! Wanted to get your feedback. I was thinking of a few options.

the go-kit PR has some feedback from the contributors. Idk what your thoughts/availability is to continue pushing it through code review. I’m pretty active in that space and wouldn’t mind opening a separate PR and driving it to a conclusion. But it’s your PR and I’d only want to do this if you’re too busy, uninterested or don’t care about getting the credit for the contribution :)
go-kit is just a bunch of libraries. To land support for twirp as a transport the go package itself doesn’t have to live within that namespace. we can keep your current but working prototype of the transport somewhere in a third party space. Then we can merge the transport options to fleet/launcher and refactor the transport further when the upstream changes are merged/final. This might also be a good option because we’d have some real feedback about usage to create consensus around the APIs.

Your PRs in launcher and fleet are good quality code and a lot of folks in the community have expressed interest in having these changes landed. So I’m happy to explore either of the above, or a third option.

I'm closing this due to inactivity. @austinylin if you're able to circle back on this, we would love to re-open this PR and get this merged one of these days.


PKCS8 Error: Asn1 HeaderDisallowed Error when Decrypting Private Key in Elixir, but Successful in Python

Hi, thanks for sharing this project! I've been trying to use the recipe, but unfortunately, I haven't been able to get them working as expected. The output I'm seeing seems to be related to the Rust implementation, which I'm not too familiar with.
Interestingly, when I tried to replicate the same functionality in Python using the same data, I was able to get it working successfully.
data = %{
      "encrypted_flow_data" =>    "23....xS1X",
      "encrypted_aes_key" =>  "C7RUBAY9QpMH9S..LCMwdQ==",
      "initial_vector" => "fAkA...Q=="
    }

{:ok, private_key_pem} = File.read(".certs/private.pem")

WhatsappFlowCrypto.fetch_private_key(private_key_pem, passphrase)

PKCS8 error: Asn1(Error { kind: Pem(HeaderDisallowed), position: None })
{:error, :decoding}

import json
from base64 import b64decode, b64encode
from cryptography.hazmat.primitives.asymmetric.padding import OAEP, MGF1, hashes
from cryptography.hazmat.primitives.ciphers import algorithms, Cipher, modes
from cryptography.hazmat.primitives.serialization import load_pem_private_key

def decrypt_request(data: dict, private_key: str, passphrase: str):
    # Read the request fields
    encrypted_flow_data_b64 = data[b'encrypted_flow_data'].decode("utf-8")
    encrypted_aes_key_b64 = data[b'encrypted_aes_key'].decode("utf-8")
    initial_vector_b64 = data[b'initial_vector'].decode("utf-8")

    flow_data = b64decode(encrypted_flow_data_b64)
    iv = b64decode(initial_vector_b64)

    # Decrypt the AES encryption key
    encrypted_aes_key = b64decode(encrypted_aes_key_b64)

    private_key = load_pem_private_key(private_key, password=passphrase)
    aes_key = private_key.decrypt(encrypted_aes_key, OAEP(
        mgf=MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None))

    # Decrypt the Flow data
    encrypted_flow_data_body = flow_data[:-16]
    encrypted_flow_data_tag = flow_data[-16:]
    decryptor = Cipher(algorithms.AES(aes_key),
                       modes.GCM(iv, encrypted_flow_data_tag)).decryptor()
    decrypted_data_bytes = decryptor.update(
        encrypted_flow_data_body) + decryptor.finalize()
    decrypted_data = json.loads(decrypted_data_bytes.decode("utf-8"))
    return decrypted_data, aes_key, iv
    ```

I think, the encrypted private key uses a chipper that is not supported. For example, the DES3 cipher is not supported.

As a workaround you can remove the encryption from the private key.

Works like a charm!
A few notes on the tweaks I made to get it running smoothly:

Extracted the unencrypted version of my private.pem.
Removed all spacing from the keys within the data (the request from Meta).
I updated a local copy of the project dependency from :json to jason 1.4 for compatibility.

openssl rsa -in private.pem -out private_unencrypted.pem

  # Meta encrypted data
   data = %{
      "encrypted_flow_data" => "23Oj6TJZsqJiow5YW......oUJxS1X",
      "encrypted_aes_key" => "C7RUBA...qmd2DLCMwdQ==",
      "initial_vector" => "fAkALM....LdQ=="
    }

    encrypted_flow_data = data["encrypted_flow_data"]
    encrypted_aes_key = data["encrypted_aes_key"]
    initial_vector = data["initial_vector"]

    {:ok, private_key_pem} = File.read("certs/private_unencrypted.pem")

    {:ok, ref} = WhatsappFlowCrypto.fetch_private_key(private_key_pem)

    WhatsappFlowCrypto.decrypt_request(ref, encrypted_aes_key, initial_vector, encrypted_flow_data)

# Response fragment
response =  %{
        "version" => result["version"],
        "action" => result["action"],
        "screen" => "SUCCESS",
        "data" => %{
            "extension_message_response" => %{
                "params" => %{
                    "flow_token" => result["flow_token"]
                }
            }
        }
    }

WhatsappFlowCrypto.encrypt_response(aes_key, initial_vector, response)

"ytDoGowFRn..."

I close this issue for now.


Closing an app crash when dropping assets.

Description
Exiting an application crashes when dropping assets. In the screenshot it is on a sprite but if we remove the sprites it will be on a texture.
Platform / Environment
rust binding. Linux 24.04 gnome wayland

I wasted hours searching because I thought it was a multi-threading problem before testing my basic template which has the problem. A really painful bug.

Exiting an application crashes when dropping assets.

Could you give a few more details about this? Are you dropping assets after StereoKit has shut down, or is this just within the main stepping loop? I haven't seen this issue at all, how can I recreate this?

These are the rust drops that occur after the last line of code. So far they haven't caused any problems. And I don't have this error with the demo examples. But I understand what's the problem now.

Ok I removed sk_shutdown() from the Sk.drop() and the problem is solved. The sk_shutdown will have to be called after the loop. Rust should follow the order of variable creation during the Drop. But I use a Winit helper which drops Sk before everyone else.


When inferring with PyTritonAdapter, the results are different.

import model_navigator as nav
package = nav.package.load("package.nav")
pytriton_adapter = nav.pytriton.PyTritonAdapter(
    package=package, strategy=nav.MaxThroughputStrategy()
) # OnnxCUDARuntime is applied.
model_runner = pytriton_adapter.runner
model_runner.activate()

ort_sess = ort.InferenceSession("navigator_workspace/onnx/model.onnx")

output1 = ort_sess.run(None, {
    "input_values": data[0].numpy(),
})
output2 = model_runner.infer({
    "input_values": data[0].numpy()
})

output1 and output2 are sharply different. Even though the graph is in the navigator workspace.

Hi @caffeinism. Could you share the providers configured for session?
ort_sess = ort.InferenceSession("navigator_workspace/onnx/model.onnx")

Based on documentation you need to specify the execution provider explicitly since ONNXRuntime 1.10. Otherwise the CPU is used by default: https://onnxruntime.ai/docs/api/python/api_summary.html#load-and-run-a-model

Aha I was ignorant about ONNX. After rerunning, the difference with ONNX seems to be less than 1%.


added custom message in failure

TestFailure/TestError should report the custom error text message as specified in the check.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Emanuele Ruffaldi seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


RedisTimeoutException: Unable to acquire connection after Redis cluster back to normal

my redisson version:3.12.3
redisson client:
config.setThreads(128).setNettyThreads(128).setCodec(new FstCodec()).setTransportMode(TransportMode.NIO)
.setLockWatchdogTimeout(15000)
.useClusterServers()
.setRetryAttempts(retryAttempts)
.setPassword(StringUtils.isBlank(redisPwd)?null:redisPwd)
.setLoadBalancer(new RoundRobinLoadBalancer())
.setSubscriptionConnectionPoolSize(200)
.setSubscriptionConnectionMinimumIdleSize(5)
.setSlaveConnectionPoolSize(Integer.parseInt(redisPoolSize)) //redisPoolSize = 512
.setMasterConnectionPoolSize(Integer.parseInt(redisPoolSize))
.setReadMode(ReadMode.SLAVE)
.setSubscriptionMode(SubscriptionMode.SLAVE)
.setPingConnectionInterval(0).setKeepAlive(false).setTcpNoDelay(false)
.addNodeAddress(redisArraynew);
return Redisson.create(config);
I use redissonMap to caching data and use RScheduledExecutorService to schedule tasks. Why there's no connection to use  ? Looks for your help, thanks.
My application error:
2020-12-29 06:02:47.279 [pool-6-thread-1] ERROR RedisCacheUtils [RedisCacheUtils.java:540] - org.redisson.client.RedisTimeoutException: Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=4568, addr=redis://<IP_ADDRESS>:6379, redisClient=null, redirect=MOVED, entry=null], command: (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false) then redis.call('publish', KEYS..., 2, {v103_cache_tbl}:b2Qvj7NBl3bGr/xULuMlIQ:rw_lock, redisson_rwlock:{v103_cache_tbl}:b2Qvj7NBl3bGr/xULuMlIQ:rw_lock, 1, 15000, e610596c-cb9f-4603-b593-b31f470ef756:172:write] after 0 retry attempts
CommonException: org.redisson.client.RedisTimeoutException: Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=4568, addr=redis://<IP_ADDRESS>:6379, redisClient=null, redirect=MOVED, entry=null], command: (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false) then redis.call('publish', KEYS..., 2, {v103_cache_tbl}:b2Qvj7NBl3bGr/xULuMlIQ:rw_lock, redisson_rwlock:{v103_cache_tbl}:b2Qvj7NBl3bGr/xULuMlIQ:rw_lock, 1, 15000, e610596c-cb9f-4603-b593-b31f470ef756:172:write] after 0 retry attempts
RedisCacheUtils.lambda$init$20(RedisCacheUtils.java:537)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.redisson.client.RedisTimeoutException: Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=4568, addr=redis://<IP_ADDRESS>:6379, redisClient=null, redirect=MOVED, entry=null], command: (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false) then redis.call('publish', KEYS..., 2, {v103_cache_tbl}:b2Qvj7NBl3bGr/xULuMlIQ:rw_lock, redisson_rwlock:{v103_cache_tbl}:b2Qvj7NBl3bGr/xULuMlIQ:rw_lock, 1, 15000, e610596c-cb9f-4603-b593-b31f470ef756:172:write] after 0 retry attempts
at org.redisson.command.RedisExecutor$2.run(RedisExecutor.java:180)
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:682)
at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:757)
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:485)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
... 1 common frames omitted
2020-12-29 06:11:58.381 [pool-7-thread-1] ERROR RedisCacheUtils [RedisCacheUtils.java:552] - Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=381, addr=null, redisClient=null, redirect=null, entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=0, freeSubscribeConnectionsCounter=value:200:queue:0, freeConnectionsAmount=24, freeConnectionsCounter=value:1024:queue:0, freezed=false, freezeReason=null, client=[addr=redis://<IP_ADDRESS>:6380], nodeType=MASTER, firstFail=0]]], command: (HKEYS), params: [v103_sentry_cache] after 0 retry attempts
org.redisson.client.RedisTimeoutException: Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=381, addr=null, redisClient=null, redirect=null, entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=0, freeSubscribeConnectionsCounter=value:200:queue:0, freeConnectionsAmount=24, freeConnectionsCounter=value:1024:queue:0, freezed=false, freezeReason=null, client=[addr=redis://<IP_ADDRESS>:6380], nodeType=MASTER, firstFail=0]]], command: (HKEYS), params: [v103_sentry_cache] after 0 retry attempts
at org.redisson.command.RedisExecutor$2.run(RedisExecutor.java:180)
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:682)
at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:757)
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:485)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
2020-12-29 06:12:44.188 [pool-6-thread-1] ERROR RedisCacheUtils [RedisCacheUtils.java:540] - org.redisson.client.RedisTimeoutException: Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=4568, addr=redis://<IP_ADDRESS>:6379, redisClient=null, redirect=MOVED, entry=null], command: (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false) then redis.call('hset', KEYS[1]..., 1, {v103_cache_tbl}:7swFf8RGPkVjjO6j8DrkYQ:rw_lock, 15000, e610596c-cb9f-4603-b593-b31f470ef756:172:write] after 0 retry attempts
CommonException: org.redisson.client.RedisTimeoutException: Unable to acquire connection! Increase connection pool size and/or retryInterval settings Node source: NodeSource [slot=4568, addr=redis://<IP_ADDRESS>:6379, redisClient=null, redirect=MOVED, entry=null], command: (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false) then redis.call('hset', KEYS[1]..., 1, {v103_cache_tbl}:7swFf8RGPkVjjO6j8DrkYQ:rw_lock, 15000, e610596c-cb9f-4603-b593-b31f470ef756:172:write] after 0 retry attempts
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
redis cluster log:
master1:
22453:S 29 Dec 06:00:31.187 * Background saving terminated with success
22453:S 29 Dec 06:03:36.058 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
22453:S 29 Dec 06:05:32.040 * 10 changes in 300 seconds. Saving...
slave1
2648:S 29 Dec 05:56:34.100 * Background AOF rewrite terminated with success
22648:S 29 Dec 05:56:34.101 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
22648:S 29 Dec 05:56:34.101 * Background AOF rewrite finished successfully
22648:S 29 Dec 05:57:25.008 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
22648:S 29 Dec 05:58:03.059 * 10 changes in 300 seconds. Saving...
22648:S 29 Dec 05:58:03.061 * Background saving started by pid 5394
5394:C 29 Dec 05:58:03.200 * DB saved on disk
5394:C 29 Dec 05:58:03.202 * RDB: 0 MB of memory used by copy-on-write
22648:S 29 Dec 05:58:03.261 * Background saving terminated with success
22648:S 29 Dec 06:03:04.039 * 10 changes in 300 seconds. Saving...
master2:
25990:M 29 Dec 05:53:58.201 * Background saving terminated with success
25990:M 29 Dec 05:56:09.391 * Marking node cf2733775061da5d63eaef8ac0fc38bcdd0db410 as failing (quorum reached).
25990:M 29 Dec 05:56:09.722 * Marking node ff6259256766f595afb6c887eaf51a04c4096583 as failing (quorum reached).
25990:M 29 Dec 05:56:11.307 * Clear FAIL state for node cf2733775061da5d63eaef8ac0fc38bcdd0db410: slave is reachable again.
25990:M 29 Dec 05:56:12.312 # Failover auth granted to cf2733775061da5d63eaef8ac0fc38bcdd0db410 for epoch 84
25990:M 29 Dec 05:56:14.034 * Clear FAIL state for node ff6259256766f595afb6c887eaf51a04c4096583: slave is reachable again.
25990:M 29 Dec 05:56:58.036 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
25990:M 29 Dec 05:58:59.050 * 10 changes in 300 seconds. Saving...
25990:M 29 Dec 05:58:59.051 * Background saving started by pid 20065
20065:C 29 Dec 05:58:59.097 * DB saved on disk
20065:C 29 Dec 05:58:59.098 * RDB: 0 MB of memory used by copy-on-write
25990:M 29 Dec 05:58:59.151 * Background saving terminated with success
25990:M 29 Dec 06:04:00.039 * 10 changes in 300 seconds. Saving...
slave2:
6251:S 29 Dec 05:56:08.713 * Marking node ff6259256766f595afb6c887eaf51a04c4096583 as failing (quorum reached).
26251:S 29 Dec 05:56:09.392 * FAIL message received from 8d50b5a9bc578993b77aa729294217a37f80e183 about cf2733775061da5d63eaef8ac0fc38bcdd0db410
26251:S 29 Dec 05:56:11.307 * Clear FAIL state for node cf2733775061da5d63eaef8ac0fc38bcdd0db410: slave is reachable again.
26251:S 29 Dec 05:56:13.188 * Clear FAIL state for node ff6259256766f595afb6c887eaf51a04c4096583: master without slots is reachable again.
26251:S 29 Dec 05:56:58.084 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
26251:S 29 Dec 05:57:03.085 * 10 changes in 300 seconds. Saving...
26251:S 29 Dec 05:57:03.086 * Background saving started by pid 18641
18641:C 29 Dec 05:57:03.371 * DB saved on disk
18641:C 29 Dec 05:57:03.372 * RDB: 0 MB of memory used by copy-on-write
26251:S 29 Dec 05:57:03.386 * Background saving terminated with success
26251:S 29 Dec 06:02:04.067 * 10 changes in 300 seconds. Saving...
26251:S 29 Dec 06:02:04.068 * Background saving started by pid 22346
master3:
21463:M 29 Dec 05:56:12.674 * Starting BGSAVE for SYNC with target: disk
21463:M 29 Dec 05:56:12.677 * Background saving started by pid 8971
8971:C 29 Dec 05:56:12.852 * DB saved on disk
8971:C 29 Dec 05:56:12.854 * RDB: 1 MB of memory used by copy-on-write
21463:M 29 Dec 05:56:12.908 * Background saving terminated with success
21463:M 29 Dec 05:56:12.919 * Synchronization with slave <IP_ADDRESS>:6380 succeeded
21463:M 29 Dec 05:56:14.010 * Clear FAIL state for node ff6259256766f595afb6c887eaf51a04c4096583: slave is reachable again.
21463:M 29 Dec 05:57:02.028 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
21463:M 29 Dec 06:01:13.058 * 10 changes in 300 seconds. Saving...
21463:M 29 Dec 06:01:13.077 * Background saving started by pid 14460
14460:C 29 Dec 06:01:13.312 * DB saved on disk
14460:C 29 Dec 06:01:13.315 * RDB: 1 MB of memory used by copy-on-write
21463:M 29 Dec 06:01:13.378 * Background saving terminated with success
slave3:
21705:M 29 Dec 05:54:45.131 * Background saving terminated with success
21705:M 29 Dec 05:56:09.391 * FAIL message received from 8d50b5a9bc578993b77aa729294217a37f80e183 about cf2733775061da5d63eaef8ac0fc38bcdd0db410
21705:M 29 Dec 05:56:09.715 * Marking node ff6259256766f595afb6c887eaf51a04c4096583 as failing (quorum reached).
21705:M 29 Dec 05:56:11.305 * Clear FAIL state for node cf2733775061da5d63eaef8ac0fc38bcdd0db410: slave is reachable again.
21705:M 29 Dec 05:56:12.311 # Failover auth granted to cf2733775061da5d63eaef8ac0fc38bcdd0db410 for epoch 84
21705:M 29 Dec 05:56:14.002 * Clear FAIL state for node ff6259256766f595afb6c887eaf51a04c4096583: slave is reachable again.
21705:M 29 Dec 05:59:46.078 * 10 changes in 300 seconds. Saving...
21705:M 29 Dec 05:59:46.085 * Background saving started by pid 12375
12375:C 29 Dec 05:59:46.111 * DB saved on disk
12375:C 29 Dec 05:59:46.111 * RDB: 0 MB of memory used by copy-on-write
21705:M 29 Dec 05:59:46.185 * Background saving terminated with success
21705:M 29 Dec 06:03:29.010 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
21705:M 29 Dec 06:04:47.051 * 10 changes in 300 seconds. Saving...
21705:M 29 Dec 06:04:47.052 * Background saving started by pid 17249
17249:C 29 Dec 06:04:47.074 * DB saved on disk
17249:C 29 Dec 06:04:47.074 * RDB: 0 MB of memory used by copy-on-write
21705:M 29 Dec 06:04:47.152 * Background saving terminated with success

port 6379 should be master and port 6380 should be slave.
Seems my redis cluster had a master-slave switch after back to normal:
cf2733775061da5d63eaef8ac0fc38bcdd0db410 <IP_ADDRESS>:6379 slave ff6259256766f595afb6c887eaf51a04c4096583 0<PHONE_NUMBER>184 96 connected
9a18ffa9db843a6ce636fe8d7359f70cec59a307 <IP_ADDRESS>:6379 myself,master - 0 0 100 connected 5461-10922
21fbfe9a4b35d9e78ca8c199ab8983ceafbe4116 <IP_ADDRESS>:6380 slave 9a18ffa9db843a6ce636fe8d7359f70cec59a307 0<PHONE_NUMBER>188 100 connected
ff6259256766f595afb6c887eaf51a04c4096583 <IP_ADDRESS>:6380 master - 0<PHONE_NUMBER>185 96 connected 0-5460
c53b93ed799da727005832f1ae52c48f71864c4f <IP_ADDRESS>:6380 slave 8d50b5a9bc578993b77aa729294217a37f80e183 0<PHONE_NUMBER>685 90 connected
8d50b5a9bc578993b77aa729294217a37f80e183 <IP_ADDRESS>:6379 master - 0<PHONE_NUMBER>184 90 connected 10923-16383

did you resolve the issue?

did you resolve the issue?

did you resolve the issue?

No, still have problem.
when try to read key named "common_service_cache_configuration" failed. and the redis node try to connecting is the failed one
but now back again. the key in the slot can query from redis client but cannot by redisson. I have no idea about this.

25990:M 31 Dec 03:05:34.033 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
25990:M 31 Dec 03:05:45.036 * FAIL message received from 21fbfe9a4b35d9e78ca8c199ab8983ceafbe4116 about ff6259256766f595afb6c887eaf51a04c4096583
25990:M 31 Dec 03:05:45.036 * FAIL message received from cf2733775061da5d63eaef8ac0fc38bcdd0db410 about c53b93ed799da727005832f1ae52c48f71864c4f
25990:M 31 Dec 03:05:45.142 * Clear FAIL state for node ff6259256766f595afb6c887eaf51a04c4096583: slave is reachable again.
25990:M 31 Dec 03:05:45.839 # Failover auth denied to c53b93ed799da727005832f1ae52c48f71864c4f: its master is up
25990:M 31 Dec 03:05:45.864 # Connection with slave <IP_ADDRESS>:6380 lost.
25990:M 31 Dec 03:05:45.881 # Configuration change detected. Reconfiguring myself as a replica of c53b93ed799da727005832f1ae52c48f71864c4f
25990:S 31 Dec 03:05:46.035 * Connecting to MASTER <IP_ADDRESS>:6380
25990:S 31 Dec 03:05:46.035 * MASTER <-> SLAVE sync started
25990:S 31 Dec 03:05:46.035 * Non blocking connect for SYNC fired the event.
25990:S 31 Dec 03:05:46.036 * Master replied to PING, replication can continue...
25990:S 31 Dec 03:05:46.036 * Partial resynchronization not possible (no cached master)
25990:S 31 Dec 03:05:46.037 * Full resync from master: 2fc3269a640ac24ece68ed9dac6edf214b11ecf0:199501762
25990:S 31 Dec 03:05:46.136 * MASTER <-> SLAVE sync: receiving 1086166 bytes from master
25990:S 31 Dec 03:05:46.140 * MASTER <-> SLAVE sync: Flushing old data
25990:S 31 Dec 03:05:46.143 * MASTER <-> SLAVE sync: Loading DB in memory
25990:S 31 Dec 03:05:46.158 * MASTER <-> SLAVE sync: Finished with success
25990:S 31 Dec 03:05:46.163 * Background append only file rewriting started by pid 24966
25990:S 31 Dec 03:05:46.235 # Start of election delayed for 538 milliseconds (rank #0, offset 199501762).
25990:S 31 Dec 03:05:46.240 * AOF rewrite child asks to stop sending diffs.
24966:C 31 Dec 03:05:46.240 * Parent agreed to stop sending diffs. Finalizing AOF...
24966:C 31 Dec 03:05:46.241 * Concatenating 0.00 MB of AOF diff received from parent.
24966:C 31 Dec 03:05:46.241 * SYNC append only file rewrite performed
24966:C 31 Dec 03:05:46.243 * AOF rewrite: 0 MB of memory used by copy-on-write
25990:S 31 Dec 03:05:46.336 * Background AOF rewrite terminated with success
25990:S 31 Dec 03:05:46.336 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
25990:S 31 Dec 03:05:46.336 * Background AOF rewrite finished successfully
25990:S 31 Dec 03:05:46.837 # Starting a failover election for epoch 143.
25990:S 31 Dec 03:05:55.058 # Currently unable to failover: Waiting for votes, but majority still not reached.
25990:S 31 Dec 03:05:55.459 * Clear FAIL state for node c53b93ed799da727005832f1ae52c48f71864c4f: is reachable again and nobody is serving its slots after some time.
2021-01-04 15:46:09.187 [redisson-timer-4-1] DEBUG org.redisson.command.RedisExecutor [RedisExecutor.java:237] - attempt 12 for command (HGET) and params [common_service_cache_configuration, PooledUnsafeDirectByteBuf(ridx: 0, widx: 9, cap: 256)]
2021-01-04 15:46:09.187 [redisson-timer-4-1] DEBUG org.redisson.command.RedisExecutor [RedisExecutor.java:612] - acquired connection for command (HGET) and params [common_service_cache_configuration, PooledUnsafeDirectByteBuf(ridx: 0, widx: 9, cap: 256)] from slot NodeSource [slot=13203, addr=null, redisClient=null, redirect=null, entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=5, freeSubscribeConnectionsCounter=value:200:queue:0, freeConnectionsAmount=24, freeConnectionsCounter=value:2048:queue:0, freezed=false, freezeReason=null, client=[addr=redis://<IP_ADDRESS>:6379], nodeType=MASTER, firstFail=0]]] using node <IP_ADDRESS>/<IP_ADDRESS>:6379... RedisConnection@1096414064 [redisClient=[addr=redis://<IP_ADDRESS>:6379], channel=[id: 0x893cb8d3, L:/<IP_ADDRESS>:59794 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6379], currentCommand=null]
2021-01-04 15:46:09.190 [scheduling-1] ERROR org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler [TaskUtils.java:96] - Unexpected error occurred in scheduled task.
org.redisson.client.WriteRedisConnectionException: Unable to write command into connection! Node source: NodeSource [slot=13203, addr=null, redisClient=null, redirect=null, entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=5, freeSubscribeConnectionsCounter=value:200:queue:0, freeConnectionsAmount=24, freeConnectionsCounter=value:2048:queue:0, freezed=false, freezeReason=null, client=[addr=redis://<IP_ADDRESS>:6379], nodeType=MASTER, firstFail=0]]], connection: RedisConnection@1096414064 [redisClient=[addr=redis://<IP_ADDRESS>:6379], channel=[id: 0x893cb8d3, L:/<IP_ADDRESS>:59794 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6379], currentCommand=null], command: (HGET), params: [common_service_cache_configuration, PooledUnsafeDirectByteBuf(ridx: 0, widx: 9, cap: 256)] after 12 retry attempts
at org.redisson.command.RedisExecutor.checkWriteFuture(RedisExecutor.java:270)
at org.redisson.command.RedisExecutor.access$100(RedisExecutor.java:58)
at org.redisson.command.RedisExecutor$1.operationComplete(RedisExecutor.java:155)
at org.redisson.command.RedisExecutor$1.operationComplete(RedisExecutor.java:152)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:502)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:476)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:415)
at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:540)
at io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:533)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:114)
at io.netty.channel.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:1018)
at io.netty.channel.AbstractChannel$AbstractUnsafe.write(AbstractChannel.java:874)
at io.netty.channel.DefaultChannelPipeline$HeadContext.write(DefaultChannelPipeline.java:1365)
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:706)
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:698)
at io.netty.channel.AbstractChannelHandlerContext.access$1700(AbstractChannelHandlerContext.java:38)
at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.write(AbstractChannelHandlerContext.java:1091)
at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.write(AbstractChannelHandlerContext.java:1138)
at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.run(AbstractChannelHandlerContext.java:1062)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:495)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:905)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
Caused by: io.netty.channel.ExtendedClosedChannelException: null
at io.netty.channel.AbstractChannel$AbstractUnsafe.write(...)(Unknown Source)

did you resolve the issue?

No, still have problem.
when try to read key named "common_service_cache_configuration" failed. and the redis node try to connecting is the failed one
but now back again. the key in the slot can query from redis client but cannot by redisson. I have no idea about this.

25990:M 31 Dec 03:05:34.033 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
25990:M 31 Dec 03:05:45.036 * FAIL message received from 21fbfe9a4b35d9e78ca8c199ab8983ceafbe4116 about ff6259256766f595afb6c887eaf51a04c4096583
25990:M 31 Dec 03:05:45.036 * FAIL message received from cf2733775061da5d63eaef8ac0fc38bcdd0db410 about c53b93ed799da727005832f1ae52c48f71864c4f
25990:M 31 Dec 03:05:45.142 * Clear FAIL state for node ff6259256766f595afb6c887eaf51a04c4096583: slave is reachable again.
25990:M 31 Dec 03:05:45.839 # Failover auth denied to c53b93ed799da727005832f1ae52c48f71864c4f: its master is up
25990:M 31 Dec 03:05:45.864 # Connection with slave <IP_ADDRESS>:6380 lost.
25990:M 31 Dec 03:05:45.881 # Configuration change detected. Reconfiguring myself as a replica of c53b93ed799da727005832f1ae52c48f71864c4f
25990:S 31 Dec 03:05:46.035 * Connecting to MASTER <IP_ADDRESS>:6380
25990:S 31 Dec 03:05:46.035 * MASTER <-> SLAVE sync started
25990:S 31 Dec 03:05:46.035 * Non blocking connect for SYNC fired the event.
25990:S 31 Dec 03:05:46.036 * Master replied to PING, replication can continue...
25990:S 31 Dec 03:05:46.036 * Partial resynchronization not possible (no cached master)
25990:S 31 Dec 03:05:46.037 * Full resync from master: 2fc3269a640ac24ece68ed9dac6edf214b11ecf0:199501762
25990:S 31 Dec 03:05:46.136 * MASTER <-> SLAVE sync: receiving 1086166 bytes from master
25990:S 31 Dec 03:05:46.140 * MASTER <-> SLAVE sync: Flushing old data
25990:S 31 Dec 03:05:46.143 * MASTER <-> SLAVE sync: Loading DB in memory
25990:S 31 Dec 03:05:46.158 * MASTER <-> SLAVE sync: Finished with success
25990:S 31 Dec 03:05:46.163 * Background append only file rewriting started by pid 24966
25990:S 31 Dec 03:05:46.235 # Start of election delayed for 538 milliseconds (rank #0, offset 199501762).
25990:S 31 Dec 03:05:46.240 * AOF rewrite child asks to stop sending diffs.
24966:C 31 Dec 03:05:46.240 * Parent agreed to stop sending diffs. Finalizing AOF...
24966:C 31 Dec 03:05:46.241 * Concatenating 0.00 MB of AOF diff received from parent.
24966:C 31 Dec 03:05:46.241 * SYNC append only file rewrite performed
24966:C 31 Dec 03:05:46.243 * AOF rewrite: 0 MB of memory used by copy-on-write
25990:S 31 Dec 03:05:46.336 * Background AOF rewrite terminated with success
25990:S 31 Dec 03:05:46.336 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
25990:S 31 Dec 03:05:46.336 * Background AOF rewrite finished successfully
25990:S 31 Dec 03:05:46.837 # Starting a failover election for epoch 143.
25990:S 31 Dec 03:05:55.058 # Currently unable to failover: Waiting for votes, but majority still not reached.
25990:S 31 Dec 03:05:55.459 * Clear FAIL state for node c53b93ed799da727005832f1ae52c48f71864c4f: is reachable again and nobody is serving its slots after some time.
2021-01-04 15:46:09.187 [redisson-timer-4-1] DEBUG org.redisson.command.RedisExecutor [RedisExecutor.java:237] - attempt 12 for command (HGET) and params [common_service_cache_configuration, PooledUnsafeDirectByteBuf(ridx: 0, widx: 9, cap: 256)]
2021-01-04 15:46:09.187 [redisson-timer-4-1] DEBUG org.redisson.command.RedisExecutor [RedisExecutor.java:612] - acquired connection for command (HGET) and params [common_service_cache_configuration, PooledUnsafeDirectByteBuf(ridx: 0, widx: 9, cap: 256)] from slot NodeSource [slot=13203, addr=null, redisClient=null, redirect=null, entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=5, freeSubscribeConnectionsCounter=value:200:queue:0, freeConnectionsAmount=24, freeConnectionsCounter=value:2048:queue:0, freezed=false, freezeReason=null, client=[addr=redis://<IP_ADDRESS>:6379], nodeType=MASTER, firstFail=0]]] using node <IP_ADDRESS>/<IP_ADDRESS>:6379... RedisConnection@1096414064 [redisClient=[addr=redis://<IP_ADDRESS>:6379], channel=[id: 0x893cb8d3, L:/<IP_ADDRESS>:59794 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6379], currentCommand=null]
2021-01-04 15:46:09.190 [scheduling-1] ERROR org.springframework.scheduling.support.TaskUtils$LoggingErrorHandler [TaskUtils.java:96] - Unexpected error occurred in scheduled task.
org.redisson.client.WriteRedisConnectionException: Unable to write command into connection! Node source: NodeSource [slot=13203, addr=null, redisClient=null, redirect=null, entry=MasterSlaveEntry [masterEntry=[freeSubscribeConnectionsAmount=5, freeSubscribeConnectionsCounter=value:200:queue:0, freeConnectionsAmount=24, freeConnectionsCounter=value:2048:queue:0, freezed=false, freezeReason=null, client=[addr=redis://<IP_ADDRESS>:6379], nodeType=MASTER, firstFail=0]]], connection: RedisConnection@1096414064 [redisClient=[addr=redis://<IP_ADDRESS>:6379], channel=[id: 0x893cb8d3, L:/<IP_ADDRESS>:59794 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6379], currentCommand=null], command: (HGET), params: [common_service_cache_configuration, PooledUnsafeDirectByteBuf(ridx: 0, widx: 9, cap: 256)] after 12 retry attempts
at org.redisson.command.RedisExecutor.checkWriteFuture(RedisExecutor.java:270)
at org.redisson.command.RedisExecutor.access$100(RedisExecutor.java:58)
at org.redisson.command.RedisExecutor$1.operationComplete(RedisExecutor.java:155)
at org.redisson.command.RedisExecutor$1.operationComplete(RedisExecutor.java:152)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:502)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:476)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:415)
at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:540)
at io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:533)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:114)
at io.netty.channel.AbstractChannel$AbstractUnsafe.safeSetFailure(AbstractChannel.java:1018)
at io.netty.channel.AbstractChannel$AbstractUnsafe.write(AbstractChannel.java:874)
at io.netty.channel.DefaultChannelPipeline$HeadContext.write(DefaultChannelPipeline.java:1365)
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:706)
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:698)
at io.netty.channel.AbstractChannelHandlerContext.access$1700(AbstractChannelHandlerContext.java:38)
at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.write(AbstractChannelHandlerContext.java:1091)
at io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask.write(AbstractChannelHandlerContext.java:1138)
at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.run(AbstractChannelHandlerContext.java:1062)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:495)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:905)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
Caused by: io.netty.channel.ExtendedClosedChannelException: null
at io.netty.channel.AbstractChannel$AbstractUnsafe.write(...)(Unknown Source)

set pingConnectionInterval = 5000

set pingConnectionInterval = 5000

Caused by: io.netty.channel.ExtendedClosedChannelException

set pingConnectionInterval = 5000

Thanks.After several days watching,  this setting works! Redisson debug log:
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xc2857cb8, L:/<IP_ADDRESS>:56356 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xd079bb3d, L:/<IP_ADDRESS>:56360 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x354f5b0d, L:/<IP_ADDRESS>:56352 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x36990510, L:/<IP_ADDRESS>:56368 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xc9ed0837, L:/<IP_ADDRESS>:56366 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x1c607c20, L:/<IP_ADDRESS>:56364 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x9781b3fd, L:/<IP_ADDRESS>:56362 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.513 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xfa80e61e, L:/<IP_ADDRESS>:56370 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.611 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisPubSubConnection@132932421 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xa14785d9, L:/<IP_ADDRESS>:56348 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@30a3068a(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.611 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisPubSubConnection@372675536 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0x6c06723e, L:/<IP_ADDRESS>:56346 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@124fd298(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1688983946 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xd2008a32, L:/<IP_ADDRESS>:56344 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@4b5ba423(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@456505540 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xacb60d1e, L:/<IP_ADDRESS>:56350 !
R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@2692c200(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1909134234 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xf9b7a969, L:/<IP_ADDRESS>:56354 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@ead070e(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisPubSubConnection@1069823507 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xa411213d, L:/<IP_ADDRESS>:56358 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@629adf51(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1168005298 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xc2857cb8, L:/<IP_ADDRESS>:56356 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@74f6159d(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1974016468 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xd079bb3d, L:/<IP_ADDRESS>:56360 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@44c45bc1(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380

Caused by: io.netty.channel.ExtendedClosedChannelException

set pingConnectionInterval = 5000

Thanks.After several days watching,  this setting works! Redisson debug log:
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xc2857cb8, L:/<IP_ADDRESS>:56356 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xd079bb3d, L:/<IP_ADDRESS>:56360 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x354f5b0d, L:/<IP_ADDRESS>:56352 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x36990510, L:/<IP_ADDRESS>:56368 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xc9ed0837, L:/<IP_ADDRESS>:56366 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x1c607c20, L:/<IP_ADDRESS>:56364 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.512 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0x9781b3fd, L:/<IP_ADDRESS>:56362 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.513 [redisson-timer-4-1] DEBUG org.redisson.client.handler.PingConnectionHandler [PingConnectionHandler.java:73] - channel: [id: 0xfa80e61e, L:/<IP_ADDRESS>:56370 - R:<IP_ADDRESS>/<IP_ADDRESS>:6380] closed due to PING response timeout set in 3000 ms
2021-01-08 09:56:50.611 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisPubSubConnection@132932421 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xa14785d9, L:/<IP_ADDRESS>:56348 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@30a3068a(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.611 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisPubSubConnection@372675536 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0x6c06723e, L:/<IP_ADDRESS>:56346 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@124fd298(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1688983946 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xd2008a32, L:/<IP_ADDRESS>:56344 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@4b5ba423(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@456505540 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xacb60d1e, L:/<IP_ADDRESS>:56350 !
R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@2692c200(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1909134234 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xf9b7a969, L:/<IP_ADDRESS>:56354 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@ead070e(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisPubSubConnection@1069823507 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xa411213d, L:/<IP_ADDRESS>:56358 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@629adf51(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1168005298 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xc2857cb8, L:/<IP_ADDRESS>:56356 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@74f6159d(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380
2021-01-08 09:56:50.612 [redisson-timer-4-1] DEBUG org.redisson.client.handler.ConnectionWatchdog [ConnectionWatchdog.java:108] - reconnecting RedisConnection@1974016468 [redisClient=[addr=redis://<IP_ADDRESS>:6380], channel=[id: 0xd079bb3d, L:/<IP_ADDRESS>:56360 ! R:<IP_ADDRESS>/<IP_ADDRESS>:6380], currentCommand=CommandData [promise=RedissonPromise [promise=ImmediateEventExecutor$ImmediatePromise@44c45bc1(failure: org.redisson.client.RedisTimeoutException: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://<IP_ADDRESS>:6380])], command=(PING), params=[], codec=org.redisson.client.codec.StringCodec]] to <IP_ADDRESS>/<IP_ADDRESS>:6380


doc: add release notes for change in vet printf detection

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version devel +8a330454dc Fri Jul 13 03:53:00 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?
No, working with Go tip.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/tmp/tmp.sI0jAUcdXy"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build282886001=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Not a bug, but a suggestion for a release note.
Discovered whilst trying out the new go tool module support, upgrading https://github.com/gobuffalo/buffalo to be a Go module.
cd `mktemp -d`
export GOPATH=$PWD
mkdir -p src/example.com/hello
cd src/example.com/hello
cat <<EOD > main.go
package main

import "fmt"

type T struct{}

func (t *T) String(s string, args ...interface{}) string {
    v := s
    if len(args) > 0 {
        v = fmt.Sprintf(s, args...)
    }
    return v
}

func main() {
    var t *T
    t.String("<%=")
}
EOD
go test

What did you expect to see?
A release note at https://tip.golang.org/doc/go1.11 giving details about the new *printf detection that now reports the above as an error:
# example.com/hello
./main.go:17: T.String format %= has unknown verb =

What did you see instead?
No release notes 😄
Not critical, but I suspect this will catch out a few people. Buffalo had a number of instances because of the templating language, Plush, it uses.
/cc @rsc

CC @andybons


Unable to embed simple Dapp using library

I am trying to connect a very simple CRA to Ledger Live.  When using this library, I am getting the following error message when trying to connect via
mutation.ts:243 Error: Response from provider did not have error or result key  at IFrameEthereumProvider._this2.handleEventSourceMessage (index.ts:327)

Ledger Live Manifest file --> https://github.com/schnogz/wagmi-ledger-live/blob/main/ledger-manifest.json
Wagmi config --> https://github.com/schnogz/wagmi-ledger-live/blob/main/src/App.js
You can find the source code here.
I tried to find other examples of people using this wagmi connector but was unable to do so.  Any help would be greatly appreciated!

Hi @schnogz
First of all, thanks for your message.
I'm not sure it's clear regarding the readme of this repository, but the connector developed here is expected to be used to develop a Live App. What we call a live app, is a dApp that runs inside the discover section in the Ledger Live wallet. That means the dApp is embedded inside an iFrame and can be accessed from the discover section.
Unfortunately, this connector doesn't manage the direct communication with the Ledger Live wallet, the dApp (called Live app in this context) needs to be embedded inside the discover section of Ledger Live to work.
By following the minimalist example in the readme, you can develop both a dApp and a Live app without compromise and a complex setup.
Was it clear to you? Do you try to enable a direct connection between your dApp and Ledger Live?

Hi @schnogz
Thanks for your message and your interest in building on top of the Ledger Platform 🙌
I had a quick look at your code and have some feedbacks that might help you make your dapp work:
As explained by @qd-qd, your Dapp will run inside the eth-dapp-browser. This is why you have 2 urls in the manifest, the first one, url, should be the url of the eth-dapp-browser. The second one, dappUrl inside the params object, should be the url of your dapp.
Here is the documentation regarding developing a dapp on top of ledger (you don't have to worry about the DApp Plugin part for your POC) with the doc related to the manifest here. If anything in this doc is not clear or could be improved, don't hesitate to drop a comment / feedback in the appropriate comment box present at the end of each page so they can be improved 👍
It looks like that you are using the same url (the url of your dapp I would assume) for both of these applications, which might cause your issue.
  "url": "http://localhost:3001/?embed=true",
  "params": {
    "dappUrl": "http://localhost:3001/?embed=true",

Regarding your wagmi config, it looks fine overall but you could specify the connector as parameter of the createClient function in order to avoid specifying it for each hook call afterward.
For a quick example of a Dapp implementation using this wagmi connector, you can take a look at this workshop repo (under the solution branch).

Thanks for the quick response @chabroA @qd-qd .
Yes I am building a Live App that will go into the Discover section of Ledger and this was just a small proof of concept.
The issue was as @chabroA pointed out, I was not running the ETH App Browser provided by ledger and my urls in the manifest were incorrect. Once I fixed that, it instantly connected!
I guess one piece of feedback would be to make it more obvious to a developer that they need to be running the ETH App Browser locally.  The description in the docs for url just says https://dapp-browser.apps.ledger.com and I guess I didn't realize that meant you needed to run this other app alongside.  Perhaps the description could be updated to state something like The url of the ETH App Browser either running locally or at https://dapp-browser.apps.ledger.com.

Your feedback is valuable, thanks! We’ll definitely update the documentation to make this part clearer.
I’m glad we helped, don’t hesitate if you have any additional questions.


DeviceConnected event not fired

Plugin.BLE 3.0.0-beta.4
MAUI .NET7.
When connecting to iDevice, the Adapter.DeviceConnected event is fired. If you disconnect from iDevice, the Adapter.DeviceDisconnected event is fired. If I connect again to iDevice, the event Adapter.DeviceConnected  is not fired.
_Ble.Adapter.ConnectToDeviceAsync(this._IDevice);
//event fired
//wait
_Ble.Adapter.DisconnectDeviceAsync(this._IDevice); //event fired
event fired
//wait
_Ble.Adapter.ConnectToDeviceAsync(this._IDevice);
event not fired

Hi @smersh1307n2,
I'm the friendly issue checker.
It seems like (100.00 %) you haven't used our issue template :cry: I think it is very frustrating for the repository owners, if you ignore them.
If you think it's fine to make an exception, just ignore this message.
But if you think it was a mistake to delete the template, please close the issue and create a new one.
Thanks!


Add ColorDB Singleton

This pull request adds a ColorDB Singleton to the project and replaces all mentions from ThemeGenerator colors to ColorDB. The reason for this is so I (or others) may create a way to make custom editor themes for GodSVG.

Also please disregard the first four commits, they failed in a lot of ways. I needed to make this ColorDB first before making themes so I figured why not make a pull request as soon as I could.

Nice commits you have here

Nice idea! Custom themes are something GodSVG should support. Currently, the top item on the "support themes" checklist is reducing the number of theme colors a little, not needing to define so many of them for a theme.
My big reservation is that I'm not sure this is the right infrastructural change for multiple themes to happen. A change like this should happen either along with the full implementation, or after working out full implementation details.

With that, I think another one of the biggest problems is how themes are set up. Currently, it's just one big function that updates everything but I would like to be able to update individual themes without updating everything.

Actually, I could do something with having the one base color and then an "Advanced Options" setting that gives you finer control.

With that, I think another one of the biggest problems is how themes are set up. Currently, it's just one big function that updates everything but I would like to be able to update individual themes without updating everything.

Does it matter? If your concern is performance, the setup isn't expensive, it's the merging. Maybe I'm wrong, but I'd need to see benchmarks proving it.

Also, we could probably get one base color for a theme and then build everything else off of that one color.

Yeah, but normally you need at least 2 colors for a theme. And I think the theme generator is kind of misleading with the colors, there would probably be different setups too, like low/medium/high "roundiness" for example.

Does it matter? If your concern is performance, the setup isn't expensive, it's the merging. Maybe I'm wrong, but I'd need to see benchmarks proving it.
When I tested updating every time the color was changed there was a lag spike which feels less than ideal.

When I tested it, creating the theme took something like 3ms, merging it with the main theme took way more. The rest is the cost of redrawing the UI, which mostly gets high when you have a big SVG.


Too  much Instructions

Please check the following route, only 7km, in the area north east of Giessen, Germany.
Supposed to be only 3 turn-offs, but we have lots of unnecessary instructions and one important instructions is even missing.
How can we start getting these things better?

Hello @TomQv
If you are interested, you can look at my fork of Itinero 'master' (https://github.com/jerryfaust/routing) in which, among other changes, I have attempted to simplify the instructions in two ways:

I have tried to correct for what I consider mislabeled turns - for example, those that indicate a right turn when intuitively it would be considered straight-on or slightly-right, and
I have tried to minimize repeated 'Continue on' instructions when you are just continuing on the same street.

I generally work with Shapefile networks, so I have a custom Lua file, but I have also modified the OSM car.lua with the same changes (although I have not tested it).
Although there is probably good reason, I don't understand why there is the division of responsibilities between work done in the c# code and other work done in the Lua file (at least as it relates to generating instructions).  And I have not found documentation of the syntax or object properties within the Lua file, so I've had to just try different things until I got it to work.  The short of it is that you need the updates to the DirectionCalculator as well as the Lua file to get the full benefit of the streamlined instructions.
Within the fork, look at the changes committed under the name "Enhanced Directions calculation...".  Only three files are affected.  You can either take the whole fork and build it, or just try integrating the 3 files into your build.
Best Regards,
Jerry

Hi Jerry, sorry for late answer, was out of office.
Will give your solution a try the next days.
Thank you, Tom


Error running composer and the wpackagist.org URL

When running Composer update I get the error
[Composer\Downloader\TransportException]
Your configuration does not allow connections to http://wpackagist.org/packages.json. See https://getcompose
r.org/doc/06-config.md#secure-http for details.

I was able to fix this by making the repo url https
"url": "http://wpackagist.org" to "url": "https://wpackagist.org"

?This has already been addressed in a pull request
https://github.com/studiorabota/sage-twig-theme/pull/14


Add docs about usage with Ionic

Anyone managed to run this plugin with Ionic and can share the steps?

I also didnt manage to get it to work yet. Getting this error
Ad failed to load : 0

Hi i'm using ionic/angular/capacitor. I followed the step shown to install and get it to work. But you'll see the ad only after adding capacitor and loading with android studio (and modifiying the manifest etc...) on a device. You can't show ad in the "Ionic serve".
To know : banner ad overlap your view (there is some fixes in the issues page)


Setting up of the new repository

The repository is going to change, starting from the final status that was reached in project BlueCloud. The new layout will continue with the same aim it was in project BlueCloud, and will be open to sinergie with more projects.

ref.: https://github.com/CMCC-Foundation/bluecloud-mockup_method/pull/30#issuecomment-1596752946
@anto6715 @gottomondo - the reorganization process is continuing, and the previous question can be managed inside this new pull request. Can you please advice about what material is available inside this repository, and can be directly linked here:
https://github.com/CMCC-Foundation/bluecloud-mockup_method/blob/1bbd38a76a4b3c9e8e265d4943e3ec9463bdfe9f/README.md?plain=1#L63-L68


error using makeJwt

I am working with oak and when I try to create a token the server responds with a status 500, it only happens when I use makeJwt

Hi @buttercubz I would recommend raising this issue in the Oak repo because I don't really know how Oak works.
But, if you can replicate the error with djwt independently of Oak I would be more than happy to help.


add stack op

Description
Missing Op from GNMT
Checklist
Essentials

[x] Passed code style checking (make lint)
[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@mbrookhart Do we have a test case that exercises this PR?

@cconvey tests/python/unittest/test_operator.py::test_stack hits this op with a few dozen examples.

Yes, MXNet verifies before we get to this point.
That's a good point, updated


run.sh

Starting the django server and node frontend requires two separate commands. Both can run in the background, but will need some terminate signal if one is killed and the other is left alive.
Create a run.sh or something for the overall startup to make it easier to start up the application.

i'm interpreting something as a systemd widget w/ auto restarts

@otakup0pe That is more than what I was expecting, and sounds amazing if not that much additional lift.
This is intended to be a quick one-command entry point to running the system, rather than a chain of commands and parameters as it currently stands.

Adding systemd for a django thing isn't that hard. For the frontend, if we host in nginx, it will come for free. The work will be in the nginx config - which isn't super difficult.

Peek ⬆  PR - React bits are served via nginx, django bits are served via wsgi via nginx.

looks like @otakup0pe did an amazing job in creating a deployment script to add the django backend as a systemctl service in #35 , calling this complete!


Added optional param allowing OR type search on each word if operator not specified. Fixed handling of multi-hyphen-words

Hey @Aledar , thanks for taking an interest in updating this project. It's been a few years though, so my PHP is a little rusty and there's probably some quirks in this code as it was written when I was in my first dev job 😅
I'm all for updating this codebase and releasing a new version, but I feel there are 2 things that jump out at me.

It looks like from the readme the default operator was OR, but your change has made AND the default. This would constitute a breaking change. It would be good to avoid this and reverse the logic (where OR is the default again)
There are some tests in the tests folder - do these still pass with these changes? Are there any tests that you could write to provide additional confidence around these changes

I feel with those changes we'd be in a great place to merge this PR 💪

Hi @DuncanOgle, thanks for taking the time to respond.
Seems fitting I am trying to contribute to this project which you wrote in your first dev job whilst I am in my first dev job. This is also my first github contribution so apologies if I have or do overlook any etiquette or get my terms wrong.
On 1, I believe the default operator was AND so the changes should not be a breaking change for existing users.
On 2, good point, I added an equivalent OR test for each existing test as well a few tests for multi-hyphened words.
Again, thanks for taking the time to respond, and considering the pull request.
Cheers,
Aledar


Modernize Java launch code

❄ Winter Update PR Navigator ❄

#261
#262
#263
#264
#265
#266
⛄ #267
#272
#274
#283

⛄ = you are here
Summary
This PR updates the Java launch code used to invoke the command line tools.
Closes #176
Testing
In order to test this, I ran Gradle experiments 1-3 both online and offline:
./01-validate-incremental-building.sh -r git@github.com:gradle/ge-solutions.git -p sample-projects/gradle/7.x/ge -t 'build'
./01-validate-incremental-building.sh -r git@github.com:gradle/ge-solutions.git -p sample-projects/gradle/7.x/ge -t 'build' -x
./02-validate-local-build-caching-same-location.sh -r git@github.com:gradle/ge-solutions.git -p sample-projects/gradle/7.x/ge -t 'build'
./02-validate-local-build-caching-same-location.sh -r git@github.com:gradle/ge-solutions.git -p sample-projects/gradle/7.x/ge -t 'build' -x
./03-validate-local-build-caching-different-locations.sh -r git@github.com:gradle/ge-solutions.git -p sample-projects/gradle/7.x/ge -t 'build'
./03-validate-local-build-caching-different-locations.sh -r git@github.com:gradle/ge-solutions.git -p sample-projects/gradle/7.x/ge -t 'build' -x

The optional comments I left might be worth considering if we're okay with deviating from the application plugin's template script. If we want this to closely match the template script, then its fine to leave them unaddressed.

These are great suggestions! I intentionally left the code as close to its source (the template script) as I could. I'm fine implementing these changes but I'm unsure of the impact, if any. @etiennestuder wdyt?


Added about section in homepage

As mentioned in issue id #498  , I have updated the homepage by adding the about section.

@cleveranu Do check this

@linga66 Can you please make changes to the design as it is contradicting with the main animation.

What colour do you want me to put?

Is this Okay? @raj03kumar

Is this Okay? @raj03kumar

yeah it's okay. But don't compromise with the main height of the pacman animation.

Is this Okay? @raj03kumar

yeah it's okay. But don't compromise with the main height of the pacman animation.

I=
The pacman animation is good

Is this Okay? @raj03kumar

yeah it's okay. But don't compromise with the main height of the pacman animation.

  It should be little big. You made it to half. Kindly improve on that.

make changes in this part.

Is this Okay? @raj03kumar

yeah it's okay. But don't compromise with the main height of the pacman animation.

  It should be little big. You made it to half. Kindly improve on that.

It was mentioned in issue id #497 , and was merged into the main branch.

Changes are done
@raj03kumar

Changes are done @raj03kumar

Good.


[Bug] NoSuchMethodException: App crash when creating instance of LifecycleCameraController in production app

Description
Sentry reports app crashes for some Android devices when the app is built in release mode and published to Google Play.
Steps to Reproduce

Install nuget in production app.
Publish app via Google Play Console.
Download app and start cameraview.

Expected Behavior

Camera starts to show preview frames.

Actual Behavior

App crashes

Basic Information

Version with issue: 1.3.x
Last known good version: N/A

Preserve attributes didn't help.

Proguard configuration solved the problem.


Fix typo in 2019-01-16-4.0.0-release.md

AllowJavaScriptPrecomplilation -> AllowJavaScriptPrecompilation

Website preview is ready!
Built with commit f484c04a4ff1f9a0dd09145a739073b1954a47c5
https://deploy-preview-903--reactnet.netlify.com/

Thanks :)


音乐url是什么呀，怎么MUSIC_BASE_PATH为空

Search keywords in the browser: NeteaseCloudMusicApi

No description provided.

No description provided.

earch keywords in the browser: NeteaseCloudMusicApi


[Feature Request] - Send Cantada

It would be fine if we have a way to send a cantada to someone.
Idea: Share button to share a plain text to social medias or just copy to clipboard. Some future ideas would be sharing a link for a "cantada presentation" page instead of the "generator" page.
Result: Be able to send or share a cantada in an easy and fun way. This would increase the engagement of people who use virtual communication tools (social media, live chat, e-mail...)

Already exists this functionality, when you click over the cantada, you copy her and can share the cantada


Unclear why "didChangeDepdenencies()" is called

Related issues:

https://github.com/flutter/flutter/issues/18774
https://github.com/flutter/flutter/issues/12992
https://github.com/flutter/flutter/issues/16218

I am also running into this on a hobby app. It would be nice to be able to either call:

this.debugWhyDidChangeDepdencjes() => Set<Object>

... or have it filled in as a diagnostic property, obviously in debug mode. Thanks!

<Technically, this issue can be closed>
Besides that, I think there's a need to document the when and why we need it too.

I myself have quite a few doubts about didChangeDependencies.
According to the documentation, it should be used for expensive work that shouldn't be done on every build call. But the way it works now seems to indicate the opposite.
Consider a Foo class that do expensive stuff inside its didChangeDependencies – where Foo depends on the InheritedWidget named Provider.
Then consider this test scenario:
testWidgets('foo', (tester) async {
  await tester.pumpWidget(Provider.value(
    value: 'hello',
    child: Foo(),
  ));

  await tester.pumpWidget(Provider.value(
    value: 'world',
    // `Foo` is removed from the tree
    child: Container(),
  ));
});

In this example, didChangeDependencies will be called twice. But the second call barely makes sense, since Foo will be unmounted.
Due to this behavior, it sounds unusual to recommend using didChangeDendencies over build for network requests – since doing the request there doesn't guarantee that we actually want to do one.
It would be actually safer to do that instead:
class Foo extends StatefulWidget {
  @override
  _FooState createState() => _FooState();
}

class _FooState extends State<Foo> {
  bool _didChangeDependencies;

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    _didChangeDependencies = true;
  }

  @override
  Widget build(BuildContext context) {
    if (_didChangeDependencies) {
      _didChangeDependencies = false;
      // actual didChangeDependencies
    }

    return Container();
  }
}

Thanks! I used the new field successfully today and I think we can close this issue! Woohoo!


pathPrefix docs

https://github.com/11ty/11ty-website/blob/master/src/docs/config.md
shows example config for pathPrefix as:
module.exports = {
    pathPrefix: "/eleventy-base-blog/"
};

maybe should be:
module.exports = function (eleventyConfig) {
    return {
        pathPrefix: "/eleventy-base-blog/"
    };
};

The former doesn't work reliably.

I’m curious as to your last comment—is there a bug there?
But I totally agree that we need to move all of the examples on config.md to use the API function rather than the Object. The Object is still supported but it sees very little use and is so much less powerful.

Didn't save the test case, but the gist of it was that if I put anything else in module exports, the path prefix wouldn't work. Probably I was just mixing up the syntax between the two. Call it fixed.

Didn't save the test case, but the gist of it was that if I put anything else in module exports, the path prefix wouldn't work. Probably I was just mixing up the syntax between the two. Call it fixed.

Not all examples converted? (and there's a lot of markup on the page: {% codetitle ".eleventy.js" %}).
Didn't save it, but I think my test case depended on having mixed up the two formats.

@zesty This shouldn't be closed until #1107 is merged. All of the Objects should be converted to use the API function in examples on config.md. Feel free to reopen.


test files

Improvements to the newest test files:

[x] They include a line that is no longer necessary:

urlbase = 'http://www.inegi.org.mx'  #change this line whenever you change the website to scrape

[x] It is good coding practice to make the arguments clear and only include unnamed arguments in the first one or two arguments of the function. Also include spaces after function arguments. So:

get_files(url_base,'pdf',folder_base,True)

should instead be:
get_files(url_base, 'pdf', folder=folder_base, overwrite=True)

[x] Make the names of files consistent: <command name>_test_<description>.ipynb (without the <> symbols) -- right now some of them are <command name>_test and some are test_<command name>. Also let's try to be more concise in the <description> part of the file name (i.e. a few words) so they aren't so long, and make sure they don't contain spaces in the name. Then in the file itself, you can include some description at the top in writing so it's clear what this file is doing (note you can change a cell to have its input be Markdown instead of code which is good for describing what you are doing in the file at the top).

Also:

[ ] Make the names of files consistent: <command name>_test_<description>.ipynb (without the <> symbols) -- right now some of them are 'testand some aretest. Also let's try to be more concise in the ` part of the file name so they aren't so long, and make sure they don't contain spaces in the name.

Solved in #35


XD-2710 Kafka on-demand queue tests should not assume offset 0

record initial offsets at the beginning of the tests - this ensures that the reading happens after the test has begun writing of the topics;
this accounts for the case where the topic exists at the beginning of the test and already contains data (typical for CI environment)

LGTM, merging!

Rebased and merged as 8598f48265c5b5e8fe744869b3ab1c5e7cd420da


When a DPR model is used in text2vec-huggingface, the loading error returns the DefaultHuggingFaceModel value

When a model is still loading, it returns (note "message"'s content):
{
  "data": {
    "Get": {
      "Sphere": null
    }
  },
  "errors": [
    {
      "locations": [
        {
          "column": 5,
          "line": 3
        }
      ],
      "message": "explorer: get class: vectorize params: vectorize params: vectorize params: vectorize keywords: remote client vectorize: failed with status: 503 error: Model sentence-transformers/msmarco-bert-base-dot-v5 is currently loading estimated time: 20",
      "path": [
        "Get",
        "Sphere"
      ]
    }
  ]
}

This seems to always be the DefaultHuggingFaceModel as set here even if another model is being used.
This was tested with the following settings:
{
    "moduleConfig": {
        "options": {
            "useCache": true,
            "useGPU": true,
            "waitForModel": true
        },
        "passageModel": "sentence-transformers/facebook-dpr-ctx_encoder-single-nq-base",
        "queryModel": "sentence-transformers/facebook-dpr-question_encoder-single-nq-base",
    }
}

So I was expecting message to output:
{
"message": "explorer: get class: vectorize params: vectorize params: vectorize params: vectorize keywords: remote client vectorize: failed with status: 503 error: Model sentence-transformers/facebook-dpr-question_encoder-single-nq-base is currently loading estimated time: 20"
}

cc @antas-marcin


Add Google / OAuth2 / OpenID authentication delegation

Currently BountySource supports delegating authentication to Facebook, Twitter, and GitHub.  BountySource should also support these authentication backends:

OAuth2 (Google / Google+)
OpenID

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/936812-add-google-oauth2-openid-authentication-delegation?utm_campaign=plugin&utm_content=tracker%2F47&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47&utm_medium=issues&utm_source=github).

Agree about OpenID.


Fix black_level_per_channel

See https://github.com/letmaik/rawpy/issues/61#issuecomment-519411071.
Tested with an example image from https://mirrorlesscomparison.com/galleries/fuji-xt3-sample-images/ which had cblack (>6) values. They were all the same, so for that image this PR solves it perfectly.
@kmilos I have a suspicion that the case where the cblack (>6) values are not uniform is quite rare. Do you have a few examples? In any case, there is no code we can steal directly to implement the per-pattern-pixel black level property, but I think this fix solves the majority of cases. Please feel free to test this once the CI build is done.

I tried some high ISO X-Trans samples here, but the black levels are still constant, so it'll be indeed hard to find and test the non-uniform black level pattern case.
OTOH, this patch seems to add the black level twice somehow, in this X-Trans case at least... From exiftool:
BlackLevel                      : 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023 1023

while we get
with rawpy.imread('./fujifilm-xt3-iso-12800-70.raf') as raw:
    print(raw.black_level_per_channel)

[2046, 2046, 2046, 2046]

Even the oldest X-Trans sensor at highest ISO seems to have constant black levels...

Thanks for pointing out the issue with double adding. I fixed this. It's all a bit confusing but essentially you only have to look at cblack after adjust_bl().

Yes, that last line C.cblack[c] += C.black; looks weird without any comment, the logic before that made sense: move all constant part to C.black, keep color channel differences in C.cblack[0..3], keep pixel pattern differences in C.cblack[6...]... Oh well, works now.

Do you think this PR solves your problem? It looks like it's hard to find nonuniform black level images anyway.

I think this is good for the time being, thanks. black_level_per_pixels can be left as a todo once/if raws pop up.


Longhorn Storage

Implement Longhorn storage

Closing.  Realigning my cluster with TalosOS, which makes a strong case against leverage iSCSI based storage in k8s, of which Longhorn does.


Add Mydumper and Myloader into the CLI image for faster MySQL dumps and restores

Describe the feature
At the moment it can take a long time to dump and restore databases if they are sufficiently large. For a recent site I was working on:

Size: ~6.8 GB
MySQLdump time: 2 minutes 11 seconds
MySQL restore time: 38 minutes

It would be great if the mydumper and myloader CLI utilities where in the CLI pod.

Additional context
Worth while to read https://medium.com/tensult/mydumper-myloader-and-my-experience-of-migrating-to-aws-rds-ff74fc9c1add
Alternatives
A go fork https://github.com/xelabs/go-mydumper has been written to which is API compatible.

As we have more and more customers and sometimes backups run into the max_query_time this would greatly benefit customers that create a database backup regularly e.g. on pre-rollout hooks.

As we have more and more customers and sometimes backups run into the max_query_time this would greatly benefit customers that create a database backup regularly e.g. on pre-rollout hooks.

I remember something something way back why it's hard.  Will try to access my in-brain glacier storage tier.

https://answers.launchpad.net/mydumper/+question/236273 - it's a global lock thing I think

Oh... Hmm yeah the global lock will be complicated - I think --no-locks or --less-locking would prevent this. Currently a normal MySQL dump also won't be fully consistent if there are writes (depending on the options passed)


Terminal: NetBSD, use Linux's function

Description
Because in get_cpu NetBSD uses Linux function instead of the usual thing, why not use the same thing for get_term since they also fetch information from /proc ?

Have you tested this on NetBSD?
I'm not sure of the extent that NetBSD emulates the /proc/ filesystem.

Yeah, turns out it's not a full emulation.
Oops.

All good.
On Sun, 4 Dec 2016 at 7:10 PM, Herdiansyah<EMAIL_ADDRESS>wrote:

Yeah, turns out it's not a full emulation.
Oops.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dylanaraps/neofetch/pull/492#issuecomment-264690394,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGfAa6uSsuG3Xlr3MO1L2IesLM4FDUthks5rEnVdgaJpZM4LDfta
.


Support for Image Layer repeat x and y in TiledMap + Bugfix

This PR will accomplished two things.

Add the ability for Image Layers to be repeated along the X and/or Y axis to support the repeatx and repeaty attributes on a layer in Tiled.
Fix a Glaring position issue that has always existed when using ImageLayers in any non-orthograpic map renderer. (That I only learned about while working on this).
Added a new GDXTest specifically to show off this feature.

First I would like to point out a bug that seems to have always existed. As I learned while working on this PR. Any imagelayer that was added to a tiled map would render at the incorrect position in the following MapRenderers:
IsometricStaggeredTiledMapRenderer
IsometricTiledMapRenderer
HexagonalTiledMapRenderer (staggered X and/or Y)
This was because they were all using the same BatchTiledMapRenderer.renderImageLayer() which works fine for the OrthogonalTiledMapRenderer but not the rest.
While fixing this I needed to give each renderer their own specific renderImageLayer() to fit it's needs.
Using the base examples I modified with an Image Layer found in GDXTests:
Pictures comparing Tiled, with how they render in libGDX.
And what I think to be the reasoning behind the issue. Please correct me if I am mistaken.
IsometricTiledMapRenderer:

So, Because of the way libGDX handles the isometric coordinates. The leftmost tile of the map begins rendering at world position 0,0, while in Tiled the y position is actually totalHeight/2
ex. Map 800px in height, leftmost tile edge starts rendering at 0,400 in tiled
To compensate for that we need to subtract half the map's height in pixels then add half of the tile's height in order to position it properly in order to get a 1 to 1 rendering as to where the imagelayer renders in tiled.
https://github.com/BoBIsHere86/libgdx/blob/61b2384796a471d8af54eb1849861c1994f8588b/gdx/src/com/badlogic/gdx/maps/tiled/renderers/IsometricTiledMapRenderer.java#L262
IsometricStaggeredTiledMapRenderer:

Must offset imagelayer x position by half of tileWidth to match position in  tiled.
https://github.com/BoBIsHere86/libgdx/blob/61b2384796a471d8af54eb1849861c1994f8588b/gdx/src/com/badlogic/gdx/maps/tiled/renderers/IsometricStaggeredTiledMapRenderer.java#L211
HexagonalTiledMapRenderer Stagger X Axis:

If X axis is the staggered axis, must offset imagelayer y position by adding half of tileHeight to match position
https://github.com/BoBIsHere86/libgdx/blob/61b2384796a471d8af54eb1849861c1994f8588b/gdx/src/com/badlogic/gdx/maps/tiled/renderers/HexagonalTiledMapRenderer.java#L290
HexagonalTiledMapRenderer  Stagger Y Axis:

This one was a bit complicated to figure out but ImageLayer's y position seems to be placed at an offset determined the total height if this were a normal tile map minus the height as calculated for a hexmap. We get this number and use it to counter offset our Y. Then we will have our imagelayer matching its position in Tiled.
https://github.com/BoBIsHere86/libgdx/blob/61b2384796a471d8af54eb1849861c1994f8588b/gdx/src/com/badlogic/gdx/maps/tiled/renderers/HexagonalTiledMapRenderer.java#L295
Anyway, once that issue was out of the way. Now I could get to the ACTUAL PR, lol.
The basic idea behind the tiling feature was to make it match 1:1 with how Tiled renders it.
Repeat X, Tiles horizontally. Repeat Y Tiles vertically. But if we have both select. It tiles all directions infinitely and not just Up/Down.
I have an example of the results in a new TiledMapImageLayerRepeatTest test I made, each with it's own map based on the maps we seem to always use.
OrthogonalTiledMapRenderer:

OrthoCachedTiledMapRenderer:

This I found to be a bit tricky, but I based it on the bounds cache. So it will render as many tiles are needed to fit within the bounds of the cache. Then when it gets to the point where the cache is invalided it get's rendered. But you will never notice this, unlike in the test. where we can see outside of the bounds, which is why this looks different than the OrthogonalTiledMapRenderer Test.
IsometricTiledMapRenderer:

IsometricStaggeredTiledMapRenderer:

HexagonalTiledMapRenderer staggered X:

HexagonalTiledMapRenderer staggered Y:

As for how I actually implemented this tiling function:
https://github.com/BoBIsHere86/libgdx/blob/61b2384796a471d8af54eb1849861c1994f8588b/gdx/src/com/badlogic/gdx/maps/tiled/renderers/BatchTiledMapRenderer.java#L243
And this is replicated in each of the specific renders.
I left a giant comment in there explaining the my thought process. I may remove it. But I wasn't sure what the protocol was, as I thought it would help if someone was looking at it. I could just remove it.
Any thoughts or complaints are welcome.
Also, While I was writing up this PR it seems like the Parallax feature was reviewed and accepted. I will need to add and do some testing to make sure the Parallax effect will work on image layers and if they tile properly with it enabled. But as of right now the parallax attribute is not taken into account.

I've tested Quillravens parallax code in a separate merged local branch I have.
And the effect seems to work without issue. Though it might be hard to tell with this low fps gif I quickly made.

This PR will have to wait until https://github.com/libgdx/libgdx/pull/6714 get's merged. As I will need to modify the new renderImage Methods to support it as this branch does not contain any of his parallax code.

Now that Quillraven's Parallax code has been merged. I rebased against the master to pull in his changes.
And I modified the renderImageLayer() functions that I added while doing this PR to make sure they support the parallax effect as well.
The only last hanging thread would be if my Tinting Feature PR were to be accepted as I completed that first.(https://github.com/libgdx/libgdx/pull/7076). I would need to update that PR, if this one is accepted and merged. To add tinting functionality to the new image renderers.
Other than that there is no more work for me to do on this PR, unless someone finds and issue.
Let me know. Cheers!

I felt my original code for tiling the images was a bit overly complicated and hard to understand. I realized it could be done a lot simpler so I changed it, retested and removed a giant ugly comment I had placed in there.
That is all.

I see a bunch of Tiled PRs here but I don't think anyone in the team who can review... uses Tiled. I can only just barely use Tiled well enough to replicate/verify bugs; I don't use it day-to-day in any of my code. There's been some talk of splitting the Tiled maps package into its own repo, though that would have to be after the next release. So uh... sorry these PRs are taking so long to get merged; you clearly put a lot of thought and work into the descriptions!

Thanks for the update. No rush on my end, libGDX is an awesome framework and I'm just doing my part to give back to this awesome community when I can.


Consistent program args for mount limit bypass

Many applications have a bypass-alt-limits flag that is specific to NexStarMount, however the LosmandyGeminiMount class has similar constructor arguments but there is no corresponding program argument for this. Do one of the following:

remove the bypass flag
make the flag generic so that it applies to all mount types
add a separate flag for the Losmandy mount RA axis limit to be consistent with NexStar mounts

Fixed in 0f1b6c1f by making the flag generic and making the mount constructor argument names consistent.


SSL support for push targets

Add support for SSL. This should cover most targets.
Options:

just skip cert validation. This is the easy approach and does not validate the remote target (if its valid). However it uses the least amount of memory and is easy to implement.
use fingerprints to validate remote targets. this would require some type of function to catch and store the fingerprints for the remote targets and users will have to update when the remote certificate is updated. better security but not really user friendly
store root ca in the device. this is the optimal solution but would require around 150 kb of flash storage to implement. There are projects that have done it but I'm not sure I want to waste this amount of space on certificates.

Need to investigate what the different libraries support.

After some testing a full implementation of SSL is not going to work. Just loading the cert store with all root CA takes almost 3 seconds on a a device + 500ms to do the time synchronisation. This would kill the batterylife of the device. Will do some tests on ESP32 later to see if this is a better platform. I will focus on doing the simple approach for next release (option 1).

dev branch now has support for ssl on http and mqtt targets.
brewfather and influx will be added if needed.


[2.9] Show Cloud Credential Expiration information for Harvester Creds, add actions to renew

Summary
Fixes #11270

Occurred changes and/or fixed issues

Cloud Credentials List

If there's a cloud cred of type harvester,  show an Expires column
Expires column is populated ig cloud cred has expired annotation (empty if not)
For cloud creds with an expiration, show a 'Renew' action
Renew action is provider specific, provide one for harvester which updates the kubeconfig within the cred

Cluster List

If there's a cloud cred associated with the harvester cluster (cloud cred harvestercredentialConfig.clusterId) check it's expired date, warn if within 7 days of expiring or has expired
If there's a cloud cred with expiration, show the Renew Cloud Credential action
Action does same as cloud cred renew

Banners

In both lists show a banner warning of soon to expire or expired creds

Technical notes summary

Areas or cases that should be tested

End to end

Renew Cloud Credential results in cluster continuing to function

Areas which could experience regressions

Cloud Credentials List
Prov Cluster List

Screenshot/Video

Cloud Credentials List

Clusters List

Checklist

[x] The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
[x] The PR has a Milestone
[x] The PR template has been filled out
[x] The PR has been self reviewed
[x] The PR has a reviewer assigned
[x] The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
[x] The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

The Renew issue was investigated today and to progress it @MbolotSuse is taking a look. Given timing we'll merge this PR WITH the feature, and then hide / change messaging tomorrow if there's no solution