Openresty process becoming unresponsive. Possibly lock related?

Hey! Sorry to bother you again, I think the instability that I had the other day (#135) was a red herring and not actually the cause of the outages that we've been having.
I've been seeing some things in our logs that look like the following:
Restarting selected processes ['openresty']

This is coming from supervisor detecting that openresty has become unresponsive. Scrolling to those logs, i see lots of things regarding a "shared memory zone" (i've redacted some duplicates for brevity):
[notice] 24883#24883: signal 15 (SIGTERM) received, exiting
[notice] 24883#24883: signal 14 (SIGALRM) received
[notice] 24883#24883: signal 17 (SIGCHLD) received
[alert] 24883#24883: worker process 24895 exited on signal 9
[alert] 24883#24883: shared memory zone "auto_ssl" was locked by 24895
[notice] 24883#24883: exit
[notice] 31640#31640: using the "epoll" event method
[notice] 31640#31640: openresty/<IP_ADDRESS>
[notice] 31640#31640: built by gcc 4.9.2 (Debian 4.9.2-10)
[notice] 31640#31640: OS: Linux 4.4.0-96-generic
[notice] 31640#31640: getrlimit(RLIMIT_NOFILE): 1048576:1048576
[notice] 31640#31640: start worker processes
[notice] 31640#31640: start worker process 31652
[notice] 31652#31652: signal 17 (SIGCHLD) received
[notice] 31652#31652: unknown process 31653 exited with code 0
[notice] 31652#31652: signal 17 (SIGCHLD) received
[notice] 31652#31652: unknown process 31655 exited with code 0
[notice] 31652#31652: *1 [lua] start_sockproc.lua:10: auto-ssl: starting sockproc, context: init_worker_by_lua*
[notice] 31652#31652: signal 17 (SIGCHLD) received
[info] 31652#31652: waitpid() failed (10: No child processes)

This log output lead me to the following issues:
https://github.com/GUI/lua-resty-auto-ssl/issues/43
https://github.com/18F/api.data.gov/issues/325
And a commit which fixed the locking issue: https://github.com/GUI/lua-resty-auto-ssl/commit/8bcb9ee83c1faae849ad456503f841afb804ad75
One of the error messages in that commit "failed to unlock:" is also coming up in our logs with the following error message:
[error] 3706#3706: *20191 [lua] ssl_certificate.lua:53: issue_cert_unlock(): auto-ssl: failed to unlock: lock does not match expected value, context: ssl_certificate_by_lua*

Which appears to come from: https://github.com/GUI/lua-resty-auto-ssl/blob/0fe6ab67f091d75821a865d8d71122dc04e8ff0d/lib/resty/auto-ssl/ssl_certificate.lua#L53
Have you ever seen this before? Is there anything I can do to debug this further? I've already bumped the auto_ssl lua_shared_dict to 100mb in an attempt to mitigate in the chance we were filling it up.
Tracing through the code to find places that may be calling this, I can see that I have some of these errors too: https://github.com/GUI/lua-resty-auto-ssl/blob/0fe6ab67f091d75821a865d8d71122dc04e8ff0d/lib/resty/auto-ssl/ssl_certificate.lua#L77
With timeout being the reason the lock couldnt be created:
[error] 1850#1850: *576 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*

We're using redis as our storage adapter, if that matters? Thanks again for all of your help with this. If there's anything I can do to contribute back to the code for all that you've done, i'd be more than happy to.

It's happening maybe a couple of times an hour. I can't confirm or not whether this was introduced in v0.12.0, or whether it's been happening longer than that. I'm also not sure why it's only recently started causing our health checks to fail.
I've patched our production systems using the following commands:
cd /usr/local/openresty/luajit/share/lua/5.1
curl https://github.com/GUI/lua-resty-auto-ssl/commit/dcf9d73eb8b9c3b9ad7d59bd614271117c27af8a.patch -O
patch -p2 < dcf9d73eb8b9c3b9ad7d59bd614271117c27af8a.patch
/usr/local/openresty/bin/openresty -s reload

I'll keep an eye out for the log that means openresty has restarted and get some more context with hopefully some useful debug messages!
Thanks.

OK so it looks like it's possibly triggering that lock failure after a troublesome domain is hitting a LE rate limit:
err Processing xxxxxxxx.com
err + Signing domains...
err + Generating private key...
err + Generating signing request...
err + Requesting authorization for xxxxxxxx.com...
err err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 429)
err
err Details:
err {
err   "type": "urn:acme:error:rateLimited",
err   "detail": "Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
err   "status": 429
err }
err
err , context: ssl_certificate_by_lua*
error 2018/05/18 22:57:07 [error] 11670#11670: *651 [lua] ssl_certificate.lua:106: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*
error 2018/05/18 22:57:07 [error] 11670#11670: *651 [lua] ssl_certificate.lua:43: issue_cert_unlock(): auto-ssl: DEBUG: Cert unlock for: xxxxxxxx.com, context: ssl_certificate_by_lua*
error 2018/05/18 22:57:07 [error] 11670#11670: *651 [lua] ssl_certificate.lua:45: issue_cert_unlock(): auto-ssl: DEBUG: Cert unlock local for: xxxxxxxx.com, context: ssl_certificate_by_lua*
error 2018/05/18 22:57:07 [error] 11670#11670: *651 [lua] ssl_certificate.lua:53: issue_cert_unlock(): auto-ssl: DEBUG: Cert unlock distributed for: xxxxxxxx.com, context: ssl_certificate_by_lua*
error 2018/05/18 22:57:07 [error] 11670#11670: *651 [lua] storage.lua:129: issue_cert_unlock(): auto-ssl: DEBUG: storage:issue_cert_unlock: key=xxxxxxxx.com:issue_cert_lock lock_rand_value=718c8714c6591935f0adf3f62e6ca5f83556aa7a46257a5c1469cdfcf8225e27, context: ssl_certificate_by_lua*
error 2018/05/18 22:57:07 [error] 11670#11670: *651 [lua] ssl_certificate.lua:56: issue_cert_unlock(): auto-ssl: failed to unlock: lock does not match expected value (expected=718c8714c6591935f0adf3f62e6ca5f83556aa7a46257a5c1469cdfcf8225e27 actual=4b46d57cd023c17cf2978b70533c306e5c50691ef54d484babcfd7ccdb6df795), context: ssl_certificate_by_lua*

For some reason that random value isnt matching?

I am hitting the same rate limit and getting the same error, any news on this?

I'm going to have to turn off auto ssl as it's constantly crashing now, I can't see to find a way of improving the situation at all.

@domharrington  Can you provide your NGINX conf files so I can compare? I believe it might be a issue with having multi_accept on; active as I've disabled that and also stopped HTTP > HTTPS redirects and so far no more crashing has occurred.

Okay quick update I am still seeing the process crash out with the locking however it much less frequent now. Still not ideal, has anyone else made any progress on this issue?

Try adding another couple of instances behind a load balancer. That's mitigated most of the problems for us.

I haven't been able to reproduce this myself, but thanks for the help in debugging this everyone!
@domharrington: With the patched version from https://github.com/GUI/lua-resty-auto-ssl/compare/debug-locks, have you still been seeing nginx become unresponsive? The fact that you're seeing the "lock does not match expected value" errors is certainly curious and would seem to indicate some type of race condition. If that error was encountered, then I think I see how things could potentially deadlock in master, but the patched version should still unlock things in that case (rather than waiting for the lock values to match). So I'm curious if this situation might explain the unresponsive issues, but if nginx can still get stuck with these patches we still have some other issue to uncover.
@BuckinghamIO: Have you by any chance tried things with the debug patches and lock changes in https://github.com/GUI/lua-resty-auto-ssl/compare/debug-locks? If you're interested in trying those, let me know if you need any help patching your current installation.
You're notes about multi_accept are also interesting. I'm not sure I've used that setting before, but I can certainly debug more with that to see if it could possibly affect things. Regarding the HTTPS redirects you disable, can you provide more detail on how those redirects were implemented so I can also try debugging with those changes?
Thanks again!

I had the same error yesterday. The problem with mine was my server block was redirecting to https, so the challenge was unable to resolve, and ultimately hit the failure rate limit. I've hit this limit before, and did not have an issue with OpenResty becoming unresponsive before. Not sure why this time was different.
I've pasted the entire log if it is helpful. I separated the [alert] where it occurred ~line 72:
2018/07/02 20:49:54 [error] 1317#1317: *331 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=f0a3a5f93701549339bad858ec895b6f51178177e5727f3e939dfc45d45466eb HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/www.problematic-domain.com ...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for www.problematic-domain.com authorization...
Invalid challenge: DOMAIN=www.problematic-domain.com RESPONSE={
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Fetching http://www.problematic-domain.com/.well-known/acme-challenge/5GRE1vaqeX8HUJaomYuOPCSz2daTGnd0hpsaHrazAUs: Timeout during connect (likely firewall problem)",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/SFxYbrTYujMGri_8HCRoB5lH8ZrbDcsXMbm0Usn2Eo0/5423848866",
  "token": "5GRE1vaqeX8HUJaomYuOPCSz2daTGnd0hpsaHrazAUs",
  "keyAuthorization": "5GRE1vaqeX8HUJaomYuOPCSz2daTGnd0hpsaHrazAUs.iyFwioEEU2gsGRl51ToulQDLULu1gh7mfp9cpKV_nD8",
  "validationRecord": [
    {
      "url": "http://www.problematic-domain.com/.well-known/acme-challenge/5GRE1vaqeX8HUJaomYuOPCSz2daTGnd0hpsaHrazAUs",
      "hostname": "www.problematic-domain.com",
      "port": "80",
      "addressesResolved": [
        "<IP_ADDRESS>"
      ],
      "addressUsed": "<IP_ADDRESS>"
    }
  ]
}
 err: nil, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 20:49:54 [error] 1317#1317: *331 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 20:49:54 [error] 1317#1317: *331 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 20:50:07 [error] 1317#1317: *330 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=f0a3a5f93701549339bad858ec895b6f51178177e5727f3e939dfc45d45466eb HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for www.problematic-domain.com authorization...
Invalid challenge: DOMAIN=www.problematic-domain.com RESPONSE={
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Fetching http://www.problematic-domain.com/.well-known/acme-challenge/J-yQV6tHW-NwQous8k26Zq6dbmKOWSwyKrYs1iwF-8I: Timeout during connect (likely firewall problem)",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/T1qtVHixtK4L-3ykShUDkSvv3lqdfU8DOi_Chzko5TA/5423850452",
  "token": "J-yQV6tHW-NwQous8k26Zq6dbmKOWSwyKrYs1iwF-8I",
  "keyAuthorization": "J-yQV6tHW-NwQous8k26Zq6dbmKOWSwyKrYs1iwF-8I.iyFwioEEU2gsGRl51ToulQDLULu1gh7mfp9cpKV_nD8",
  "validationRecord": [
    {
      "url": "http://www.problematic-domain.com/.well-known/acme-challenge/J-yQV6tHW-NwQous8k26Zq6dbmKOWSwyKrYs1iwF-8I",
      "hostname": "www.problematic-domain.com",
      "port": "80",
      "addressesResolved": [
        "<IP_ADDRESS>"
      ],
      "addressUsed": "<IP_ADDRESS>"
    }
  ]
}
 err: nil, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 20:50:07 [error] 1317#1317: *330 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 20:50:07 [error] 1317#1317: *330 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443

****** auto_ssl locked *********
2018/07/02 22:37:27 [alert] 1315#1315: worker process 1317 exited on signal 9
2018/07/02 22:37:27 [alert] 1315#1315: shared memory zone "auto_ssl" was locked by 1317
****** auto_ssl locked *********

2018/07/02 22:39:51 [error] 1342#1342: *65 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:39:51 [error] 1342#1342: *65 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:18 [error] 1342#1342: *75 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:18 [error] 1342#1342: *75 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:18 [error] 1342#1342: *73 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:18 [error] 1342#1342: *73 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:20 [error] 1342#1342: *82 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:20 [error] 1342#1342: *82 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:51 [error] 1342#1342: *98 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:40:51 [error] 1342#1342: *98 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:41:21 [error] 1342#1342: *105 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:41:21 [error] 1342#1342: *105 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:41:54 [error] 1342#1342: *134 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=53905c0b9dbc62d0b4026d591231694ba00ce38fbb29c0d45f0f86f4441d25d4 HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for www.problematic-domain.com authorization...
Invalid challenge: DOMAIN=www.problematic-domain.com RESPONSE={
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Fetching https://www.problematic-domain.com/.well-known/acme-challenge/4cQiEWb7JmAFhgjTZBfbJHNVKvPuIq6w5aP0wlgzNI0: Error getting validation data",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/S_K4QA6wL-BIfVUgsjJu9VESFNMw92vTgRk6WblRV5M/5425284669",
  "token": "4cQiEWb7JmAFhgjTZBfbJHNVKvPuIq6w5aP0wlgzNI0",
  "keyAuthorization": "4cQiEWb7JmAFhgjTZBfbJHNVKvPuIq6w5aP0wlgzNI0.iyFwioEEU2gsGRl51ToulQDLULu1gh7mfp9cpKV_nD8",
  "validationRecord": [
    {
      "url": "http://www.problematic-domain.com/.well-known/acme-challenge/4cQiEWb7JmAFhgjTZBfbJHNVKvPuIq6w5aP0wlgzNI0",
      "hostname": "www.problematic-domain.com",
      "port": "80",
      "addressesResolved": [
        "<IP_ADDRESS>"
      ],
      "addressUsed": "<IP_ADDRESS>"
    },
    {
      "url": "https://www.problematic-domain.com/.well-known/acme-challenge/4cQiEWb7JmAFhgjTZBfbJHNVKvPuIq6w5aP0wlgzNI0",
      "hostname": "www.problematic-domain.com",
      "port": "443",
      "addressesResolved": [
        "<IP_ADDRESS>"
      ],
      "addressUsed": "<IP_ADDRESS>"
    }
  ]
}
 err: nil, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:41:54 [error] 1342#1342: *134 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:41:54 [error] 1342#1342: *134 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:42:22 [error] 1342#1342: *155 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:42:22 [error] 1342#1342: *155 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:42:52 [error] 1342#1342: *176 [lua] ssl_certificate.lua:68: issue_cert(): auto-ssl: failed to obtain lock: timeout, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:42:52 [error] 1342#1342: *176 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:43:59 [error] 1342#1342: *225 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=53905c0b9dbc62d0b4026d591231694ba00ce38fbb29c0d45f0f86f4441d25d4 HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 + 1 pending challenge(s)
 + Deploying challenge tokens...
 + Responding to challenge for www.problematic-domain.com authorization...
Invalid challenge: DOMAIN=www.problematic-domain.com RESPONSE={
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Fetching https://www.problematic-domain.com/.well-known/acme-challenge/x8kjiHlvQdO_OdHETaDGe8yeIA-STfF1RMYEBO73x8k: Error getting validation data",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/T2K0FcEDMpCnD7jfqZZDp-qWQEcAFuQWW4YXKU3JQ4o/5425313962",
  "token": "x8kjiHlvQdO_OdHETaDGe8yeIA-STfF1RMYEBO73x8k",
  "keyAuthorization": "x8kjiHlvQdO_OdHETaDGe8yeIA-STfF1RMYEBO73x8k.iyFwioEEU2gsGRl51ToulQDLULu1gh7mfp9cpKV_nD8",
  "validationRecord": [
    {
      "url": "http://www.problematic-domain.com/.well-known/acme-challenge/x8kjiHlvQdO_OdHETaDGe8yeIA-STfF1RMYEBO73x8k",
      "hostname": "www.problematic-domain.com",
      "port": "80",
      "addressesResolved": [
        "<IP_ADDRESS>"
      ],
      "addressUsed": "<IP_ADDRESS>"
    },
    {
      "url": "https://www.problematic-domain.com/.well-known/acme-challenge/x8kjiHlvQdO_OdHETaDGe8yeIA-STfF1RMYEBO73x8k",
      "hostname": "www.problematic-domain.com",
      "port": "443",
      "addressesResolved": [
        "<IP_ADDRESS>"
      ],
      "addressUsed": "<IP_ADDRESS>"
    }
  ]
}
 err: nil, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:43:59 [error] 1342#1342: *225 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:43:59 [error] 1342#1342: *225 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:45:32 [error] 1342#1342: *264 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=53905c0b9dbc62d0b4026d591231694ba00ce38fbb29c0d45f0f86f4441d25d4 HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 429)

Details:
{
  "type": "urn:acme:error:rateLimited",
  "detail": "Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}

, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:45:32 [error] 1342#1342: *264 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:45:32 [error] 1342#1342: *264 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:45:35 [error] 1342#1342: *303 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=53905c0b9dbc62d0b4026d591231694ba00ce38fbb29c0d45f0f86f4441d25d4 HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 429)

Details:
{
  "type": "urn:acme:error:rateLimited",
  "detail": "Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}

, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:45:35 [error] 1342#1342: *303 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:45:35 [error] 1342#1342: *303 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 22:57:20 [emerg] 1148#1148: "server" directive is not allowed here in /usr/local/openresty/nginx/conf/nginx.conf:60
2018/07/02 23:08:12 [error] 1337#1337: *73 [lua] lets_encrypt.lua:41: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=27862fd1c04cad17fbb6cdffedddbffc5c0b7a615c4cab7e25634e2987dbed2f HOOK_SERVER_PORT=8999 /usr/local/openresty/luajit/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain www.problematic-domain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/openresty/luajit/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
Processing www.problematic-domain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting authorization for www.problematic-domain.com...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 429)

Details:
{
  "type": "urn:acme:error:rateLimited",
  "detail": "Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}

, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 23:08:12 [error] 1337#1337: *73 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2018/07/02 23:08:12 [error] 1337#1337: *73 [lua] ssl_certificate.lua:286: auto-ssl: could not get certificate for www.problematic-domain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443

I believe I'm running into this exact same issue. I'm running a few instances and the master nginx process crashes every hour or two. The last thing in the error log is always similar to this:
{
  "type": "urn:acme:error:rateLimited",
  "detail": "Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}```

So far, it's one domain in particular that's causing the issue, so I've instructed resty to ignore it, but is this something I should expect to happen any time we get a `rateLimit` error?

This also happens for us when we try to request a domain that for some reason is not reachable by the letsencrypt check (for example when DNS has not propagated yet). In this case the logs just say nothing and the server does not respond until it's restarted. At the moment we ship around this by automatically issuing a restart when this happens, but it would be nice if we could get to the bottom of the locking issue.
Background info: We allow our users to access parts of our service via their own domains, and at the moment nginx has no way of finding out the exact set of domains to allow for issuing letsencrypt certs. So we just disallow issuing for a few known cases (IP addresses for example) but the 'fallback' is to allow requesting a cert.
If I can provide you with additional information or logs, please let me know!

@benzimmer I've noticed the exact same behavior.

At the moment we ship around this by automatically issuing a restart when this happens, but it would be nice if we could get to the bottom of the locking issue.

Are you somehow detecting the error as it happens? If so, how are you doing that?

@joshnabbott I just run monit with a http check on localhost, once it does not respond it automatically restarts nginx.

@benzimmer nice! I’ve been running a cron to perform a check with a script I write. Not sure why I didn’t think about monit first 🙃

Hit this issue almost every hour. Have to run an infinite loop to check Nginx status and kill Nginx processes if they are not responsive.

@RainFlying have you debugged it at all? Maybe if we all compared notes we could figure out what’s causing it. Anytime it’s happened to me and I’ve checked the logs before restarting, the thing in the error log is regarding a dehydrated failure. @benzimmer have you debugged this at all?
Anyway, I put a monit http check on each of my instances and haven’t had an outage since.

@RainFlying have you debugged it at all? Maybe if we all compared notes we could figure out what’s causing it. Anytime it’s happened to me and I’ve checked the logs before restarting, the thing in the error log is regarding a dehydrated failure. @benzimmer have you debugged this at all?
Anyway, I put a monit http check on each of my instances and haven’t had an outage since.

Hi, I haven't debugged yet. But after I turned off resty-auto-ssl, the Nginx processes work normally all the time. I guess it may be caused by the number of domains handled by resty-auto-ssl, the single Nginx server handled the ssl certificate application of almost one thousand domains.

@RainFlying it could be that, too. We also serve certs for about 1200 domains. Maybe with more workers it would function better?

@RainFlying it could be that, too. We also serve certs for about 1200 domains. Maybe with more workers it would function better?

I set the worker_processes as auto, Nginx should fork enough workers to process those requests?
May I ask what number of worker_processes have you set?
It may also be caused by lots of failed authorization requests, some of the name servers which locate in China mainland have issues serving DNS requests from places outside China. I have seen quite a few failed requests in the log file.

I just have ours set to the standard one worker per core, so 4 per instance. We run 4 instances total and we serve all requests with ssl.

@GUI  Any update on this? We've also been hit by this problem in a server with just 6 domains. Same urn:acme:error:rateLimited and shared memory zone "auto_ssl" was locked messages as others have already posted.

Getting this with just a couple of domains. Multiple times within an hour.

Having this issue as well, any solutions yet?

@shaunc869 I’d suggest using monit and adding an http check on the host (ours is a simple curl with a timeout flag). It’s not fixing the root of the problem, but we haven’t had issues since we added this.

Thanks @Adel-Magebinary for the insight, that's what happens in our case.
Unfortunately for people generating certs for their customers, thus not having access to their customer CloudFlare account to disable "Always redirect to SSL", there doesn't seem to by any solution. Or is there?
There's a post on CloudFlare requesting them to create an exception for LE validation. Perhaps if there's a lot of requests for it they'll do something about it at some point...

Interestingly though valid certs seem to be created at some point regardless of the error and prior to it.
When we try to reach the domain over HTTPS the request takes some time because auto-ssl is attempting to order a new cert, that fails because of CloudFlare's "Always redirect to SSL", but after the failure the page actually shows up with a valid cert. Yet, further requests will again attempt to order a new cert (taking some time, and fail again).
Is it possible LE actually succeeded in accessing /.well-known/acme-challenge/ over a broken HTTPS initially, but reported an error/warning, and auto-ssl is thus trying to re-issue a cert every time the URL is accessed again? If that's the case then there is a possible fix: ignore LE's warning/error when a cert was actually validated earlier. This is just a guess, I'm not familiar with auto-ssl and LE's validation process.
Our error logs are similar to ones reported by @bryanus above, apart that we get a 403 instead of a 400 error on the challenge. We also notice despite the validation status being "invalid" the presence of "validated": "2021-12-02T11:44:48Z". At the given date and time we find no auto-ssl error.
Initial failure:
2021/12/02 11:45:20 [error] 10122#10122: *1102095 [lua] lets_encrypt.lua:40: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=obfuscatedsecret HO
OK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain obfuscatedomain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/l
ocal/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
startup_hook
Processing obfuscatedomain.com
 + Creating new directory /etc/resty-auto-ssl/letsencrypt/certs/obfuscatedomain.com ...
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for obfuscatedomain.com
 + 1 pending challenge(s)
 + Deploying challenge tokens...
deploy_challenge
 + Responding to challenge for obfuscatedomain.com authorization...
invalid_challenge
Invalid challenge: DOMAIN=obfuscatedomain.com RESPONSE={
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "Invalid response from https://obfuscatedomain.com/.well-known/acme-challenge/OZ08EpHakmp-jz12UerK8bHsSQORKIEQxQWosjztF-w [2606:4700:20::681a:628]: \"\u003chtml\u003e\\n\u003chead\u003e\u00
3ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\\n\u003cbody\u003e\\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\\n\u003chr\u003e\u003ccenter\u003eopenre
sty\u003c/center\u003e\\n\u003c\"",
    "status": 403
  },
  "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/54755184260/WMuMfw",
  "token": "OZ08EpHakmp-jz12UerK8bHsSQORKIEQxQWosjztF-w",
  "validationRecord": [
    {
      "url": "http://obfuscatedomain.com/.well-known/acme-challenge/OZ08EpHakmp-jz12UerK8bHsSQORKIEQxQWosjztF-w",
      "hostname": "obfuscatedomain.com",
      "port": "80",
      "addressesResolved": [
        "<IP_ADDRESS>",
        "<IP_ADDRESS>",
        "<IP_ADDRESS>",
        "2606:4700:20::ac43:4a79",
        "2606:4700:20::681a:628",
        "2606:4700:20::681a:728"
      ],
      "addressUsed": "2606:4700:20::ac43:4a79"
    },
    {
      "url": "https://obfuscatedomain.com/.well-known/acme-challenge/OZ08EpHakmp-jz12UerK8bHsSQORKIEQxQWosjztF-w",
      "hostname": "obfuscatedomain.com",
      "port": "443",
      "addressesResolved": [
        "<IP_ADDRESS>",
        "<IP_ADDRESS>",
        "<IP_ADDRESS>",
        "2606:4700:20::681a:628",
        "2606:4700:20::ac43:4a79",
        "2606:4700:20::681a:728"
      ],
      "addressUsed": "2606:4700:20::681a:628"
    }
  ],
  "validated": "2021-12-02T11:44:48Z"
}
 err: nil, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2021/12/02 11:45:20 [error] 10122#10122: *1102095 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: 162.1
58.91.18, server: <IP_ADDRESS>:443
2021/12/02 11:45:20 [error] 10122#10122: *1102095 [lua] ssl_certificate.lua:53: issue_cert_unlock(): auto-ssl: failed to unlock: lock does not match expected value, context: ssl_certificate_by_lua*, clie
nt: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2021/12/02 11:45:20 [error] 10122#10122: *1102095 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for obfuscatedomain.com - using fallback - failed to get or issue certificate, context
: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443

After a while:
2021/12/03 10:22:09 [error] 15347#15347: *1556412 [lua] lets_encrypt.lua:40: issue_cert(): auto-ssl: dehydrated failed: env HOOK_SECRET=obfuscatedsecret HOOK_SERVER_PORT=8999 /usr/local/bin/resty-auto-ssl/dehydrated --cron --accept-terms --no-lock --domain obfuscatedomain.com --challenge http-01 --config /etc/resty-auto-ssl/letsencrypt/config --hook /usr/local/bin/resty-auto-ssl/letsencrypt_hooks status: 256 out: # INFO: Using main config file /etc/resty-auto-ssl/letsencrypt/config
startup_hook
Processing obfuscatedomain.com
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 err:   + ERROR: An error occurred while sending post-request to https://acme-v02.api.letsencrypt.org/acme/new-order (Status 429)

Details:
HTTP/2 429
server: nginx
date: Fri, 03 Dec 2021 10:22:09 GMT
content-type: application/problem+json
content-length: 201
boulder-requester: 123900029
cache-control: public, max-age=0, no-cache
link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
replay-nonce: 0102O2mIbRuBK2Fv2Kq5eZhD8XabKKslr_lLStswyR2qQrc

{
  "type": "urn:ietf:params:acme:error:rateLimited",
  "detail": "Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}

, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2021/12/03 10:22:09 [error] 15347#15347: *1556412 [lua] ssl_certificate.lua:97: issue_cert(): auto-ssl: issuing new certificate failed: dehydrated failure, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443
2021/12/03 10:22:09 [error] 15347#15347: *1556412 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for obfuscatedomain.com - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: <IP_ADDRESS>, server: <IP_ADDRESS>:443

@DoobleD @GUI  maybe there is a simple fix by triggering the certificate renewal 1 week before its expiration date?
Then we won't be running into the issue of an invalid certificate and the .acme will still be accessible via SSL.

Thanks for the suggestion @Adel-Magebinary! We've let the error run for now, we'll perhaps try that idea when we get back to it.


Update readme and ecoclient to list all commands

Firstly thank for writing this great tool.
I noted reference to set-metadata, however this was not mentioned in the README.md or listed in the help for ecoclient. Viewing the commands I see there are other commands not listed.
Many thanks in advance.

Oh yes, good shout. I should put in some words around recursion, get/put of DFS images too.
Thanks Neil, it may be a short while until I am able to get around to this but I appreciate the reminder. Pleased to hear someone is using the tool.
BTW, if you're looking for some idea of how to use these features in the meantime, check out the later pages on this stardot thread: https://stardot.org.uk/forums/viewtopic.php?t=26775&sid=9dbd8f30207b1b695ec35b65b9184276&start=150


Update Updates “notifications”

Automatically generated by Netlify CMS

Deploy preview for cms-demo ready!
Built with commit 943eb39f3e28a2dd1f73aa9bc578b9913f0a0640
https://deploy-preview-1856--cms-demo.netlify.com


Update snmp docstrings

Fixex #40

Added a couple more reviewers, since I'm off for vacation in less than an hour


MM-30076 Detox/E2E: Update UI test structure for reusability

Summary
Update UI test structure for reusability.
Move all UI screen/component at @support/ui

screen should match the screen we're using in the app to easily follow UI flow and make more readable
components are unit/section of the screen which may be used in different screen/component
all testIDs should be placed either in screen/component and not in the test (*.e2e.js) file as much as possible.
UI text can be in the screen/component or in the test file. No strict requirement currently.

Docs to follow.
Other changes:

testIDs

Ticket Link
Jira ticket - https://mattermost.atlassian.net/browse/MM-30076
Device Information
This PR was tested on: iOS simulator and Android emulator (both debug and release)

@josephbaylon Thanks for testing! Android failing tests should be fixed by https://github.com/mattermost/mattermost-mobile/pull/4931/commits/1edf38b81bc393d453c8cf608aeac3a34cc3178b. I can't repro the failing tests on iOS. It's consistently passing on me. I did a cleanup in Autocomplete - https://github.com/mattermost/mattermost-mobile/pull/4931/commits/d674ba6414c81826a231a1cc216568f900484f97. Please try again.

Thanks and yes, docs on the way.


RNW project support matrix (by language) is incomplete

RNW technically supports projects (both host apps and native modules) written in C++/WinRT and C#. However, support for mixing these project types is incomplete, inconsistent, and ultimately confusing due to their mixed support by VS/MSBuild.
This is a tracking issue to capture which scenarios actually work, with links to examples and/or the specific issues blocking the scenario. As we move to fill these gaps, hopefully this issue will help guide developers in making appropriate decisions for their own projects.
Notes:
"Pass ✅" means that everything works, and you can ship on it. You can build, debug, package, deploy, and launch all configurations (Debug/Release), on all platforms (x86/x64/ARM/ARM64), and any runtime errors will be due to the app/module code itself, not toolchain issues.
"Partial 🟨" means that some parts of the scenario work. See the footnote for the relevant issue(s).
"Fail 🟥" means the scenario does not work in a fundamental way.
"Untested ❔" means the scenarios has yet to be tested.
RNW 0.63

C++ App (Default)
C# App

C++ Module
Pass ✅: (SampleAppCpp + SampleLibraryCpp)
Pass ✅: (SampleAppCS + SampleLibraryCpp)

C++ Module w/ C++ Nuget Dependency
Pass ✅: (CameraDemo + React Native Camera)
Pass ✅: (Test App + React Native Camera)

C++ Module w/ C# Nuget Dependency
Fail 🟥1
Fail 🟥1

C# Module
Partial 🟨2: (SampleAppCpp + SampleLibraryCS)
Pass ✅: (SampleAppCS + SampleLibraryCS)

C# Module w/ C# Nuget Dependency
Fail 🟥2,3: (Test App + Lottie React Native)
Pass ✅: (Example + Lottie React Native)

C# Module w/ C++ Nuget Dependency
Fail 🟥2,3: (SampleAppCpp + SampleLibraryCS + huycn.zxingxpp.winrt)
Pass ✅: (SampleAppCS + SampleLibraryCS + huycn.zxingxpp.winrt)

1: C++/WinRT based projects (app or module) are unable to consume C# nugets
2: C++/WinRT-based apps consuming C# native modules (which use reflection) cannot use .NetNative, and therefore may be unable to actually ship
3:  C++/WinRT based apps are unable to consume C# native modules that contain nuget dependencies
RNW 0.62

C++ App (Default)
C# App

C++ Module
Pass ✅: (SampleAppCpp + SampleLibraryCpp)
Pass ✅: (SampleAppCS + SampleLibraryCpp)

C++ Module w/ C++ Nuget Dependency
Partial 🟨1: (CameraDemo + React Native Camera)
Pass ✅: (Test App + React Native Camera)

C++ Module w/ C# Nuget Dependency
Fail 🟥2
Fail 🟥2

C# Module
Partial 🟨3: (SampleAppCpp + SampleLibraryCS)
Pass ✅: (SampleAppCS + SampleLibraryCS)

C# Module w/ C# Nuget Dependency
Fail 🟥1,3,4: (Test App + Lottie React Native)
Pass ✅: (Example + Lottie React Native)

C# Module w/ C++ Nuget Dependency
Fail 🟥1,3,4: (SampleAppCpp + SampleLibraryCS + huycn.zxingxpp.winrt)
Pass ✅: (SampleAppCS + SampleLibraryCS + huycn.zxingxpp.winrt)

1: Binary dependencies of native modules are not included for C++ apps when deploying via run-windows (using VS or Release mode works)
2: C++/WinRT based projects (app or module) are unable to consume C# nugets
3: C++/WinRT-based apps consuming C# native modules (which use reflection) cannot use .NetNative, and therefore may be unable to actually ship
4:  C++/WinRT based apps are unable to consume C# native modules that contain nuget dependencies

We need some representation of this in the docs. It doesn't mean it needs to be in this format, and this issue should continue to exist with the full details. But we need to help app authors make decisions that send them down the golden path and avoid gremlins. The existing warnings are not enough, based on the incoming issues we see of developers running into the gremlins here. Perhaps a top level topic of "Language Choice" or more to the point "Mixing C++ and C#".

While we may want to put a table like this into the docs, this isn't a docs issue. Given the number of developers that hit this, I honestly think this should be pinned in the main repo, not hidden away here off the radar.


[DeviceLayer] Add SetupPinCode and SetupDiscriminator to configuration manager

Problem
Current, configuration manager still uses PairingCode and missing SetupDiscriminator, which is required to generate QR code and BLE advertisement.
Solution
Modify configutation manager to include them.
fixes #1654

@gjc13 PTAL

@erjiaqing FYI, builds fail

@saurabhst @jelderton @BroderickCarlin ?


wip: add PyTupleMethods

Implements PyTupleMethods for #3382.
This is a draft, because I found two things need to be implemented first:

PySequenceMethods trait, I'll do that in a separate PR first.
I found I wanted a borrowed pointer that wasn't a pointer-to-pointer, so I began experimenting with a Py2Borrowed type. I'm going to split that out into a separate PR first as it deserves its own discussion.

Superseded by #3681


Add docs for batch_run/5

Somewhat frequently there are questions on Slack surrounding batch_run in dataloader. I've added some docs regarding what I use batch_run for frequently, namely doing stuff like post_count, comment_count etc.
I might also add some docs regarding dataloader and batch_run in the Absinthe repo.

Fantastic, thank you!


Fix links to point to ardupilot.org

Update to fix ardupilot.org links and make forum.ardupilot.org default

Larvely thanks!


chore: update dependencies

❓ Type of change
dependencies
📚 Description
Updated dependencies to resolve https://avd.aquasec.com/nvd/2022/cve-2022-29622/

Looks like superagent shipped some breaking changes? Or maybe just flakky test? need to investigate

i had another look at it but can't seem to identify why while handling response in superagent is getting timed out  and this is specifically happening with multipart form data.
I found similar issues on superagent: https://github.com/ladjs/superagent/issues/1799
However the advisory was withdrawn last night, https://github.com/advisories/GHSA-8cp3-66vr-3r4c


Rework shell help

I have decided to remove options concept as it was not used by anyone. Options are commands starting with -. From user perspective I have removed:

macro to create options: SHELL_OPT
help functionality to print options help string when command is called with -h or --help
Command and its subcommands help string will be still available when user will call it with -h or --help.

As a result this change allowed to simplify help usage. With new implementation user will not need to bother to implement help handler inside a command handler. In addition it shall save a lot of flash  by removing already implemented help handlers.
Apart from that I have moved shell help functionality to separate module: shell_help.c and shell_help.h and I've update CMakeList accordingly.
And last but not least I have removed shell_cmd_precheck from API and command handlers and replaced it with recently added macros: SHELL_CMD_ARG_REGISTER and SHELL_CMD_ARG. This change also saved some Flash.

Codecov Report

Merging #11664 into master will decrease coverage by 0.06%.
The diff coverage is 70.05%.

@@            Coverage Diff             @@
##           master   #11664      +/-   ##
==========================================
- Coverage   48.23%   48.16%   -0.07%
==========================================
  Files         279      279
  Lines       43291    43210      -81
  Branches    10359    10337      -22
==========================================
- Hits        20881    20814      -67
+ Misses      18270    18252      -18
- Partials     4140     4144       +4

Impacted Files
Coverage Δ

subsys/shell/shell_ops.h
52.63% <ø> (ø)
:arrow_up:

subsys/shell/shell_utils.h
80% <100%> (+30%)
:arrow_up:

subsys/shell/shell_ops.c
21.56% <41.17%> (+2.45%)
:arrow_up:

subsys/shell/shell_utils.c
39.89% <55.17%> (+1.57%)
:arrow_up:

subsys/shell/shell.c
29.04% <63.88%> (-6.75%)
:arrow_down:

subsys/shell/shell_help.c
74.39% <74.39%> (ø)

subsys/shell/shell_cmds.c
49.61% <93.33%> (-14.52%)
:arrow_down:

subsys/shell/shell_history.c
71.92% <0%> (-3.51%)
:arrow_down:

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 80a8cfc...c13d4d5. Read the comment docs.

@jarz-nordic looks pretty good, I've had something similar in mind when I was introduce the ARG variants.

@nordic-krch : Fix you have proposed (offline) for static assert looks fine. However I think it shall be introduced with different PR.

@nordic-krch : May you please re-review?

@carlescufi @nashif : Can we merge this PR? It simplifies commands implementation and decreases flash usage.


Test React SDK

Is this feature related to a problem? Please describe.
React SDK is not tested.
Describe the solution you'd like
Write tests using React Testing Library.

I’m available to work on this

Hi @od-hunter , go ahead, let me know if you need any assistance.

Hi @ooochoche, there will be other issues open for contribution in near future, thanks for offering!

Hello @gershon , so sorry I wouldn’t be able to do this anymore, @ooochoche can just go ahead. Decided to let you know on time. My apologies please.🙏🏼

Hi @gershon can I take this up?

Hey @gershon ,
i am handling this request in #451 , let me know if this has to be mock unit tests or workflow tests ? thanks

Hi @dhruvmalik007 , we are closing this issue as we are preparing a new release with SDK react test setup. There will be other issues listed for improving tests.

ah well I had completed with the current one with list auctions and full fill auction. ok atleast keep the branch available so that i can improve the test .

@dhruvmalik007, thanks for your contributions! You can follow https://github.com/ArkProjectNFTs/ark-project/pull/440 for v2 updates, which should be released soon.


docs(samples): add runReport samples for ordering, pagination, property quota

I'd like to mere #206 before merging these samples. Thanks!

@sofisl codeowner review is required to merge


Size

How  do you reduce the size of the pie chart?

The easiest way is to wrap it in an element with dimensions set. Something like
<div style={{ width: 100 }}>
  <PieChart />
</div>

Thanks for responding. It works.
i am closing it .


[Feature]: Library Filtering

Guidelines

[X] I agree to follow this project's Contributing Guidelines.

Description
Hannah Sherrod gave me this idea. What if we could allow people to filter the library by the spectra in the libraries signal to noise ratio? Also could be good to allow filtering by material type, organization, etc. This would ideally happen before anything is shown to the user.
Problem
library difficult to filter.
Proposed Solution
Add additional filter options.
Alternatives Considered
Potentially this could make the tool more complicated to use.

filtering is already implimented to some extent.


Call out go version required to get client

Proposed changes
If you have an old version of go installed on your machine the instruction to
go get github.com/docker/docker/client fails.
ref https://forums.docker.com/t/possible-doc-bug-for-go-client/47374?u=rkielty
I think that go 1.8 is the required minimum based on the following :

https://forums.docker.com/t/possible-doc-bug-for-go-client/47374/2?u=rkielty Thanks David Maze!
I have tested this with go 1.6.2 where it failed as described above
I have tested this with go 1.10 where it succeed

I cannot find a statement where the required minimum go version to get the client is called out
I checked the above doc along with

https://godoc.org/github.com/docker/docker/client
https://github.com/moby/moby/blob/master/client/README.md

I found a reference to a golang version in this commit, Bump Golang to 1.9.4
Bump Golang to 1.9.4 - caeab268430
So I suppose that given that caeab268430 references a vulnerability being fixed this change should bump to 1.9.4?

Sorry this took so very long. Good to go.


Update to Node.js 16, add ncc for prepare script

Fixes #1, tested on my own fork of the CircuitPython TestRepo.

I added the ability to use npm run prepare just like the current template action, so I added it to node_modules/.  But it's true that it isn't strictly needed for the action itself to function.

I still don't understand why it is checked in. The template you linked to doesn't have a node_modules folder.

I saw that there were already other things in the node_modules folder in this repo so I added it, but I can remove that specific package if you want.  I'm new to Node.js so I don't truly understand any of the implications of these sort of things, so happy to remove the ncc dependency if that's best.

Haha! I added the other ones. Whoops.
This is fine. :-)

Awesome, thanks!

I'm going to release this and push this as an update to v1 since nothing changed functionally, and this way the libraries won't need a patch.  Let me know if you prefer a v2 tag.


updated exception when refreshing module

I've found that different PageNotFoundException is thrown in Xots code used to refresh a module. Not sure when it changed, but on Domino V12 it is com.ibm.xsp.page.PageNotFoundException.

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Ah, good catch - thanks!


feat(FN-3450-51): added banner if read only and fixed text to only show if not read only

Introduction :pencil2:
This PR adds a notification banner if read only on utilisation report page and conditionally shows text on trade-finance-manager-ui\templates\utilisation-reports\utilisation-report-reconciliation-for-report.njk
Resolution :heavy_check_mark:

Added notification banner to only show if PDC_READ user
Added text on utilisation-report-reconciliation-for-report.njk to only show conditionally if not read-only
Updated tests

Can we add some context to the PR title i.e what area this affects? E.g something like this
"X area - read only banner, content fix"


feature request | add edittext to pick color

add place to color picker dialog where can be color inputed by keyboard in rgb or hex

Definitely like this idea.  Not sure if I'll have time to get this into the next release, but I'll for sure keep this in mind afterward.

thanks


global: migrate CI to gh-actions

closes #188

CI probably fixable locally -> https://github.com/inveniosoftware/invenio-oaiserver/pull/189/checks?check_run_id=1524277105#step:7:14 @ParthS007

Opened another issue for fixing tests: https://github.com/inveniosoftware/invenio-oaiserver/issues/190


Feature/mission-controls-button-styles

https://trello.com/c/obzk8UyU/650-fix-styling-on-modal

match button styling to rest of web app
increase font size of button, make more readable
center button
increase size of "x", move to the top, right of the modal
make modal responsive
make the button match the theme of the other buttons in this app for design consistency

You need to rollback (revert) package-lock.json before we can merge into main.

 I think that command will also automatically stage the file, so then just commit and push and you should be good.


What do I do if my xpath is returning false?

My transformation xpath (e.g. not(//ancestor-or-self::cac:Signature)) is returning a false value. Because of this, canonicalizeData method will also give me an empty string (but I still need this exact same transform value to be there).
I have checked the original xmlseclibs library and it doesn't do a loop. Would it be possible to start with a fresh copy of objData at the start of each foreach iteration, or would that ruin the whole purpose of the transforms since the xpath doesn't seem to be correct anyway?

You will be able to see from the last changed dates in the repository it's not been update in some time so my response is going to be affected by that.
Things may have changed but three years ago xmlseclibs did not implement transformations well.  Maybe that's why there's no loop?  Based on the information provided it's not really possible to give much of an answer.  Does the  containing XPath element include a namespace for 'cac'?

Yup, the XML looks something like this:
https://sdk.myinvois.hasil.gov.my/files/one-doc-signed.xml

Update - I found that the xpath query actually is returning some namespaces. So now I will just try to figure out why the C14N method that is giving us an empty string.

Good idea.  On the way to work it occurred to me to me maybe the parameters passed to the C14N function are not right.
But you might check the  element.  Here is an example from the specification:
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
  <XPath xmlns:dsig="&dsig;">
    not(ancestor-or-self::dsig:Signature)
  </XPath>
</Transform>

You can see the  element is being passed the namespace of the  element to exclude.  Your example does not include a definition for the 'cac' namespace.
<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
  <ds:XPath>not(//ancestor-or-self::ext:UBLExtensions)</ds:XPath>
</ds:Transform>

If the C14N function is not passed the namespace for 'cac' it will not be able to find the elements.  Maybe this will have an effect?
I do not have any experience using a signature that is in a namespace that is not 'http://www.w3.org/2000/09/xmldsig#'.  It maybe the code expects to use the DSig namespace not the cac namespace.

The namespace is there because I tried to change the xpath to (ancestor-or-self::cac:Signature) and it worked. Something seems to be up with this "not" in XPath here - it can't select anything even in XPath testers. I believe this is the reason why the C14N method wasn't able to detect the path. As a result the document also probably has not been canonicalized at all.
If it turns out that the XPath is really screwed, I might consider a workaround where I manually canonicalize and append transform nodes.
Thakns for the help!


Text color of the 'likes modal'

It appears that the 'Likes modal' text color was the User-Agent default. So I added an entry to use --text-color-3.
UA default

text-color-3

🙏

Thank you!!!


python3 compatible - nullptr -> str(ifdir)

Hi, the change is valid. However, the problem is that the ifdir is not found. I guess that's okay if you are not building an installer.


separated etcd cluster does not work out of the box

I have a script that shows this:
chef_etc_cluster_separate
will post more details later, when I've left it running for a couple of hours to prove.

https://github.com/ianmiell/shutit-openshift-cluster/tree/chef_etcd_cluster_separate

I think this is still a problem, just been reminded of it by having to rebase my branch!

This has just hit us while trying to move an etcd cluster. Would you like more details?
Also: we found that chef tries to deploy docker on pure etcd nodes. Is it worth thinking about taking the docker installation out of common, or is this deliberate? Happy to work on this/these myself.

Hi Ian,
We left the Docker installation in common because of containerised deployment. When people do not use RPMs and they do docker installation of etcd, we still need docker.
Yes please if you can give more details on what happened, we can definitely work on a fix for you.

Spoke to Will last week, I think he understands the problem now :)

Gentle reminder about this @IshentRas :)

Have been thinking about this again this morning.
Do you think it makes sense to have all the certs created and stored on the first master and retrieved from there?
Remember that the problem is that when we move the etcd servers, the certs appear to be 'missing' when the first etcd server != first master server.
Another thought is 'what happens if/when the first master dies'?

Hi Ian,
I have been doing a lot of tests so far regarding that one I am unable to reproduce that issue.
My approach so far has been ETCD MASTER CERTIFICATE (EM) ETCD (E) NEW ETCD (NE):

EM - E - E
EM - E - E - NE - NE - NE
NE - NE - NE
Redeploy cert -> EM - NE - NE

What I think you need is a way to override the default logic for finding the first ETCD which is so far the use first server in the list of etcd_servers.
Regarding the question over losing the first master, it is not an issue as we have got now the redeploy certificates option which deals with those issues.
I have got time this weekend and I shall prepare a new logic or extend the logic to override the first master for certificate retrieval.

This makes sense - I have not looked at the redeploy cert option yet, as
our work predated that.
What you suggest will likely cover it.
On Thu, Feb 2, 2017 at 9:54 AM, William Burton<EMAIL_ADDRESS>wrote:

Hi Ian,
I have been doing a lot of tests so far regarding that one I am unable to
reproduce that issue.
My approach so far has been ETCD MASTER CERTIFICATE (EM) ETCD (E) NEW ETCD
(NE):

EM - E - E
EM - E - E - NE - NE - NE
NE - NE - NE
Redeploy cert -> EM - NE - NE

What I think you need is a way to override the default logic for finding
the first ETCD which is so far the use first server in the list of
etcd_servers.
Regarding the question over losing the first master, it is not an issue as
we have got now the redeploy certificates option which deals with those
issues.
I have got time this weekend and I shall prepare a new logic or extend the
logic to override the first master for certificate retrieval.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/IshentRas/cookbook-openshift3/issues/27#issuecomment-276913599,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGrczVfDUAwM9TEudi19PxsK28l0--OJks5rYafYgaJpZM4K_Pt6
.

--
My book on Docker in Practice: Get 39% off with the code 39miell
http://manning.com/miell/?a_aid=zwischenzugs&a_bid=e0d48f62

But you are right, I'll work on a mechanism to override the logic.
Signed. Murphy's law

Hey @ianmiell I have been working on a nice way to replace a failed member in addition to the migration you are referring above.
I came to the conclusion that it will be possible to automate if needed but the logic should be one by one. The limitation is ETCD can add members one by one and therefore there is not way we can predict which members from the failed one we are trying to replace have already joined the cluster...
Ex. you have a cluster of 3 and you lose 2 -> 1 survivor that you need before doing anything to reinitialise as cluster of 1 (Not a big deal here)
Unfortunately for 2 and 3, the cluster will give you what to put one by one as ETCD does not accept bulk actions.
So :-1:
a) Add srv-2 --> srv-1 will tell you : members = srv-1,svr-102 (If you put anything more, it does not work).
b) Once 2 is ok and you add srv-3, the master will tell you: memebrs = srv-1,srv-2,srv-3
c) and so on...
[root@srv-101 ~]# etcdctl -C $ETCD_SERVER --cert-file $CRT --key-file $KEY --ca-file $CA member add srv-102.domain.local https://<IP_ADDRESS>:2380
Added member named srv-102.domain.local with ID cb479d70680bd430 to cluster
ETCD_NAME="srv-102.domain.local"
ETCD_INITIAL_CLUSTER="srv-101.domain.local=https://<IP_ADDRESS>:2380,srv-102.domain.local=https://<IP_ADDRESS>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
[root@srv-101 ~]# etcdctl -C $ETCD_SERVER --cert-file $CRT --key-file $KEY --ca-file $CA member add srv-103.domain.local https://<IP_ADDRESS>:2380
Added member named srv-103.domain.local with ID cb479d70680sss221 to cluster
ETCD_NAME="srv-103.domain.local"
ETCD_INITIAL_CLUSTER="srv-101.domain.local=https://<IP_ADDRESS>:2380,srv-102.domain.local=https://<IP_ADDRESS>:2380,srv-103.domain.local=https://<IP_ADDRESS>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
Therefore, we cannot do that action in one shot.
Instead, we shall perform that action 1 by 1. Still finalising the logic. Thoughts?

yup, looks similar to:
https://github.com/ianmiell/shutit-openshift-cluster/blob/chef_etcd_migration/shutit_openshift_cluster.py#L434-L558
On Sat, Feb 4, 2017 at 3:01 PM, William Burton<EMAIL_ADDRESS>wrote:

Hey @ianmiell https://github.com/ianmiell I have been working on a nice
way to replace a failed member in addition to the migration you are
referring above.
I came to the conclusion that it will be possible to automate if needed
but the logic should be one by one. The limitation is ETCD can add members
one by one and therefore there is not way we can predict which members from
the failed one we are trying to replace have already joined the cluster...
Ex. you have a cluster of 3 and you lose 2 -> 1 survivor that you need
before doing anything to reinitialise as cluster of 1 (Not a big deal here)
Unfortunately for 2 and 3, the cluster will give you what to put one by
one as ETCD does not accept bulk actions.
So 👎
a) Add srv-2 --> srv-1 will tell you : members = srv-1,svr-102 (If you put
anything more, it does not work).
b) Once 2 is ok and you add srv-3, the master will tell you: memebrs =
srv-1,srv-2,srv-3
c) and so on...
[root@srv-101 ~]# etcdctl -C $ETCD_SERVER --cert-file $CRT --key-file
$KEY --ca-file $CA member add srv-102.domain.local
https://<IP_ADDRESS>:2380
Added member named srv-102.domain.local with ID cb479d70680bd430 to cluster
ETCD_NAME="srv-102.domain.local"
ETCD_INITIAL_CLUSTER="srv-101.domain.local=https://192.168.
122.101:2380,srv-102.domain.local=https://<IP_ADDRESS>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
[root@srv-101 ~]# etcdctl -C $ETCD_SERVER --cert-file $CRT --key-file
$KEY --ca-file $CA member add srv-103.domain.local
https://<IP_ADDRESS>:2380
Added member named srv-103.domain.local with ID cb479d70680sss221 to
cluster
ETCD_NAME="srv-103.domain.local"
ETCD_INITIAL_CLUSTER="srv-101.domain.local=https://192.168.
122.101:2380,srv-102.domain.local=https://<IP_ADDRESS>:
2380,srv-103.domain.local=https://<IP_ADDRESS>:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"
Therefore, we cannot do that action in one shot.
Instead, we shall perform that action 1 by 1. Still finalising the logic.
Thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IshentRas/cookbook-openshift3/issues/27#issuecomment-277451325,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGrczVvQhrnnqXen8aIo5xCIFM7xOJ0Qks5rZJK3gaJpZM4K_Pt6
.

