反向代理不断出现访问accepted udp:reverse.internal.v2ray.com:0造成卡死，不能访问bridge

你正在使用哪个版本的 V2Ray？

服务器，debain，V2RAY 4.34.0
bridge：raspbian，V2RAY 4.34.0
你的使用场景是什么？

在家里放置树莓派做反向代理，供外网访问家里的nas等
你看到的异常现象是什么？

bridge给portal发一个请求，访问用于标识反问代理的那个URL：
portalLog  ：v2ray.com/core/common/mux: received request for tcp:test.aabbyy.com:0
然后portal会指挥bridge访问：reverse.internal.v2ray.com:0
bridge确实去访问，然后就不再处理其它请求，通常过将近20秒时间，感觉是超时了才放弃，然后才能提供正常服务
但是这个过程反反复复，有时候持续5分钟一直在做这件事，外网访问不能连入
你期待看到的正常表现是怎样的？
没有这个动作，或者这个动作很快结束，或者虽然不结束，但是不影响其它连入，因为发生这个情况时bridge是卡死状态，不干活
请附上你的配置

服务端配置：
我精简过的配置，只保留有关数据
// 在这里附上服务器端配置文件
"reverse": {
    "portals": [
      {
        "tag": "portalHome",
        "domain": "test.aabbyy.com"
      }
    ]
  }
"inbound":
[{
      "tag": "tag1",
      "port": 10808,
      "listen": "<IP_ADDRESS>",
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
    {
      "port": 4095,
      "listen":"<IP_ADDRESS>",
      "tag": "interconnFromHome",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "134b33ca-b0cc-44b7-a28f-4214842c2fd6",
            "alterId": 64
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
        "path": "/response"
        }
      }
    }]
"routing": {
        "type": "field",
        "inboundTag": [
          "tag1",
        ],
        "ip":[
            "<IP_ADDRESS>/24"
            ],
        "outboundTag": "portalHome"
      },
      {
        "type": "field",
        "inboundTag": [
          "interconnFromHome"
        ],
        "outboundTag": "portalHome"
      },

客户端配置：
// 在这里附上客户端配置
"reverse": {
    "bridges": [
      {
        "tag": "bridge",
        "domain": "test.aabbyy.com"
      }
    ]
  },
"outbounds": [{
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "ddmnt.com",//此为portal地址
            "port": 443,
            "users": [
              {
                "id": "134b33ca-b0cc-44b7-a28f-4214842c2fd6",
                "alterId": 64
              }
            ]
          }
        ]
      },
	  "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "allowInsecure": true,
          "serverName": null
        },
        "tcpSettings": null,
        "kcpSettings": null,
        "wsSettings": {
          "connectionReuse": true,
          "path": "/response",
          "headers": null
        },
        "httpSettings": null,
        "quicSettings": null
      },
      "mux": {
        "enabled": true,//此处true,false都尝试过，均存在问题
        "concurrency": 8
      },
      "tag": "interconn"
    }，
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "http"
        }
      }
    },
       {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {

	  }
    },
  ]

"routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [{
        "type": "field",
        "inboundTag": [
          "bridge"
        ],
        "domain": [
          "full:test.aabbyy.com"

        ],
        "outboundTag": "interconn"
      },
     {
        "remarks": "block",
        "type": "field",
        "outboundTag": "block",
        "domain": [
          "geosite:category-ads-all",
          "reverse.internal.v2ray.com" //此处把这个地址屏蔽了，也试过给配置到freedom，花的时间更长
        ]
      },
    {
        "remarks": "192",
        "type": "field",
        "outboundTag": "direct",
        "ip": [
          "<IP_ADDRESS>/24"
        ]
      },

请附上出错时软件输出的错误日志

服务器端错误日志：
// 在这里附上服务器端日志
portal

2021/12/22 11:05:59 [Info] [40209657] v2ray.com/core/common/mux: received request for tcp:test.aabbyy.com:0
2021/12/22 11:05:59 [Info] [40209657] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:test.aabbyy.com:0]
2021/12/22 11:05:59 [Info] v2ray.com/core/common/mux: dispatching request to udp:reverse.internal.v2ray.com:0
2021/12/22 11:06:00 [Info] v2ray.com/core/common/mux: failed to fetch all input > io: read/write on closed pipe
2021/12/22 11:06:00 [Info] [3266714446] v2ray.com/core/common/mux: received request for tcp:zws5.web.telegram.org:443
2021/12/22 11:06:00 [Info] [3266714446] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:zws5.web.telegram.org:443]
2021/12/22 11:06:00 [Info] [3266714446] v2ray.com/core/common/mux: dispatching request to tcp:zws5.web.telegram.org:443
2021/12/22 11:06:01 [Info] [3275037948] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:01 [Info] [3275037948] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:01 [Warning] [3275037948] v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/common/mux: unable to find an available mux client
2021/12/22 11:06:01 [Warning] [3275037948] v2ray.com/core/proxy/http: failed to read response from <IP_ADDRESS> > io: read/write on closed pipe
2021/12/22 11:06:01 [Info] [2173692306] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:01 [Info] [2173692306] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:01 [Info] [2173692306] v2ray.com/core/common/mux: dispatching request to tcp:<IP_ADDRESS>:80
2021/12/22 11:06:04 [Info] [2509237320] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:04 [Info] [2509237320] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:04 [Warning] [2509237320] v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/common/mux: unable to find an available mux client
2021/12/22 11:06:04 [Warning] [2509237320] v2ray.com/core/proxy/http: failed to read response from <IP_ADDRESS> > io: read/write on closed pipe
2021/12/22 11:06:04 [Info] [2140000218] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:04 [Info] [2140000218] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:04 [Info] [2140000218] v2ray.com/core/common/mux: dispatching request to tcp:<IP_ADDRESS>:80
2021/12/22 11:06:05 [Info] [3266714446] v2ray.com/core/common/mux: received request for tcp:zws5.web.telegram.org:443
2021/12/22 11:06:05 [Info] [3266714446] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:zws5.web.telegram.org:443]
2021/12/22 11:06:05 [Info] [3266714446] v2ray.com/core/common/mux: dispatching request to tcp:zws5.web.telegram.org:443
2021/12/22 11:06:07 [Info] [864153682] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:07 [Info] [864153682] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:07 [Warning] [864153682] v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/common/mux: unable to find an available mux client
2021/12/22 11:06:07 [Warning] [864153682] v2ray.com/core/proxy/http: failed to read response from <IP_ADDRESS> > io: read/write on closed pipe
2021/12/22 11:06:07 [Info] [3714898830] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:07 [Info] [3714898830] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:07 [Info] [3714898830] v2ray.com/core/common/mux: dispatching request to tcp:<IP_ADDRESS>:80
2021/12/22 11:06:07 [Info] [3266714446] v2ray.com/core/common/mux: received request for tcp:wx.qq.com:443
2021/12/22 11:06:07 [Info] [3266714446] v2ray.com/core/app/dispatcher: taking detour [freedom] for [tcp:wx.qq.com:443]
2021/12/22 11:06:07 [Info] [3266714446] v2ray.com/core/proxy/freedom: opening connection to tcp:wx.qq.com:443
2021/12/22 11:06:07 [Info] [3266714446] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:wx.qq.com:443
2021/12/22 11:06:10 [Info] [3266714446] v2ray.com/core/common/mux: received request for tcp:zws5.web.telegram.org:443
2021/12/22 11:06:10 [Info] [3266714446] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:zws5.web.telegram.org:443]
2021/12/22 11:06:10 [Info] [3266714446] v2ray.com/core/common/mux: dispatching request to tcp:zws5.web.telegram.org:443
2021/12/22 11:06:10 [Info] [382109166] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:10 [Info] [382109166] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:10 [Warning] [382109166] v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/common/mux: unable to find an available mux client
2021/12/22 11:06:10 [Warning] [382109166] v2ray.com/core/proxy/http: failed to read response from <IP_ADDRESS> > io: read/write on closed pipe
2021/12/22 11:06:10 [Info] [1705703497] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:10 [Info] [1705703497] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:10 [Info] [1705703497] v2ray.com/core/common/mux: dispatching request to tcp:<IP_ADDRESS>:80
2021/12/22 11:06:13 [Info] [3117897057] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:13 [Info] [3117897057] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:13 [Warning] [3117897057] v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/common/mux: unable to find an available mux client
2021/12/22 11:06:13 [Warning] [3117897057] v2ray.com/core/proxy/http: failed to read response from <IP_ADDRESS> > io: read/write on closed pipe
2021/12/22 11:06:13 [Info] [1378586443] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:13 [Info] [1378586443] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:13 [Info] [1378586443] v2ray.com/core/common/mux: dispatching request to tcp:<IP_ADDRESS>:80
2021/12/22 11:06:14 [Info] [3266714446] v2ray.com/core/common/mux: received request for tcp:zws5.web.telegram.org:443
2021/12/22 11:06:14 [Info] [3266714446] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:zws5.web.telegram.org:443]
2021/12/22 11:06:14 [Info] [3266714446] v2ray.com/core/common/mux: dispatching request to tcp:zws5.web.telegram.org:443
2021/12/22 11:06:15 [Info] v2ray.com/core/common/mux: failed to read metadata > io: read/write on closed pipe
2021/12/22 11:06:15 [Info] [3266714446] v2ray.com/core/common/mux: received request for tcp:learning.chem.com:6443
2021/12/22 11:06:15 [Info] [3266714446] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:learning.chem.com:6443]
2021/12/22 11:06:15 [Info] [3266714446] v2ray.com/core/common/mux: dispatching request to tcp:learning.chem.com:6443
2021/12/22 11:06:16 [Info] [1248861372] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:16 [Info] [1248861372] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:16 [Warning] [1248861372] v2ray.com/core/app/reverse: failed to process reverse connection > v2ray.com/core/common/mux: unable to find an available mux client
2021/12/22 11:06:16 [Warning] [1248861372] v2ray.com/core/proxy/http: failed to read response from <IP_ADDRESS> > io: read/write on closed pipe
2021/12/22 11:06:16 [Info] [4102476173] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]
2021/12/22 11:06:16 [Info] [4102476173] v2ray.com/core/app/dispatcher: taking detour [portal] for [tcp:<IP_ADDRESS>:80]
2021/12/22 11:06:16 [Info] [4102476173] v2ray.com/core/common/mux: dispatching request to tcp:<IP_ADDRESS>:80
2021/12/22 11:06:17 [Info] [40209657] v2ray.com/core/common/mux: received request for tcp:test.aabbyy.com:0
2021/12/22 11:06:17 [Info] [40209657] v2ray.com/core/app/dispatcher: taking detour [portalHome] for [tcp:test.aabbyy.com:0]
2021/12/22 11:06:17 [Info] v2ray.com/core/common/mux: dispatching request to udp:reverse.internal.v2ray.com:0
2021/12/22 11:06:18 [Info] v2ray.com/core/common/mux: failed to fetch all input > io: read/write on closed pipe
2021/12/22 11:06:19 [Info] [156260329] v2ray.com/core/proxy/http: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/]