--
My book on Docker in Practice: Get 39% off with the code 39miell
http://manning.com/miell/?a_aid=zwischenzugs&a_bid=e0d48f62

@ianmiell Whilst I was working on the ETCD logic I noticed that adding new etcd servers was not covered by the code at all. Which is not really nice.
Therefore I have just put the logic to give people the capacity of adding new etcd servers within an existing cluster.
https://github.com/IshentRas/cookbook-openshift3/tree/enhance_etcd

Next step adhoc commands to remove/replace etcd members

Exactly - as I said, I don't think anyone else has done this before!
On Sun, Feb 5, 2017 at 3:16 PM, William Burton<EMAIL_ADDRESS>wrote:

Next step adhoc commands to remove/replace etcd members
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/IshentRas/cookbook-openshift3/issues/27#issuecomment-277526012,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGrczaxQQbEUHOLVfqC7623bydJ_xzZbks5rZee1gaJpZM4K_Pt6
.

--
My book on Docker in Practice: Get 39% off with the code 39miell
http://manning.com/miell/?a_aid=zwischenzugs&a_bid=e0d48f62

I am now confident about this topic. I am about to push the new logic of removing etcd servers from the cluster. That being said, it will simplify the logic of migrating etcd functionality from a set of nodes to new nodes as the following:

Masters share ETCD functionality
M1 M2 M3
Add new dedicated ETCD servers
E1 E2 E3
List of etcd_servers => M1 M2 M3 E1 E2 E3 => (Certificate retreival is done from M1)
Remove Masters as ETCD
node_to_be_removed => M1 M2 M3
List of etcd_servers => E1 E2 E3
Redeploy certs for new set E1 E2 E3 => (Future work for certificates will be handled by E1)

Yes, makes sense. Tho must be careful to remove only after 3 new nodes have received data/. etcd is generally bigger than I expect it to be.

Just added the functionality now :+1:

@ianmiell should worth adding if needed:
Reject reconfiguration requests that would cause quorum loss.
strict-reconfig-check: true

The only point/use case missing here is the following one:
ETCD_CLUSTER = E1 E2 E3

Remove E3 due to issues... (whatever it might be)
==> New cluster = E1 E2
Add E3 back after fixing stuff.
==> Error from E3 which did not clean it /var/lib/etcd data....

Need a new flag to handle ths situation, when the system will clean the data repo before starting etcd.
Not needed if the server is new from scratch.

Ok, I am done with above :+1:
I am now handling the case of re-inserting the pre-existed member (Need to clear its data directory before joining the cluster)

Not sure I follow completely, but losing and adding the same node is not a scenario I think is needed.
In that case, it should be ok to drop it from the etcd cluster, wipe all the data and then re-add separately. It would be like there were two separate servers.
But in any case, the use case will be odd and rare.