客户端错误日志：
// 在这里附上客户端日志
2021/12/22 11:05:59 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.aabbyy.com:0]
2021/12/22 11:05:59 [Info] common/mux: dispatching request to tcp:test.aabbyy.com:0
2021/12/22 11:05:59  accepted udp:reverse.internal.v2ray.com:0 [block]
2021/12/22 11:05:59 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0
2021/12/22 11:05:59 [Info] app/dispatcher: taking detour [block] for [udp:reverse.internal.v2ray.com:0]
2021/12/22 11:06:00 [Info] common/mux: session 1 ends. > io: read/write on closed pipe
2021/12/22 11:06:17 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.aabbyy.com:0]
2021/12/22 11:06:17 [Info] common/mux: dispatching request to tcp:test.aabbyy.com:0
2021/12/22 11:06:17 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0
2021/12/22 11:06:17 [Info] app/dispatcher: taking detour [block] for [udp:reverse.internal.v2ray.com:0]
2021/12/22 11:06:17  accepted udp:reverse.internal.v2ray.com:0 [block]
2021/12/22 11:06:18 [Info] common/mux: session 1 ends. > io: read/write on closed pipe
2021/12/22 11:06:25 [Info] common/mux: received request for tcp:<IP_ADDRESS>:80
2021/12/22 11:06:25 [Info] app/dispatcher: taking detour [direct] for [tcp:<IP_ADDRESS>:80]

请附上访问日志

// 在这里附上服务器端日志
2021/12/22 11:05:58 <IP_ADDRESS>:50846 accepted http://<IP_ADDRESS>/ [portalHome]
2021/12/22 11:05:59 <IP_ADDRESS>:50848 accepted http://<IP_ADDRESS>/ [portal]
2021/12/22 11:05:59 tcp:<IP_ADDRESS>:51716 accepted tcp:test.aabbyy.com:0 [portalHome]
2021/12/22 11:06:00 tcp:<IP_ADDRESS>:48016 accepted tcp:zws5.web.telegram.org:443 [portal]
2021/12/22 11:06:01 <IP_ADDRESS>:50854 accepted http://<IP_ADDRESS>/ [portalHome]
2021/12/22 11:06:01 <IP_ADDRESS>:50856 accepted http://<IP_ADDRESS>/ [portal]

其它相关的配置文件（如 Nginx）和相关日志
Nginx未配置日志
如果 V2Ray 无法启动，请附上 --test 命令的输出
可启动
如果 V2Ray 服务运行异常，请附上 journal 日志
无其它异常

Don't block reverse.internal.v2ray.com.

I did what you told and tested for two weeks
here is the key  configs
{       "protocol": "vmess",       "settings": {         "vnext": [           {             "address": "lemnt.com",             "port": 443,             "users": [               {                 "id": "134xxxx-b0cc-44a7-a28f-4214842c2fd6",                 "alterId": 64               }             ]           }         ]       }, 	  "streamSettings": {         "network": "ws",         "security": "tls",         "tlsSettings": {           "allowInsecure": true,           "serverName": null         },         "tcpSettings": null,         "kcpSettings": null,         "wsSettings": {           "connectionReuse": true,           "path": "/wx",           "headers": null         },         "httpSettings": null,         "quicSettings": null       },       "mux": {         "enabled": false,         "concurrency": 8       },       "tag": "interconn"     }
     {         "type": "field",         "inboundTag": [           "bridge"         ], 		"domain": [           "reverse.internal.v2ray.com"         ],         "outboundTag": "proxy_active"       },
the problem is still there
the following log is from bridge:
2022/02/17 11:40:31 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:40:31 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:40:31 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:40:31 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:31 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:40:31  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:40:31 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:31 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:40:32 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:40:36 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:40:47 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:40:48 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:40:48 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:40:49 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:40:49 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:40:49 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:40:49 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:49 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:40:49  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:40:49 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:49 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:40:50 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:05 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:41:06 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:41:06 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:41:07 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:41:07 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:41:07 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:41:07 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:07 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:41:07 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:07  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:41:07 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:08 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:23 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:41:24 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:41:24 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:41:25 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:41:25 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:41:25 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:41:25  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:41:25 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:25 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:41:25 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:25 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:26 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:41 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:41:42 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:41:42 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:41:43 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:41:43 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:41:43 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:41:44 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:44 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:41:44 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:44  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:41:44 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:44 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:00 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:42:01 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:42:02 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:42:03 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:42:03 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:42:03 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:42:04  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:42:04 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:04 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:42:04 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:04 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:04 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:20 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:42:20 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:42:21 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:42:21 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:42:21 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:42:23 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:42:23 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:23 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:42:23 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:23  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:42:23 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:23 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452
it still try to vistit reverse.internal.v2ray.com:0  until time out ,and during the time, it wouldn't accept new request