[4.0.2] Focus on window ends up switching workspace

Hi!
I'm running a dual monitor setup and often times I'll have two separate windows of chrome running in separate workspaces on separate monitors. When I focus on one window of chrome, it will switch the workspace on the other monitor to show my other chrome window. Is there any way to prevent this?

I don't have access to an external monitor at this moment, but I remember this issue being a thing.
Are you able to reproduce this with other browsers (or other applications in general), or is it only happening with Chrome?

No it happens with pretty much any application that has multiple windows open on different monitors

Does this only happen when Kwm is running?
How is the behaviour by default on MacOS without any applications intefering?

I don't think this has happened for me since updating to v4.0.4

@koekeishiya I think so. I can't get it to happen when kwm isn't running, although it's hard to replicate since kwm focuses the window on hover (instead of me having to click on it).  I'm currently on version v.4.0.3 so I'll update today and report whether the issue has gone away.

This problem still exists on v4.0.4


Bulk unpublish to add associations - PMID 32929287

Please unpublish all studies for PMID '32929287'
I will then add associations through depocuration app and ask to republish.

@earlEBI have unpublished the studies kindly confirm

@earlEBI the studies have been published

@sajo-ebi great thanks!


Missing "selected" style in navbar summary link

Once navigating to the course summary page from the navbar the link is missing the selected state:

HOW IT SHOULD LOOK LIKE (see Kyselyni)

hey Rem, can this be assigned to me?


add naming capability to the RobotInterface

Often wrappers are build around the RobotInterface to store additional information about the robot.
This should not be necessary for the most basic information like the name of the robot.
Therefore, the RobotInterface should contain a name property.

Changes have been reviewed and merged


Platform-specific APIs.

There are various APIs which are specific to a platform (i.e. have no corresponding APIs on other platforms) but would still be useful to be accessed from Avalonia.
One example of this which recently came up is NSWindowLevel on macOS: other platforms don't have an equivalent so it doesn't make sense as a general API, but still it's really useful in certain situations to be able to set this for a window.
One way of providing these APIs might be as attached properties, for example one could set:
<Window MacOS.WindowLevel="FloatingWindow">

Such a property would only have effect when running on macOS.
The main question with regards to such APIs, is in which assembly should they live?
So, a few questions to start the ball rolling:

Is it a good idea to provide such APIs?
Which APIs might be good candidates?
Is the attached property idea a good one?
Where should the APIs live?

Is it a good idea to provide such APIs?

Yes

Is the attached property idea a good one?

This is a really good idea. It's perfectly clear this is platform specific and also doesn't exist on the shared type. The syntax is really nice too!