the previous comment has some problem to show the log
2022/02/17 11:40:31 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:40:31 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:40:31 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:40:31 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:31 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:40:31  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:40:31 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:31 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:40:32 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:40:36 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:40:47 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:40:48 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:40:48 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:40:49 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:40:49 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:40:49 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:40:49 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:49 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:40:49  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:40:49 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:40:49 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:40:50 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:05 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:41:06 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:41:06 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:41:07 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:41:07 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:41:07 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:41:07 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:07 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:41:07 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:07  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:41:07 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:08 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:23 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:41:24 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:41:24 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:41:25 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:41:25 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:41:25 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:41:25  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:41:25 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:25 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:41:25 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:25 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:26 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:41 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:41:42 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:41:42 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:41:43 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:41:43 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:41:43 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:41:44 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:44 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:41:44 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:41:44  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:41:44 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:41:44 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:00 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:42:01 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:42:02 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:42:03 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:42:03 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:42:03 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:42:04  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:42:04 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:04 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:42:04 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:04 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:04 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:20 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:42:20 [Info] failed to handler mux client connection > proxy/vmess/outbound: connection ends > websocket: close 1005 (no status) 2022/02/17 11:42:21 [Info] app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: connection ends > context canceled 2022/02/17 11:42:21 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:42:21 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:42:23 [Info] proxy/vmess/outbound: tunneling request to tcp:test.ailitonia.com:0 via tcp:lemnt.com:443 2022/02/17 11:42:23 [Info] common/mux: received request for udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:23 [Info] app/dispatcher: taking detour [proxy_active] for [udp:reverse.internal.v2ray.com:0] 2022/02/17 11:42:23 [Info] common/mux: dispatching request to udp:reverse.internal.v2ray.com:0 2022/02/17 11:42:23  accepted udp:reverse.internal.v2ray.com:0 [proxy_active] 2022/02/17 11:42:23 [Info] transport/internet/websocket: creating connection to tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:23 [Info] proxy/vmess/outbound: tunneling request to tcp:v1.mux.cool:9527 via tcp:hk03-vm5.entry.ikuuu.casa:452 2022/02/17 11:42:39 [Info] common/mux: failed to read metadata > io: read/write on closed pipe 2022/02/17 11:42:39 [Info] app/dispatcher: taking detour [interconn] for [tcp:test.ailitonia.com:0] 2022/02/17 11:42:39 [Info] transport/internet/websocket: creating connection to tcp:lemnt.com:443 2022/02/17 11:42:39 [Info] failed to handler mux client connection > proxy/vmess/o

You seem to be using different versions of V2ray on the portal and the bridge. Try to use the lastest version.

You seem to be using different versions of V2ray on the portal and the bridge. Try to use the lastest version.

that's true, and it solved the problem
on bridge is v4.43, not 4.34, i was wrong about it
it seems that the later version use "reverse.internal.v2fly.org:0" instead of "reverse.internal.v2ray.org:0"
maybe that the reason
thank you so much


Create database structure

Need to create database interface and sqlite implementation

Sqlite database structure created!
Need to add:

[ ] Dinamic creation of tables
[ ] pid to users model instead of emails
[ ] Know how to encrypt the pid of user


xlights: 2023.11 -> 2023.13

Description of changes
diff: https://github.com/smeighan/xLights/compare/2023.11...2023.13
xlights 2023.12 was skipped due to https://github.com/NixOS/nixpkgs/pull/247444#issuecomment-1672386457, seems to be fixed in 2023.13

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 253023 run on x86_64-linux 1

1 package built:

xlights


ChangePassword method on SDK does not return the ticket

Checklist

[X] I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved
I have a usecase where I want to be able to create a password change ticket and send that link in a custom email - specifically to implement a new-user invite flow described here: https://auth0.com/docs/customize/email/send-email-invitations-for-application-signup#create-password-change-tickets
To do this I need to be able to get the ticket url returned by the management API: https://auth0.com/docs/api/management/v2/tickets/post-password-change
However, the SDK method that wraps this endpoint does not actually return the URL, it only returns an error.
Describe the ideal solution
The SDK ChangePassword method returns the password reset ticket url (or a new method is added which does this).
Alternatives and current workarounds
The only alternative/workaround I have right now is to not use the SDK and just call the API directly with Go's http client instead.
Additional context
No response

Hi @TheManSpeaker,
I hope you're having a great day!
I've reviewed the issue, and it seems that you can easily access the password change ticket URL without needing to modify or add anything to the SDK. The ChangePassword method automatically updates the Ticket object with the ticket URL after it successfully creates the ticket.
Here's how it works: when you call the api.Ticket.ChangePassword method and pass in your Ticket object with the necessary parameters (like ResultURL, UserID, etc.), the Auth0 SDK handles the API call and updates the Ticket object internally with the URL where users can change their password.
To retrieve this URL, you simply need to access it from the Ticket object after calling the method. Here's a working example in Go:
// Initialize Auth0 Management API client
api, err := management.New(
    os.Getenv("AUTH0_DOMAIN"),
    management.WithClientCredentials(context.Background(), os.Getenv("AUTH0_CLIENT_ID"), os.Getenv("AUTH0_CLIENT_SECRET")),
    management.WithDebug(true),
)
if err != nil {
    log.Fatalf("failed to create Auth0 management client: %+v", err)
}

// Create a new user (example user creation code not shown for brevity)
// ...

// Prepare the password change ticket request
ticket := &management.Ticket{
    ResultURL:              auth0.String("https://example.com/change-password"),
    UserID:                 user.ID,
    TTLSec:                 auth0.Int(3600),  // Ticket TTL in seconds
    MarkEmailAsVerified:    auth0.Bool(false),
    IncludeEmailInRedirect: auth0.Bool(true),
}

// Call the ChangePassword method to generate the ticket
err = api.Ticket.ChangePassword(context.Background(), ticket)
if err != nil {
    log.Fatalf("failed to create password change ticket: %+v", err)
}

// The 'ticket' object now contains the ticket URL
ticketURL := ticket.GetTicket()
log.Printf("Password change ticket URL: %s", ticketURL)

In this example, after calling api.Ticket.ChangePassword, you can directly access ticket.GetTicket() to obtain the URL where users should be redirected to change their password.
This approach ensures that you can seamlessly integrate the password change flow in your application without needing to handle additional data structures or make extra SDK modifications.
Let me know if you have any further questions or if there's anything else you need assistance with!

Ah this will work for me then. Might be worth calling out in the docs somewhere that it mutates the ticket since that wasn't obvious to me - but otherwise this solves the problem. Thanks!


[KT Cloud VPC] Prevent an Error in case of Get/List of VM info. when there is No Portforwarding Rule

Update VMHandler

Prevent 'Failed to Get VPC ID' error in case of Get/List of VM info. when there is No Portforwarding Rule

Update VPCHandler

Adjust time.Sleep for Adding Subnet

@innodreamer

https://github.com/cloud-barista/cb-spider/issues/1178과도 영향이 있는지 확인 부탁드립니다.


Handle slow network speeds

Description:

We should have add message on the connection bar that the network is slow.
Ideas:

https://stackoverflow.com/questions/38137422/show-alert-message-if-the-internet-connection-speed-is-slow-in-android
https://ux.stackexchange.com/questions/110156/what-would-be-a-user-friendly-message-when-the-user-has-a-slow-internet-connecti

love this idea!

@sabau aside from reducing the bundle (is this idea / project being tracked somewhere?) are there are other easy ways to improve this for us?
try switching to 3G in chrome - the website won't even load 😨