Where should the APIs live?

I've often thought Avalonia should have an Avalonia.Platforms parent directory. Then all platform implementations go in there. Avalonia.Android, Avalonia.X11, etc. That would really clean up the main src directory IMO.
Then these types of attached properties should probably go inside a PlatformIntegration directory or something within the specific platform. Then you can have files for Window.cs, etc and inside there put whatever platform specific code.
Alternatively, the idea started with Xamarin is to have Window.cs and Window.macOS.cs, etc. Platform specific code is in a partial class file next to the shared code. The file suffix states the platform. Not a huge fan of this for Avalonia though as it's extremely rare to need platform specific code so far. It makes more sense to be with the platform implementations.

Note that an app using some platform features in XAML should not be forced to reference a platform backend when running on a different platform. Especially since one can't reference wasm, mobile and desktop at the same time.

The support code can live where it wants to live, but the API should still be accessible when targeting netstandard2.0 with only Avalonia package referenced.

And it will nice to support platform suffix .cs compilation.

@workgroupengineering it won't work if XAML project uses generic .netstandard of .net6.0 target (not a platform specific one). It's not a problem in MAUI, where you have a new target for each platform. And every third party library can target all platforms at once to get this XAML compilation-time trimming.
That's why we want a different way in our implementation of OnPlatform extension. Where we rely on postproccessing linker trimming depending on runtime identifier of the actual application (i.e., libraries contain all the branches of OnPlatform as they are platform agnostic).