ModuleNotFoundError: No module named 'cerf_api'

Installed vint with pip install --upgrade vint which ended with the message:
Successfully installed certifi-2<IP_ADDRESS> chardet-3.0.4 docopt-0.6.2 idna-2.6 python-dateutil-2.6.1 requests-2.18.4 six-1.11.0 urllib3-1.22 vint-0.1.5

Running vint from the console results in the following error traceback:
Traceback (most recent call last):
  File "/home/user/.local/bin/vint", line 13, in <module>
    from vint import vint
  File "/home/user/.local/lib/python3.6/site-packages/vint/vint.py", line 5, in <module>
    from cerf_api import Cerf
ModuleNotFoundError: No module named 'cerf_api'

The correct package name of Vint is vim-vint.
Please upgrade vint the following command:
$ pip install --upgrade vim-vint

Ouch. Stupid mistake on my part. Hopefully this issue will help anyone else who makes it. Thanks for your quick response.


Solution Planning - Brainstorming/Grooming

Completed.  Multiple changes are expected as we move through development and testing.

The link to the Current & Future State Diagram in Lucid Chart is https://lucid.app/lucidchart/30ef181b-28f6-4388-951a-d2df110112d0/edit?page=0_0#


Perspective View MapsUi

Hi,
is it possible to transform the View to achieve a perspectival View ?
Can i access the Canvas somehow, i did not find anything except the ITransformation.
Thanks in Advance.
XamHans

No. You can rotate the view. So for navigation you could rotate into the direction you are driving. I assume what you want is to also tilt it backwards. That is not possible right now.
To add this feature there will need to be transformation of the canvas. This may not be too hard. It will also affect the area in view, which will be trapezoid shaped, and thus other data needs to be fetched and drawn. This will be hard. You also need to take into account a lower level of detail for areas further from you viewpoint.

Have the same problem. How can I access the canvas to transform it?
As I have seen the MapControl.cs instantiates the canvas on each platform. But this field is private. Is there another way to access it?

Take the source code and change MapControl and its Renderers.
But be carefull, Skia has problems with big numbers, because it only uses float for calculations. So, if you use matrix operations, there could be "jumping" features.

Thanks. Can anyone give me a hint how I can transform the canvas after it has already drawn the map?
I.e: I want to rotate the map 90 Degree via SKCanvas. Usually you have to specify the rotation before something is drawn on the canvas but is there a possible solution to the the whole canvas content and then execute the rotation (change matrix) and then paste the content again so that it is rotated after?
Or is there a way to intercept the map drawing and add some operations before it?

Map is rotated by Viewport.Rotation. That isn‘t a perspactival transformation. Paul’s answer above should you direct in the right direction.

This was only an example. He said that the canvas needs to be transformated which is what I want now to achieve. The transformation only affects drawings after the transformation matrix was set.

Try, ifyou could der the matrix before anything else happens. I don‘t have the code by hand, but if I remember correct, Mapsui derives from SKCanvasView.

Perhaps the best way to go here is to create a copy of the MapControl and modify it to your needs.


exploitdb: 2021-07-10 -> 2021-07-14

Motivation for this change
Update to latest upstream release 2021-07-14
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 130221 run on x86_64-linux 1

1 package built:

exploitdb


deploy python function failed

Does this occur consistently?
Repro steps:

Action: azureFunctions.deploy
Error type: ENOTFOUND
Error Message: getaddrinfo ENOTFOUND fazbear-py.scm.azurewebsites.net
Version: 0.22.1
OS: win32
OS Release: 10.0.18362
Product: Visual Studio Code
Product Version: 1.46.0
Language: en

Call Stack
GetAddrInfoReqWrap.onlookup [as oncomplete] dns.js:60:26

@joshdotexe please add detailed repro steps


Slow Performance Observed When Updating State On Keyup

Hi all:
problem statement
On each keystroke trigger an action, reduce the state to compensate for the new character, but observe that re-rendering becomes laggy.  You can watch the lag here.
background

I use react-router, and have a simple component structure (I'd snap a shot of the component DOM, but electron react-dev tools is currently out-of-operation).  It's a few layers deep:

Provider >
App >
Dashboard  >
Home {connected, but passes no state/props through children. why? to dispatch an auth middleware event on load} >
ProjectDashboard >
ProjectController {connected, passes a single object of state, ~small} >
Project {dumb}

a third component is connected, but is not rendered.  its a layout component for login, and I don't believe to be associated with the issue at hand.
I've profiled while punching keys into the field.  It's the name field shown.  It looks like a ton of time is being spent in validate and doing deepEquals in shouldComponentUpdate.

discussion

it's been noted to move components down lower in the structure if perf is an issue, so I've done that.  i only have a few components, and they pass the minimal amount of state via connect
my reducers and state updating is waaay down the list of processing % time.  it seems to correspond to actual react re-rendering time in some components, perhaps performing frivolous checks?

Would love some tips!  Thanks!

What is contained in props on your Project component? It looks like you've got something big in your props that's being validated.
I'd recommend grabbing the react devtools, as it makes viewing this stuff much easier.
Could you post your Project component's code?

I get similar performance issues with forms when I'm using redux-devtools.
Have you tried out reselect? It'll memoize selectors, which should help you avoid re-calculating stuff when data changes.
Aside from that, pulling in react-pure-render might help as well.

hi @timdorr @cesarandreu.  thanks for your willingness to add ideas!

my selected-mapped state isn't tiny, but it's not huge either. see here.  I could perhaps reduce some of that data further.  do you know much about the what and why of the validation step?
i have tried to get react devtools up, but it's currently out-of-order in electron, which is my target client.
in regards to reselect, i'm not modifying as I select my state-bits into the component's stateToProps map.  but perhaps therein is part of the issue?  i'm still reasoning over why you'd cache in this part of the processes vs. before/conditionally dispatching an action.
i will be trying pure render for sure
thanks guys! would definitely care for some more tips if you got them!

It's a known issue with Redux DevTools and if you'd like to see it fixed, a good first step is to contribute tests.
You won't have this issue in production.

There's a PR attempted to fix it: https://github.com/gaearon/redux-devtools/pull/133
Can you please test whether it improves the situation?

This is fixed in<EMAIL_ADDRESS>Performing an action with DevTools open was O(n), now it's O(1).

thanks @gaeron!  will try at my next opportunity

I'm still seeing a bit of a lag when carrying out rapid state changes (in this scenario it's a keydown event for an autocomplete). My suspicion is that it may be due to the number of LogMonitor nodes it has to update in quick succession. I created a very simple custom monitor which just logged the action and the problem seemed to go away. If anyone else is experiencing this I think the resolution may be one of the following..

Create a simple custom monitor with an emphasis on speed
In the default LogMonitor raise a PR to only retrieve action details on request

(I can hopefully help out with a resolution, I wonder if this issue could be transferred to redux-devtools)

Oh, I see now. There hasn't been much effort to optimize LogMonitor so I wouldn't be surprised if there are many low hanging fruit there.

Adding a shouldComponentUpdate that does a shallowEqual for LogMonitorEntry seems to greatly improve responsiveness for me when using redux-forms (goes from unusable to usable). I'm not entirely sure if it's safe to just do a shallowEqual though... so far seems ok.

@davecoates Then please file an issue (or, better, a PR) to add it!

@davecoates The issue I found with redux-form is that onChange', 'onBlur', 'onFocus', 'onUpdate',
'handleChange', 'handleBlur', 'handleFocus' on field prop change on every render. I put a shouldComponentUpdate on my Widget component (that render a input, select or whatever) to ignore changes of those functions. This is what I use:
const IGNORE_FUNCTIONS = [
  'onChange', 'onBlur', 'onFocus', 'onUpdate',
  'handleChange', 'handleBlur', 'handleFocus']

export function shallowEqual(objA, objB) {
  if (objA === objB) {
    return true
  }

  if (typeof objA !== 'object' || objA === null ||
      typeof objB !== 'object' || objB === null) {
    return false
  }

  const keysA = Object.keys(objA)
  const keysB = Object.keys(objB)

  if (keysA.length !== keysB.length) {
    return false
  }

  // Test for A's keys different from B.
  const bHasOwnProperty = Object.prototype.hasOwnProperty.bind(objB)
  for (let i = 0; i < keysA.length; i++) {
    if (!bHasOwnProperty(keysA[i])) {
      return false
    }
    if (keysA[i] === 'field') {
      if (!shallowEqual(objA[keysA[i]], objB[keysA[i]])) {
        return false
      }
    } else if (typeof objA[keysA[i]] === 'function' &&
      IGNORE_FUNCTIONS.indexOf(keysA[i]) > -1 ) {
      // don't compare function is the IGNORE_FUNCTIONS array
      continue
    } else if (objA[keysA[i]] !== objB[keysA[i]]) {
      // console.log('rerender because of prop named:')
      // console.log(keysA[i])
      // console.log('before:')
      // console.log(objA[keysA[i]])
      // console.log('after:')
      // console.log(objB[keysA[i]])
      return false
    }
  }

  return true
}

export default function shouldPureComponentUpdate(nextProps, nextState) {
  return !shallowEqual(this.props, nextProps) ||
         !shallowEqual(this.state, nextState)
}

class Widget extends Component {
  static propTypes = {
    field: PropTypes.object.isRequired,
  }
  shouldComponentUpdate = shouldPureComponentUpdate
}

@vincentfretin Please file an issue in Redux Form. You shouldn't have to do these optimizations by hand.

Redux DevTools 3.0 Beta 2 should vastly improve performance.
Please help test it: https://github.com/gaearon/redux-devtools/releases/tag/v3.0.0-beta-2

I'm still seeing the same issue in 3.0.5 for onChange.

@stanleycyang Please share a project reproducing the problem.

git clone https://github.com/erikras/redux-form
git checkout gh-pages
npm install
npm run dev

Navigate to http://localhost:3030/#/examples/synchronous-validation
Hold down the spacebar in the username field
Remove the DevTools from the project:  src/index.js by deleting the following line
{devToolsEnabled && !window.devToolsExtension && <DevTools/>}
Refresh
Notice speedup.
You can also get a preview here:  http://erikras.github.io/redux-form/#/examples/synchronous-validation?_k=hl6zzk
This is not just keyup for me.  It's slow for everything.

90% of folks that experience this issue aren't building their react bundle/compile with the production flag on. And another interesting fact of the day, 99% of statistics like my statement are made up! Haha
Best resolution if your building your React app code with grunt or something:
export NODE_ENV=production && grunt

That usually does the trick, IME

I encounter similar problem because I enabled diff flag when creating the redux-logger


Add more info for each status code with a link to the wiki page.

Hi, is that a feature you still consider adding? Would be awesome :)

Yeah, but unfortunately not for a week or two since I'm bogged down with work. I'll keep you posted!


Add JSON linting to ImportTextArea component

Text Area can be replaced with CodeMirror component with JSON linting https://codemirror.net/demo/lint.html
This would add warnings in the gutter for user in case JSON is malformed.
Could research adding validation for the resource that is being imported as well??

we should lint any raw text we display in the UI, including toml for telegraf configs.


eliminate unnecessary update calls from autogen code

initial commit

@tst-basilhuffman I just thought of something. It's possible that we're only seeing failures from the RasterProject code because that's the only code we're testing. It may be that my original suggestion to try this optimization is misguided and it's broken everywhere, and we just haven't noticed it because we're focused on imagery projects. Can you list all the autogenerated files that are affected by this change? We may need to come up with additional tests cases to hit all of them.

@tst-lsavoie
RasterProjectAssetD.cpp
RasterProductAssetD.cpp
MercatorRasterProductAssetD.cpp
VectorLayerXAssetD.cpp
MapLayerAssetD.cpp
MercatorRasterProjectAssetD.cpp

We're probably hitting RasterProject and RasterProduct but almost certainly not the others. While testing this PR we'll need to make sure we're exercising all the code that has changed.

Minor:
The indentation of the condition statements in the auto-generated code is off.


Run WPT tests in debug mode

This lets us use debug_assert!() in Servo. Tests should be run fast enough now that Servo improved.

You're adding steps to the release builders; they'll build Servo in release, and then build it again in debug to make wpt work. Not what we want :smile:

Oh, I need to build debug too I guess?

Isn't the configuration a mess? I think linux_dev_factory and mac_dev_ref_unit_factory are defined twice.

If you want to switch to dev builds, then you should also rename the factories to match. Calling it linux_rel_factory when it builds dev is not the best.
Also, running wpt in debug mode when everything is compiled in release mode will about double our compile times (since it will have to do it twice).
Probably we should switch to running everything in debug. Later we can add new slaves and expand to cover release mode again.