And it will nice to support platform suffix .cs compilation.

Unrelated to this issue.
And you already have it in the SDK - ExcludeFromCurrentConfiguration. It can be done with simple msbuild condition.
Like this one - https://github.com/AvaloniaUI/Avalonia/pull/9613/files#diff-f187e1f8a2658efbbfc23efe2c18a51c40156749cf078645534481518139779eR80-R102
Note, "linux" and "browser" branches will not work...because there are no targets for these platforms. Yet?


Request for jackson cbor version bump to latest version

Localstack-java-utils is currently using older version of jackson-dataformat-cbor
Please update it to use the latest version which is:
<groupId>com.fasterxml.jackson.dataformat</groupId>             <artifactId>jackson-dataformat-cbor</artifactId>             <version>2.15.2</version>             <scope>test</scope>  </dependency>
This will remove the Vulnerability that jackson library brings

Hi @jjeongatl!
As mentioned in the README, this library is not really actively maintained. We suggest using the great tools from testcontaintainers instead.
Would it be possible to migrate to testcontainers instead of using this library?
It not, would you mind creating a PR updating the dependency?

Since we didn't get any responses here, I will close this issue for now...


Race condition during character minting

The possibility for race condition is correctly called out in kreadKit.js:299-302. In character.mint() there is an interleaving hazard that can lead to a time-of-check-to-time-of-use (TOCTOU) race condition. The cause is that we have await between the time-of-check and time-of-use, meaning the execution can yield to another context where similar code can run before the state is written.
The TOCTOU can occur in a scenario where two or more offers to mint a character "joe" occur at nearly the same time:

The first offer is processed and the name uniqueness check occurs in line 265. Since "joe" is not in the entries, the check is successful
The code for the first offer reaches reaches the await in line 273. There is also an await during the recorder writing, which is another point where execution of processing another offer can occur.
Any subsequent offers during this time will pass the uniqueness check as the entry has not been updated yet while creation is in process. As a result multiple characters named "joe" can be created, and as pointed out in line 299-302, base character is deleted multiple times.
The last offer to be processed will write to the recorder in line 304 and overwrite all the ones just created. Similarly, the character state entries in line 355 will be overwritten with the last one.

By the time the offers are processed, we will have deleted from the base character entry multiple times, and overwritten both the character state entry and the recorder entries.
Note: the code in the await, and therefore the time window, seem very small, making this an unlikely scenario.
I believe to prevent this we'd have to reorder the operations such that there are no await between when character name is checked and added to the collection:

Once name uniqueness is checked, write to the collection immediately
Write the recorder entry
Delete the base character

https://github.com/Kryha/KREAd/blob/8c74d68e64016b3ddbd27e9edefeac184b68391c/agoric/contract/src/kreadKit.js#L275 resolved within mint


[Ubuntu17.04] Compilation error

Hello,
I've the following error on Ubuntu 17.04
hw/xtensa/xtfpga.o: In function lx_init': /home/pef/qemu-xtensa-esp32/hw/xtensa/xtfpga.c:323: undefined reference to load_device_tree'
collect2: error: ld returned 1 exit status
Makefile:197: recipe for target 'qemu-system-xtensa' failed
make[1]: *** [qemu-system-xtensa] Error 1
Makefile:204: recipe for target 'subdir-xtensa-softmmu' failed
make: *** [subdir-xtensa-softmmu] Error 2
I've googled it but no answers.
Any ideas ?

Oh. If you use the patch for the 2.9 version i would say,
git submodule update --init dtc
However load_device_tree is not used so I removed the call.
Try

git pull
and recompile.


Physics

The pushback of Twins is way too big and the pusuback of thunder is way too small.

If you want to help, make a pull request with changes


Move model to a trait

Fix #2120
By moving all the logic to a trait, it make it possible to reuse entities provided by community projects. Example: https://github.com/z-song/laravel-admin/blob/master/src/Auth/Database/Administrator.php
The properties $primaryKey and $keyType can't be in the trait because PHP forbid declaring a property in a trait that is different (type and value) than the property declared in the parent class.
I have mixed feelings about this change, as it breaks the link with the overloaded parent methods. It would probably be better to make the change in each community-package when necessary.

Currently, the Model class is a marker for MongoDB models. If a trait is used, an other marker will be necessary.
https://github.com/mongodb-php/laravel-mongodb/blob/f06f7b3dca88cfd5cc6a823ff01051b4a46ca10a/src/Eloquent/HybridRelations.php#L145

@GromNaN Hopefully in documentation can add a guide for third party packages like spatie's laravel-permissions, bouncer, tenancy etc, sanctum, etc. Or create a community for laravel packages being modified to work with laravel mongodb. This way all popular packages will have counterpart that is made to work with mongodb thanks.

@masterbater The documentation is going to be written by MongoDB's doc team.


Switch withProperties to be withProps

For model builder components switch withProperties to be withProps.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

40 of 118 (33.9%)  changed or added relevant lines in 35 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 42.555%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

extensions/notebook/src/dialog/configurePython/configurePathPage.ts
0
1
0.0%

extensions/resource-deployment/src/ui/deployAzureSQLVMWizard/pages/networkSettingsPage.ts
0
1
0.0%

extensions/resource-deployment/src/ui/deployClusterWizard/pages/summaryPage.ts
0
1
0.0%

extensions/resource-deployment/src/ui/resourceTypePickerDialog.ts
0
1
0.0%

extensions/arc/src/ui/components/keyValueContainer.ts
3
5
60.0%

extensions/arc/src/ui/dashboards/miaa/miaaConnectionStringsPage.ts
0
2
0.0%

extensions/arc/src/ui/dashboards/postgres/postgresComputeAndStoragePage.ts
0
2
0.0%

extensions/arc/src/ui/dashboards/postgres/postgresPropertiesPage.ts
0
2
0.0%

extensions/arc/src/ui/dialogs/addPGExtensionsDialog.ts
0
2
0.0%

extensions/data-workspace/src/dialogs/projectDashboard.ts
0
2
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
26729

Relevant Lines:
56928

💛  - Coveralls


Improve artifact names

          Maybe we could improve the filename of release files. Adding OS name like `darwin` or `macos` / `linux`

Originally posted by @sxzz in https://github.com/elk-zone/elk-native/issues/2#issuecomment-1381763757

Please check the Releases tab now @sxzz I added a workflow step so all artefact names follow the same schema.


Set up file storage on S3

Background
Current POC stores all uploads on the disk. We'll need to wire up S3 properly for the staging and production sites.

@jamesiarmes I saw your email about REST - curious if this story should be rewritten / updated?

I assume we'll still need somewhere to upload files to. For example, when a user uploads a CSV to begin the classification process, we need to parse it for the fields and the possible call type values.
We could either use ActiveStorage to write those files to S3, or write them locally and mount an EFS volume to ensure files are available across containers.


Draft user documentation for creating/integrating/testing custom controllers

We can be guided by Nate's work on blue-gren algae and helping him integrate with the new framework.

resolved in #159


WBD clip for Great Lakes HUCs

The clipping of the WBD layer for HUCs on the Great Lakes may not be necessary anymore as we've changed the input streams to use the NWM network.

Here's @RobHanna-NOAA notes on the issue...

in clip_vectors_to_wbd.py  ( for great lakes)

clip wbd to the dem domain (good)
create wbd_buffer as wbd +  7,000 meters
If great lakes exist

clip great_lakes to wbd_buffer  (huc8 + 7,000)  (so great_lakes is  7,000 from shoreline (ish))
Add a buffer of lake_buffer_distance (20 meters).  great_lakes is now 6,980 from shoreline.
adjust wbd_buffer   (overlay) against great_lakes from 7,000 to 6,980 ??

Is this what we want?  Why do we bother? or do we care? We just cut back the wbd_buffer a little.

in clip_vectors_to_wbd:  Now let's look at it from streams

clip wbd to the dem domain (good)
create wbd_buffer as wbd +  7,000 meters
create wbd_stream_buffers from copy of wbd_buffer (so huc + 7,000 m)
adjust wbd_stream_buffers to a negative buffer of (30 (3 x cellsize)) ( wbd_stream_buffer is now 6,790 m past huc8).
if great lakes exist