:umbrella: The latest upstream changes (presumably #110) made this pull request unmergeable. Please resolve the merge conflicts.

Rebased and amended, I also renamed the factories and builders accordingly.

How about the CSS tests? Did they improve as well?

@Ms2ger I have absolutely no idea. In doubt, I didn't change it.

Except you did on Linux

I have no idea what you mean. Where did I change test-css?

Oh right, it's right in the middle of it!

So I guess I need to either change the other tests to stay consistent, or to move CSS tests on Linux in a separate factory?

Reviewed 2 of 2 files at r2.
Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from the review on Reviewable.io

You should change the mac-rel-css factory to mac-dev-css. That will make everything consistent. r=me with that change.

@bors-servo r=jack

:pushpin: Commit 0e98538 has been approved by jack

:hourglass: Testing commit 0e98538 with merge daeaeed...

:sunny: Test successful - travis


Adjust prod API flag settings and change support API default

Description
In doing some research for adding a new support API endpoint, I noticed a couple of potential issues:

the new GovCloud prd environment appears to have some APIs turned on -- prime, support, and GHC -- that do not seem to have previously been on in the commercial prod environment.
the SERVE_SUPPORT_API flag defaults to true unless an environment explicitly turns it off (which is opposite of what we do for all other API flags), potentially leading us to serving that API by accident.  This appears to have been the case even before the GovCloud migration.

Reviewer Notes

Am I missing some other place where the flags are set that may be affecting my assumptions?
Did we intentionally decide to serve the APIs as part of the migration?
I changed a few docker-compose files that would have previously had the support API on via the former true default.  I'm less familiar with how these are used, so if the support API should be off in them, let me know.
I'm not sure what the best way to test this would be -- any suggestions?

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against 97548a167b92ac12dc6649bc1288f6a7f59cbc04


always have publish button.fix #6388 for 1.9.3

always have publish button.fix #6388 for 1.9.3

We have updated the issue with the exact actions to apply. WE don't think your changes are correct, probably only the Views should be changed.

this is for draftable

this is without draftable

added new commit for
Action:
Change "Save" to "Save Draft"
Show Publish all the time.

Please target 1.9.x as triaged. thanks.

Too many issues with this PR, please create a new one based on the comments (including merge issues).


There is no v0.14.1 docker image tag for the acryldata/datahub-postgres-setup

Describe the bug
I see that there is no v0.14.1. tag for the acryldata/datahub-postgres-setup container in the Docker hub.
I do see an updated image for the acryldata/datahub-mysql-setup but what about postgres? It's braking the Helm-based deployment with default values because it expects that all components will have the same image tags.
Expected behavior
All DataHub components should have the same release tag, including acryldata/datahub-postgres-setup

This prevented us from updating as well, giving us the following error
Error: UPGRADE FAILED: release datahub failed, and has been rolled back due to atomic being set: pre-upgrade hooks failed: 1 error occurred:
	* timed out waiting for the condition

I worked around it by setting image.tag to the previous working version in the helm values.
postgresqlSetupJob:
  enabled: true
  image:
    repository: acryldata/datahub-postgres-setup
    # tag: "v0.11.0" # defaults to .global.datahub.version
    tag: v<IP_ADDRESS>

While we're working on adding the tag, there is a hash tag 6a165a8 for the v0.14.1 release.

Tag added acryldata/datahub-postgres-setup:v0.14.1


deps(otel): Update OTel to v0.58.0

Proposed Change

Update OTel deps to v0.58.0
Remove awsprometheusremotewriteexporter

This exporter was previously deprecated, and removed in v0.58.0 of contrib

Replace WithMetricsExporterAndStabilityLevel and similar with WithMetricsExporter or its equivalent

Note: This PR does not contain updates to operations collector dependencies.
Tested that his builds and runs locally.
Checklist

[x] Changes are tested
[ ] CI has passed

Note that this has some postgres changes but they are hidden behind feature gates
https://github.com/open-telemetry/opentelemetry-collector-contrib/releases/tag/v0.58.0

Looking into test failures...


Connection reset when using server

OS: Windows 11 23H2
Docker version: Docker version 24.0.7
When running
docker run -p 3333:3333 ghcr.io/chmouel/gosmee:latest server

I'm getting:
Serving for webhooks on http://localhost:3333

But when trying to connect tho this URL I'm getting Connection reset error in browser, and while using curl empty response.

Are there any necessary steps missing to fully utilize this functionality or there is some bug?

@chmouel can someone take a look at this?

this sounds like a docker error to me...

this sounds like a docker error to me...

@chmouel
I've tried on multiple machines with linux/windows and different versions of app (tried latest, v21 v20). Can you provide example that works on your environment?

It seems like it works when using network mode host:
docker run -d --restart always --network host --name ***** ghcr.io/chmouel/gosmee:latest server --port 3026 --address my.ip.address
There seems to be issue when using bridged mode, probably because binding is explicit to localhost. Maybe change it to bind to all ip addresses? Also it would be nice to update the documentation.

i think if you do --address <IP_ADDRESS> that would work isnt it? without having to use network host

i think if you do --address <IP_ADDRESS> that would work isnt it? without having to use network host

@chmouel Thanks for suggestion.
It seems to be working. My current command:
docker run -d -p 3026:3026 --restart always --name example.org ghcr.io/chmouel/gosmee:latest server --port 3026 --address <IP_ADDRESS> --public-url https://example.org
It would be nice to update readme with this example command.


crash with cluster mode  errorcode c0000005

node config like this
port from 6380-6385

need exce redis-cli --cluster create IP:6380 IP:6381 IP:6382 IP:6383 IP:6384 IP:6385 --cluster-replicas 1

need exce redis-cli --cluster create IP:6380 IP:6381 IP:6382 IP:6383 IP:6384 IP:6385 --cluster-replicas 1

in fact i already tested this cluster function before released.maybe something happend.can you send me your all config files,i will test it again.thank you very much

need exce redis-cli --cluster create IP:6380 IP:6381 IP:6382 IP:6383 IP:6384 IP:6385 --cluster-replicas 1

in fact i already tested this cluster function before released.maybe something happend.can you send me your all config files,i will test it again.thank you very much,you can send config file to my email<EMAIL_ADDRESS>
i had send all file to your email

I fixed this issue,it took me long time to locate issue,because that there is a little difficult about this issue. i tested it like this,you test it please and tell me result.

I need quite a long time to test its stability, performance, efficiency

i updated program,please pull new and test it.you can refer to #5 issue,for old version when key number is large,it will stop work.


inputText inputs characters at same position for AutofillHints.newPassword

Is there an existing issue for this?

[X] I have searched the existing issues and didn't find mine.

Steps to reproduce

Download the binary: https://drive.google.com/file/d/15MTRG1wiJtua_x-Cf76SA8QYQEn3rDqs/view?usp=sharing
Install it on the simulator xcrun simctl install Booted LOCAL_PATH_TO_Runner.app
Run the flow maestro --device YOUR_IOS_DEVICE_ID test YOUR_LOCAL_PATH_TO_FLOW_FILE_BELOW

This issue only occurs on iOS. Android works fine.
Here is a recording of the flow: https://youtu.be/sAEdvm6Nuj4
Actual results
The inputText inputs the password characters at the first position, overwriting previously input characters. Also, it inputs the password in both password fields at the same time.
When I comment out the autofillHints for the password field everything works as expected.
Expected results
The password is correctly input in the first password field only.

As it stands right now, it's not reproducible (the code sample is not self contained). Please either provide a self contained code sample (preferred), or share the app binary.

@bartekpacia thank you for notifying me. I have added the app binary. A self contained code sample was not feasible without sharing the complete app's code and API Keys, because it seems like I would need to set up the Apple side stuff for autofill.
Let me know when I can help with anything else!

Hey @Peetee06, thanks for providing the binary. Unfortunately it crashes right after installing on my iOS simulator. Please see attached crash logs (exported from Console.app) and double check that it works for you.
crashlogs.txt
My specs: MacBook M1, macOS Sonoma 14.5, Xcode 15.4, iOS Simulator 17.5

@bartekpacia thank you so much for testing it!
I created a .zip locally now and uploaded it:
https://drive.google.com/file/d/15KxTYVKzuUKMXDEtIbeMaBafjg4EndOL/view?usp=sharing
I tried and had the same issue like you described when downloading the Runner.app directly. It seems like Google Drive does not correctly zip it when downloading and the Runner.app gets corrupted.
I also adjusted the link in the initial post.
Let me know if it works now! :)

Thanks – now I was able to reproduce it. I observe that there's always a single character entered in the "Confirm password" checkbox.
It would help if you uploaded a binary that has the "show password" checkbox.
btw, glad to see Semantics.identifer being put to good use! :)

Here it is: https://drive.google.com/file/d/15MTRG1wiJtua_x-Cf76SA8QYQEn3rDqs/view?usp=sharing :)
I ran into this issue myself while testing the hide/show icons to the password fields. On first install and start of the app, the focus was on both password and confirm password field and overwrote the first character when I typed in it. Tapping on another textfield and then back into the password fixed it. After that it never happened again. Navigating back and forth, reinstalling the app, nothing brought back the issue. Might be a weird simulator issue.
Yes, Semantics.identifier makes it SO easy to create flows. Doing so with localized labels would be such a pain :D


Distributes eigen betas to 'external' testers

'External' is in square quotes because these are all Artsy staff (but not strictly developers). After being merged, new betas of Eigen should go out to both our engineers and our Artsy colleagues (based on the new pilot parameters).

This PR replicates the following emission-nebula commits:
https://github.com/artsy/emission-nebula/commit/360d0bdf14e238f05483b0c977e08707b91c4266
https://github.com/artsy/emission-nebula/commit/8cd5e64444f5121b0ee36036a2348d2a6f5d150e
I already made another necessary change in https://github.com/artsy/emission-nebula/commit/3d281dd01ea40429c371f20ffdf4d9dc0f72ccad to master to unblock an earlier beta deploy (see this tweet for context).

Gonna merge.


Remove disablePipelineExperiments feature flag

JIRA: RHOAIENG-11336
Description

Remove the feature flag disablePipelineExperiments and the supported area PIPELINE_EXPERIMENTS. Make experiments always enabled.
How Has This Been Tested?

Make sure all the tests are passed and the pipeline/experiments can run/navigate correctly. Make sure nothing is broken in the pipelines area.
Also, deploy this branch to a live cluster to see if anything is broken.
Test Impact

N/A, updated mock dashboard config due to API change.
Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

/lgtm
tested in live cluster, nothing is broken in the pipelines area.

/approve


fix(filter): Don't throw key.charAt is not a function when object's keys are not of type string.

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix
What is the current behavior? (You can also link to an open issue here)
When an object has keys which are not of type string, the filter would throw an exception for trying to call charAt, which is not defined on a none-string type.
#15644
What is the new behavior (if this is a feature change)?
This commit checks whether charAt is defined before calling it.
Does this PR introduce a breaking change?
No
Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Other information:

Can you please add a test for this?

I am afraid it is not possible (as discussed in #15644) :grin:

LGTM if it LGT @Narretz :smiley:

LGTM


Refactoring

Refactored using Roslynator plus vs.

@jinbe when you get a chance could you please review these changes?


tests/ctor: Make test_ctor_noncopy_same an Hypothesis test

This likely doesn't matter all that much, but avoids hardcoding an arbitrary value.

I feel like this is testing an optimization, not a reliable behavior? But it's fine.
bors r+

bors r+

@astronouth7303 You are the one who added the test (in fbf3fee245bc20a2a404367e2f395a0c54d9903b)  :P

Oh.


NAS-129371 / 24.10 / Use truenas_api_client

Jira URL: https://ixsystems.atlassian.net/browse/NAS-129371

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.


Fix mjs handling for graphql

Fixes #5234.
Closes #5235.
This pull request allows packages to import from dependencies who export a mjs file (instead of us giving a URL).
It also ensures that a user who uses mjs in their application gets a file.
I'm really getting tired of all of these mjs hacks, because now we "sort of" support mjs. e.g.:
If a user defines their module field in package.json as index.mjs and then explicitly import files with .mjs instead of being extensionless, we'll keep loading them.

I wonder if we can somehow tell webpack to not use module if the field is mjs? That would prevent this hack.

I really don't like this PR. I'd like to somehow use the main key if module is a mjs file.


Update README.md

Fix typo in readme.md(follwing -> following)
Added RELEASE.md

Thanks for adding the RELEASE.md file!

Here's a preview of the changelog:

Typo fix - changed the spelling from 'follwing' to 'following'.

Hi @marcoacierno ! This is the new PR. Please merge it!

@Parikshit-Hooda thanks! :) send me an email with your address and I'll ship the sticker :)


Fixed dialogs not going outside of the iframe

Should fix https://github.com/divio/django-cms/issues/5572

Coverage remained the same at 82.486% when pulling fdae228f10926478b8b020fa80bc3d6dd8142348 on vxsx:bugfix/dialog-sizing into 86354212de1d35afeeded7697ae7f233800e895b on divio:master.


swarmros: 0.3.4-1 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository swarmros to 0.3.4-1:

upstream repository: https://github.com/amilankovich-slab/swarmros.git
release repository: https://github.com/amilankovich-slab/swarmros-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.9.3
previous version for package: 0.3.2-1

Holding for sync.


No Infer action

I've tried installing XInfer both manually from git and via Alcatraz, but after restarting Xcode I cannot see the Infer action neither in the Product menu nor anywhere else. I'm using Xcode 7.1.

me neither - Xcode 7.2

not in Xcode 7.3 either


Cleanup memo usage

This is a very minor cleanup around the usage of React memo(). It removes a few duplicate calls and tries to be more consistent with its usage by applying the memoization along with the export statement when possible.

Amazing!


Using SelectTokens with inequality query dont return object/arrays

I would like to report an behavior that might be considered inaccurate. Using inequality queries in the JsonPath value, ie. $.[?(@.value!=null)] or $.[?(@.value!='string')] will not return arrays or objects.
I've asked this question on stackoverflow and refer to more details with the following links:
Stackoverflow question
Sample fiddle
Is this an issue to be fixed or considered as correct behaivor?
Thanks in advance,
Jan

Finally figured out what was causing the .SelectTokens to ignore arrays and objects when using JSONPath. The issues occurs in QueryExpressions.cs line 78
JValue v = r as JValue;

This will cause any JToken that is JObject/JArray to become null and hence being ignored when compared. My way of fixing this was to replace line 78 with the following code that handles JObject and JArray:
            JValue v = null;
            switch (r.Type)
            {
                case JTokenType.Object:
                case JTokenType.Array:
                    v = new JValue(r.ToString());
                    break;
                default:
                    v = r as JValue;
                    break;
            }

This will ensure that JObject and JArray are returned when calling .SelectTokens. Please comment this solution if the approach has fallbacks and/or can be implemented.

Thanks for the example. I fixed it slightly differently but the result is the same - https://github.com/JamesNK/Newtonsoft.Json/commit/031222d4f4bd541e66f236329591f2427f835174


Slows down Windows 98 and a graphical glitch in VirtualBox during the launch of games.

I installed a new driver (0.4.2023.18) in a virtual machine with Windows 98 installed, but when I start any game in it, it starts to slow down.
Video
Video adapter VMSVGA, 128 MB video memory, 3D acceleration enabled
VirtualBox 6.0.24 r139119 (Qt5.6.2)
What to do?

This is probably simitar problem as for VB 6.1, please try this solution https://github.com/JHRobotics/softgpu/issues/24#issuecomment-1701864038
Unfortunately, I can't currently fully test VirtualBox 6.0. There are a lot of HW/SW combinations and I'm mainly trying to optimize for newer versions. So please be patient.

thank you)) it helped me

Release v0.4.2023.19-alpha should by free of this bug.


pressing Ctrl-C when a new vault is created still prompts for pw verification

PS> Set-Secret -Name TestSecret

cmdlet Set-Secret at command pipeline position 1
Supply values for the following parameters:
SecureStringSecret: **********
Creating a new SecretStore vault. A password is required by the current store configuration.
Enter password: <PRESS CTRL-C>
Enter password again for verification:

It seems like the verification prompt should not be posted. Also, in this case, we should probably state that the secret was not put in the vault.

Fixed for preview3.


Forward __layout slot props to pages

Describe the problem
I'm running into the situation where I have multiple pages all needing access to the same content, and I need to copy boilerplate into all those pages to make that possible.
I have a specific example: I have a whole bunch of pages (/campaigns/[id]/characters, /campaigns/[id]/locations, /campaigns/[id]/quests plus more and all of their subpages too), all of which need access to the campaign object which I get from a remote server. I currently have my system setup so that the actual fetching of the campaign from the API server is done in a central place: /campaigns/[id]/__layout.svelte. I then have logic to write that fetched campaign to a Svelte store if we're running in the browser, or return it as part of the context if we're in SSR. And before fetching from the remote server, I first check if we already have it cached in the store, to prevent duplicate fetches (which are otherwise very frequently happening). Something like this:
<script context="module">
  import { browser } from "$app/env";
  import { get } from "svelte/store";
  import { content } from "$lib/store";

  export async function load({ page, fetch, session }) {
    // If we already have the content, then don't fetch it again
    const storedContent = get(content);
    if (browser && storedContent) {
      return {
        props: { fetchedContent: storedContent }
      };
    }

    // Fetch remote content, give it back as a prop AND context
    const res = await fetch("my remote server url");
    const fetchedContent = await res.json();

    return {
      props: { fetchedContent },
      context: { fetchedContent }
    };
  }
</script>

<script>
  export let fetchedContent;

  // If we're running in the browser, then we can save the fetched content in the store
  if (browser) {
    $content = fetchedContent;
  }
</script>

Every single page then needs this kind of logic to either get the campaign from the store, or to fallback to the freshly fetched object in the context. That way we're using a reactive store in the browser and we can update the object in real time, and when we're running in SSR the store isn't used, but the context is.
<script context="module">
  // Forward context to props
  export async function load({ context }) {
    return { props: context };
  }
</script>

<script>
  import { content as contentStore } from "$lib/store";
  export let fetchedContent;

  // Use the content in the store, but fallback to the context, which is needed for SSR.
  $: content = $contentStore || fetchedContent;
</script>