clip great_lakes to wbd_buffer  (huc8 + 7,000)  (so great_lakes is  7,000 from shoreline (ish))  (same as above)
great_lakes_streams clipped against wbd_stream_buffers (great_lakes_stream is 6,970 into the water)
great_lakes_streams adds a buffer for lake_buffer_distance (20 meters), so we are now back up to 6,990 in the water.
adjust wbd_stream_buffers (overlay) but against great_lakes (which is at 6,980 from shoreline), so wbd_stream_buffer is now also 6,980.  We lost the extra 20 meters.

Same questions as above. Do we care?

None of this matters if the nwm streams don't go that far into the water of the great lakes, or where the huc8 cuts are in relation to the great lakes.  But.. in landsea we do see some streams that go out in the water (around maine maybe others).
Again.. do we care?

@mluck Please post screenshots of the polygons that you exported here when you get a chance... thanks!

I think Matt just adjusted his other PR for this fix. (or at least that we did not need to create the great_lakes_stream object as we don't use it.  I am not 100% on the rest.  I think we need to experiment with it as it might be assuming the relationship of where huc boundaries lie in relation to great lakes poly's.  I think some huc boundaries already go into the great lakes but some may be more/less shoreline

If Matt already has a fix in, then we can close this issue and link to the PR where that's done. Regardless, I think it's good to have this ticket to document why we're removing that section of code.

This was introduced in PR #375 to resolve errors related to NHDPlus HR input data. Now testing to see if we can do without that section of code now that we use NWM instead of those data using HUCs 04060101 and 04040002 in the original issue (#374).


Add dashboard for container-level metrics

I was looking for a dashboard to see some container-level metrics and found your comment and this repo. I used your dashboard as starting place for this.

Thanks and sorry for the delay. I am trying to wrap my head around this. I like directionally where you are going with this (i.e. an additional dashboard to check single container behaviour in parallel of the original Fargate right sizing dashboard - two different use case). I have yet to play with it but my first question would be what happens when you have multiple containers that have the same name (e.g. which always happen when you have >1 tasks per service). Will play around more. Thanks!

Also, this may need a bit of cleanup in the SOURCE of some of the widgets because you left in your own cluster names I think.

Made a few changes and augmented the README(s). Thanks for kicking this off!


docs: Add API documentation

Set the Sphinx version to 3.5.4 to sidestep
an impending stylesheet issue with the
the CSS that docs.nvidia.com prefers.

The pytorch failure is a mystery and not in a fun, delightful way.
The API doc seems to work again: https://nvidia-merlin.github.io/models/review/pr-212/api.html

Pretty sure that's just a flaky test


[BUG] Forecast with predictive intervals fails in case of data gaps

🐛 Bug Report
I run code from How to reproduce section with PREDICTION_INTERVAL = False and everything works good. If I run it with PREDICTION_INTERVAL = True it fails with unclear error ValueError: y_true and y_pred have different timestamps.
This error is caused by metrics computation in backtest (from prediction intervals generation). Actually, we do not need to compute metrics to build prediction intervals 🤔
Expected behavior
As long as we don't need to compute metrics to build prediction intervals code shouldn't fail in case of metrics' errors.
How To Reproduce
Code
import pandas as pd
from etna.models import NaiveModel
from etna.pipeline import Pipeline
from etna.transforms import TimeSeriesImputerTransform
from etna.datasets import TSDataset

PREDICTION_INTERVAL = True

N = 50
HORIZON = 7

df = pd.DataFrame(
    {
        "timestamp": pd.date_range("2020-01-01", periods=N),
        "segment": "segment_0",
        "target": list(range(N))
    }
)

df.loc[40, "target"] = None
df.loc[10, "target"] = None
df.loc[25, "target"] = None

wide_df = TSDataset.to_dataset(df)
ts = TSDataset(wide_df, "D")
train, test = ts.train_test_split(test_size=HORIZON)

pipeline = Pipeline(model=NaiveModel(), transforms=[TimeSeriesImputerTransform()], horizon=HORIZON)
pipeline.fit(train)
forecast = pipeline.forecast(prediction_interval=PREDICTION_INTERVAL, n_folds=3)

code above returns an error ValueError: y_true and y_pred have different timestamps.
Environment
No response
Additional context
No response
Checklist

[X] Bug appears at the latest library version

Possible hotfix: create dummy metric that does not check timestamps for y_true and y_pred and change MAE metric with it here.
It can cause some problems here, so we need to add a test to check the intervals still work in case of data gaps.


Update timer.gd

Fixed the timer.
Note: this aproach works when:
Script is attached to a Controll with children:
Name: "minutes", Label
Name: "seconds", Label
Name: "miliseconds", Label

This is the hierarchy mentioned in the patch note:

Hi @wwidlishy. I appreciate your interest in contributing to the Flick repo. However, I'm still not exactly sure what this update is for.
The timer should have been working already, but I had the time incremented in the Level class so that it was easier for other scripts to access the completed time (ie. the exit that brings up the level status screen). It is also a bit cleaner than having to pass the Timer scene reference to the level status screen (in this case I would have had to make a reference on the root level scene and then add code to have the timer referenced manually there).
I'm happy to talk further about this change. I'm sure there's something I'm not seeing. Maybe there's a cleaner way we can move the time itself out of the Level singleton and then reference the Timer node in the right places?
Thanks again for the contribution!


Wordsmith and simplify Github issue and PR templates

This commit removes or refactors boilerplate from our issue and PR templates.
It's primarily wordsmithing, but has two notable changes:

It introduces a make reviewable command so we can shorten our PR checklist.
It uses issue labels to indicate whether something is a bug or enhancement.

Our current templates contained a bunch of markdown inside comment tags, which did not actually render and looked a little unprofessional. I also found that I was ignoring most our checklist most of the time, so I've attempted to make it a little more approachable.


gpl routability log change

Minor modification from "numCall" variable name to "iteration", which is exactly what the internal variable represents.
Noticed that the inflation and bloat counters are unused in practice. The counters exceed their maximum values without triggering any functionality.
Bloat is expected to occur when inflation reaches its maximum iterations, but no action is associated with this condition. This appears to be a remnant of an earlier idea that was not fully implemented or was removed, leaving behind unused code.

This PR should cover the request in issue https://github.com/The-OpenROAD-Project/OpenROAD/issues/5201


[fix] transmission: Handle rpc client exception

Motivation for changes:
Avoid flexget crash when rpc client raises exception
Detailed changes:

The rpc client converting a json request and handling the decode erro, he does this raising a ValueError exception, added a handler to that.

Addressed issues:

Fixes #2811

Implemented feature requests:
Config usage if relevant (new plugin or updated schema):
tasks:
  transmission_test:
    from_transmission:
      host: localhost
      port: 9091
      username: myusername
      password: mypassword

Log and/or tests output (preferably both):
2021-04-28 11:01:36 ERROR    transmission-rpc transmission_test Error: Expecting value: line 1 column 1 (char 0)
2021-04-28 11:01:36 ERROR    transmission-rpc transmission_test Request: "{"tag": 0, "method": "session-get", "arguments": {}}"
2021-04-28 11:01:36 ERROR    transmission-rpc transmission_test HTTP data: "
403: Forbidden

Unauthorized IP Address.

Either disable the IP address whitelist or add your address to it.

If you're editing settings.json, see the 'rpc-whitelist' and 'rpc-whitelist-enabled' entries.

If you're still using ACLs, use a whitelist instead. See the transmission-daemon manpage for details.
"
2021-04-28 11:01:36 CRITICAL plugin        transmission_test Error connecting to transmission
2021-04-28 11:01:36 WARNING  task          transmission_test Aborting task (plugin: from_transmission)

To Do:

LGTM, thanks!


[ca] Add support for verifying and loading certificate chains which include intermediates

Part of addressing #1990 (supporting intermediates).
This adds support in validating and loading intermediates that are included with TLS leaf certificates, although ValidateCertChain could also be used to validate a chain of intermediates.
(most of this PR is tests and some additional static certs)

Codecov Report

Merging #2000 into master will increase coverage by 0.04%.
The diff coverage is 98.24%.

@@            Coverage Diff             @@
##           master    #2000      +/-   ##
==========================================
+ Coverage    53.8%   53.85%   +0.04%
==========================================
  Files         109      109
  Lines       18943    18969      +26
==========================================
+ Hits        10192    10215      +23
- Misses       7517     7524       +7
+ Partials     1234     1230       -4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bff526f...e54f3cf. Read the comment docs.

LGTM

Updated comments to reflect why we are doing some additional verification, and changed that chain function to an iterative one.


Can't view table data in VS after updating .bim in TE2

I made a number of adjustments to my model in Tabular Editor, mostly based on best practice analysis.  After saving the changes and then opening the solution in Visual Studio (2019), the table data does not show on three of my tables after processing them.
The changes I recall included removing availability in MDX, formatting numerical fields from general to whole numbers, adding table names to fully-qualify column names, adding descriptions to hierarchies...  there were some others, but I left them out if I know they affected tables I can still see the data in.

Update - I updated the table keys for the affected tables to be available in MDX again, and the problem was resolved.  Maybe table keys, though hidden, shouldn't be recommended in the DISABLE_ATTRIBUTE_HIERARCHIES recommendation?

I don't know why Visual Studio requires that IsAvailableInMdx = true on hidden key columns. It should not be a problem for the end-users of your model (i.e. those who would typically be querying the model using Excel, Power BI or other client tools). So instead of changing the rule, I would recommend reporting this as a bug to the Analysis Services Projects extension for Visual Studio team.


fix: Enable the Validating Admission Webhook

Description
Tested, validated, and rewrote the instructions.
It does not work for Helm Installation.
Here's the terminal output for the YAML working and HELM not working.
[webhookhelmnotworking.txt](https://github.com/Kong/docs.konghq.com/files/130397
webhookyamlworking.txt
18/webhookhelmnotworking.txt)
Testing instructions
Preview link:
Checklist

[x] Review label added
[x] PR pointed to correct branch (main for immediate publishing, or a release branch: e.g. release/gateway-3.2, release/deck-1.17)

Closing this PR in lieu of https://github.com/Kong/docs.konghq.com/pull/6342