(I've used "content" instead of "campaign" in these examples since they are somewhat simplified examples)
This works does work fine. I can prevent duplicate fetches (for example when you from from /about to /campaigns/1 to /about and back to /campaigns/1 normally that would result in a new fetch. Or when you go to one of the campaign subpages for the first time in a session, that normally also does a fetch, but my system prevents that, which is great (and important).
The downside is that it's annoying to keep copying this boilerplate to literally every single page where I need access to the campaign object.
Describe the proposed solution
It would be so great to be able to set props on the slot inside of the layout, like this:
// __layout.svelte
<slot {campaign} />

And all the pages could simply do export let campaign and they would have access to the campaign object. All the complex logic of fetching the campaign is in a single place, and we'd forward the resulting object to the page via that slot.
Alternatives considered
No response
Importance
would make my life easier
Additional Information
I have a project with a minimal example where I recreated my current setup so you can play around with it and see the boilerplate involved: https://github.com/kevinrenskers/sveltekit-reproduce/tree/fix/context.

Duplicate of #627

I don't think it is a duplicate, that seems to be about named slots?

I read your feature request as "I want to be able to pass named slots from __layout to pages", which is the same as the linked issue.

No; I want to pass props, I think that is different, right?

Ok I think I understand, that use case is slightly different, reopening. Although I'll say that the proposed solution doesn't seem sound with the rest, and to some extend conflicts with #627 . I think a better solution would be to either automatically pass down all props from the returned load, or introduce a new property like pageProps.

True, passing down all props would be a very handy solution too!

This could also enable inheritance of hydrate and router (and maybe others).
Currently one can choose between disabling the settings for all routes or specifying it on a per route basis.

I used https://kit.svelte.dev/docs#loading-output-stuff  in the main layout to add stuff to the stuff, and then I use it in sub pages / layouts to get stuff from 'stuff'. But it still requires you to do a load, and pass props down.
Adding props in the slot would be great to get rid of the load function, but it works!


Error building on first try

I just cloned the repo. I ran npm install and it installed all the dependencies successfully. However when I ran npm start, it throws the following error:
-- /build/server.js:70 --
var manifest = webpack_require(!(function webpackMissingModule() { var e = new Error("Cannot find module "../build/manifest.json""); e.code = 'MODULE_NOT_FOUND'; throw e; }()));
Error: Cannot find module "../build/manifest.json"
It looks like the manifest.json file isn't being created in the build folder.
Do you guys think I might I messed up while cloning, or missed a step?
Thanks.

Did you solved this?
If not, can you provide some information about your development environment (like operating system and node version) please?


Better double asterisk support

This PR updates the s3fs implementation to support updates made in the Better double asterisks ** support pull request in the filesystem_spec repo.
Successful run: https://github.com/fsspec/filesystem_spec/actions/runs/5847462518/job/15915309957

@martindurant @ianthomas23 Since the upstream PR has been merged, the CI should succeed now.

rerunning

@martindurant Thanks for the rerun. Merging this PR should then fix the filesystem_spec latest master CI: https://github.com/fsspec/filesystem_spec/actions/runs/5968251389/job/16191678409


fix: middle name slice position fix

Nice catch! unfortunately, I can't change the notes since they're recorded on video and we need them to remain in sync


Ci checks

Proposed changes

Format exiting code according to golangci-lint
Add golang-ci lint in build pipeline
Remove frontend and backend checks from push pipeline
this fixes #2649

Types of changes
What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[x] New feature (non-breaking change which adds functionality)
[x] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] I have signed the commit for DCO to be passed.
[x] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)

Dependency

Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:

Too many code changes cannot be merged without proper testing. Can you just setup the golint for the goimport and gofmt checks. Other checks can be added later.
There should be some option for linters in theis github action similar to the original golanci-lint https://golangci-lint.run/usage/linters/

Sir go imports is already working as a separate CI check , can i add gofmt as a check without using golangci-lint ?

I think we need to fix all linting issue. Let's have this PR after the release (15April) with proper testing.

Yes @rajdas98  sir sure , I need to work on this a little more , the goling-ci lint is giving timeout errors in the pipeline , hopefully i will fix it by then

@rajdas98 sir , i have made all the lint fixes and intergarated go-lang ci-lint in  CI/CD as well .Sir all the lint tests are passing , put one test from better code hub is failing . Sir , how can i fix it ?

Closing this PR due to some large merge conflicts. Please raise a new PR for it.


error page

Description
instead of services page it takes us to error page
Expected Behavior
it should be redirected to service page
Show us the trouble with screenshots
https://github.com/OSCode-Community/OSCodeCommunitySite/assets/96969496/47629dc9-0f93-4c0e-b2af-1353915555a5
Which browsers are affected?
No response
Which OS are affected?
No response
Enter the version of your web browser
chrome
Device?
No response
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSoC'23 contributor
[X] I want to work on this issue

@Divesh2003 @Vaishnavi-Patil2211 please assign me this issue


Retry metric middleware probably shouldn't return error if no retry metadata

The retry metric middleware will return an error if it cannot find the retry metadata in the middleware context. This middleware should most likely just forward on the request instead of errorring out.
https://github.com/aws/aws-sdk-go-v2/blob/223893cb4d9d2da39d7f82d87a8614f0f8c95bbe/aws/retry/middleware.go#L132-L135

created in v2 SDK repo.


Make it compatible with Laravel 9

Currently this doesn't work with Laravel 9.
When installing through composer you get
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - json-mapper/json-mapper[2.3.0, ..., 2.10.0] require psr/log ^1.1 -> found psr/log[1.1.0, ..., 1.1.4] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - json-mapper/json-mapper[2.11.0, ..., 2.14.0] require psr/simple-cache ^1.0 -> found psr/simple-cache[1.0.0, 1.0.1] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - json-mapper/laravel-package 2.3.0 requires json-mapper/json-mapper ^2.3 -> satisfiable by json-mapper/json-mapper[2.3.0, ..., 2.14.0].
    - Root composer.json requires json-mapper/laravel-package ^2.3 -> satisfiable by json-mapper/laravel-package[2.3.0].

I tried to fork the JsonMapper package and changed the composer.json file to include the simple-cache version 3:
"psr/simple-cache": "^1.0 || ^2.0 || ^3.0",

And the composer worked. However, when I try to map any model I receive this error
PHP Fatal error:  Declaration of JsonMapper\Cache\ArrayCache::get($key, $default = null) must be compatible with Psr\SimpleCache\CacheInterface::get(string $key, mixed $default = null): mixed in /var/www/html/vendor/json-mapper/json-mapper/src/Cache/ArrayCache.php on line 12

Is there any way to set up the this plugin work with the Laravel 9?

I ran into this yesterday as well. One approach is to include version 1.0 of the simple cache package, then require json-mapper and remove the simple cache package.
Ultimately the package should be able to handle all versions. This is currently blocked as I used an implementation of the interface which aren’t compatibility bel with each other due to the type hints. Will think a bit more on this approach though.


Improve the UI of the Home-Page

Describe the feature
As you can see I will keep the best structure to the cards and improve this part of section and even make it responsive
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I have checked the existing issues
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@Satyam1923 Could you please assign this issue to me under the GSSOC'24 label?


hierarchy: click on top element of attribute pulldown causes pull down to collapse

GIT SHA-1: 8596f1786c88c1329fb12206a3fa5cb1fdf85bd6 - master
tested on Chrome and Firefox:

open hierarchy
click on the default attribute name in pull down menu of a level
menu arrow changes from '<' to 'v'
after that the pull down cannot be used any longer
I have to close the hierchy and start again.

I can reproduce this with the ae database integrated into the web app. Clarifictation: You have to click the button label, not the first entry in the pull-down menu.

I can't reproduce this bug any more - something has changed in the last 5 years. Time to close?

I can't reproduce it either. If only all bugs were magically fixed by waiting five years.