vmess出站的域名是双栈时，部分流量走了IPv6

提交 Issue 之前请先阅读 Issue 指引，然后回答下面的问题，谢谢。
除非特殊情况，请完整填写所有问题。不按模板发的 issue 将直接被关闭。
如果你遇到的问题不是 V2Ray 的 bug，比如你不清楚要如何配置，请使用Discussion进行讨论。

你正在使用哪个版本的 V2Ray？（如果服务器和客户端使用了不同版本，请注明）
4.21.3
你的使用场景是什么？比如使用 Chrome 通过 Socks/VMess 代理观看 YouTube 视频。
win10上开socks代理看Youtube
你看到的不正常的现象是什么？（请描述具体现象，比如访问超时，TLS 证书错误等）
vmess出站的域名是双栈时，部分流量走了IPv6
你期待看到的正确表现是怎样的？
不配置sendthrough时，默认值是<IP_ADDRESS>，应该只走IPv4
请附上你的配置（提交 Issue 前请隐藏服务器端IP地址）。

服务器端配置:
    // 在这里附上服务器端配置文件

客户端配置:
{
    "log": {
        "loglevel": "info"
    },
    "inbounds": [
        {
            "port": 1080,
            "listen": "<IP_ADDRESS>",
            "protocol": "socks"
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        },
        {
            "protocol": "vmess",
            "tag": "ws",
            "settings": {
                "vnext": [
                    {
                        "address": "???", //双栈域名
                        "port": 443,
                        "users": [
                            {
                                "security": "none",
                                "id": "?"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "security": "tls",
                "wsSettings": {
                    "path": "?"
                }
            }
        }
    ],
    "routing": {
        "rules": [
            {
                "type": "field",
                "outboundTag": "direct",
                "domain": [
                    "geosite:cn"
                ]
            }
        ]
    }
}

请附上出错时软件输出的错误日志。在 Linux 中，日志通常在 /var/log/v2ray/error.log 文件中。

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

客户端错误日志:
V2Ray 4.21.3 (V2Fly, a community-driven edition of V2Ray.) Custom
A unified platform for anti-censorship.
2019/11/09 15:44:08 [Warning] v2ray.com/core: V2Ray 4.21.3 started
2019/11/09 15:44:08 [Info] [3333385144] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:44:08 tcp:<IP_ADDRESS>:53365 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:44:08 [Info] [3333385144] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:44:08 [Info] [3333385144] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:09 [Info] [2774331670] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:44:09 [Info] [2774331670] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:44:09 tcp:<IP_ADDRESS>:53363 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:44:09 tcp:<IP_ADDRESS>:53364 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:44:09 [Info] [2774331670] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:09 [Info] [2223073842] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:44:09 [Info] [2223073842] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:44:09 [Info] [2223073842] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:10 [Info] [2223073842] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:44:10 [Info] [3333385144] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:44:10 [Info] [2774331670] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:44:12 [Info] [2579708292] v2ray.com/core/proxy/socks: TCP Connect request to tcp:www.youtube.com:443
2019/11/09 15:44:12 [Info] [2579708292] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:www.youtube.com:443]
2019/11/09 15:44:12 tcp:<IP_ADDRESS>:53371 accepted tcp:www.youtube.com:443 [ws]
2019/11/09 15:44:12 [Info] [2579708292] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:13 [Info] [2579708292] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:www.youtube.com:443 via tcp:???:443
2019/11/09 15:44:19 [Info] [3592358198] v2ray.com/core/proxy/socks: TCP Connect request to tcp:fonts.googleapis.com:443
2019/11/09 15:44:19 [Info] [3592358198] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:fonts.googleapis.com:443]
2019/11/09 15:44:19 [Info] [3592358198] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:19 tcp:<IP_ADDRESS>:53373 accepted tcp:fonts.googleapis.com:443 [ws]
2019/11/09 15:44:19 [Info] [2652465924] v2ray.com/core/proxy/socks: TCP Connect request to tcp:fonts.gstatic.com:443
2019/11/09 15:44:19 tcp:<IP_ADDRESS>:53374 accepted tcp:fonts.gstatic.com:443 [ws]
2019/11/09 15:44:19 [Info] [2652465924] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:fonts.gstatic.com:443]
2019/11/09 15:44:19 [Info] [2652465924] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:20 [Info] [3592358198] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:fonts.googleapis.com:443 via tcp:???:443
2019/11/09 15:44:20 [Info] [3466788818] v2ray.com/core/proxy/socks: TCP Connect request to tcp:i.ytimg.com:443
2019/11/09 15:44:20 [Info] [3466788818] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:i.ytimg.com:443]
2019/11/09 15:44:20 [Info] [3466788818] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:20 tcp:<IP_ADDRESS>:53377 accepted tcp:i.ytimg.com:443 [ws]
2019/11/09 15:44:20 [Info] [4007622444] v2ray.com/core/proxy/socks: TCP Connect request to tcp:fonts.gstatic.com:443
2019/11/09 15:44:20 [Info] [4007622444] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:fonts.gstatic.com:443]
2019/11/09 15:44:20 tcp:<IP_ADDRESS>:53379 accepted tcp:fonts.gstatic.com:443 [ws]
2019/11/09 15:44:20 [Info] [4007622444] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:20 [Info] [3334263461] v2ray.com/core/proxy/socks: TCP Connect request to tcp:clients4.google.com:443
2019/11/09 15:44:20 tcp:<IP_ADDRESS>:53381 accepted tcp:clients4.google.com:443 [ws]
2019/11/09 15:44:20 [Info] [3334263461] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:clients4.google.com:443]
2019/11/09 15:44:20 [Info] [3334263461] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:21 [Info] [2652465924] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:fonts.gstatic.com:443 via tcp:???:443
2019/11/09 15:44:21 [Info] [1398528184] v2ray.com/core/proxy/socks: TCP Connect request to tcp:i.ytimg.com:443
2019/11/09 15:44:21 [Info] [1398528184] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:i.ytimg.com:443]
2019/11/09 15:44:21 [Info] [1398528184] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:21 tcp:<IP_ADDRESS>:53384 accepted tcp:i.ytimg.com:443 [ws]
2019/11/09 15:44:21 tcp:<IP_ADDRESS>:53385 accepted tcp:i.ytimg.com:443 [ws]
2019/11/09 15:44:21 tcp:<IP_ADDRESS>:53386 accepted tcp:i.ytimg.com:443 [ws]
2019/11/09 15:44:21 tcp:<IP_ADDRESS>:53387 accepted tcp:i.ytimg.com:443 [ws]
2019/11/09 15:44:21 tcp:<IP_ADDRESS>:53388 accepted tcp:i.ytimg.com:443 [ws]
2019/11/09 15:44:21 [Info] [2724557779] v2ray.com/core/proxy/socks: TCP Connect request to tcp:i.ytimg.com:443
2019/11/09 15:44:21 [Info] [2724557779] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:i.ytimg.com:443]
2019/11/09 15:44:21 [Info] [2724557779] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:21 [Info] [3130935966] v2ray.com/core/proxy/socks: TCP Connect request to tcp:i.ytimg.com:443
2019/11/09 15:44:21 [Info] [3130935966] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:i.ytimg.com:443]
2019/11/09 15:44:21 [Info] [3130935966] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:21 [Info] [2529123471] v2ray.com/core/proxy/socks: TCP Connect request to tcp:i.ytimg.com:443
2019/11/09 15:44:21 [Info] [2529123471] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:i.ytimg.com:443]
2019/11/09 15:44:21 [Info] [2529123471] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:21 [Info] [3382221503] v2ray.com/core/proxy/socks: TCP Connect request to tcp:i.ytimg.com:443
2019/11/09 15:44:21 [Info] [3382221503] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:i.ytimg.com:443]
2019/11/09 15:44:21 [Info] [3382221503] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:21 [Info] [3334263461] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:clients4.google.com:443 via tcp:???:443
2019/11/09 15:44:21 [Info] [3466788818] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:i.ytimg.com:443 via tcp:???:443
2019/11/09 15:44:22 [Info] [2724557779] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:i.ytimg.com:443 via tcp:???:443
2019/11/09 15:44:22 [Info] [1398528184] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:i.ytimg.com:443 via tcp:???:443
2019/11/09 15:44:22 [Info] [3130935966] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:i.ytimg.com:443 via tcp:???:443
2019/11/09 15:44:22 [Info] [2529123471] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:i.ytimg.com:443 via tcp:???:443
2019/11/09 15:44:23 [Info] [3382221503] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:i.ytimg.com:443 via tcp:???:443
2019/11/09 15:44:23 [Info] [4007622444] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:fonts.gstatic.com:443 via tcp:???:443
2019/11/09 15:44:23 [Info] [3130935966] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > write tcp <IP_ADDRESS>:1080-><IP_ADDRESS>:53386: wsasend: An established connection was aborted by the software in your host machine.
2019/11/09 15:44:23 [Info] [3130935966] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:23 [Info] [2529123471] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > write tcp <IP_ADDRESS>:1080-><IP_ADDRESS>:53387: wsasend: An established connection was aborted by the software in your host machine.
2019/11/09 15:44:23 [Info] [2529123471] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:23 [Info] [3382221503] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:44:23 [Info] [2724557779] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:44:23 [Info] [2724557779] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:23 [Info] [3382221503] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:24 [Info] [1398528184] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1000 (normal)
2019/11/09 15:44:24 [Info] [1398528184] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:44:24 [Info] [382214947] v2ray.com/core/proxy/socks: TCP Connect request to tcp:yt3.ggpht.com:443
2019/11/09 15:44:24 [Info] [382214947] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:yt3.ggpht.com:443]
2019/11/09 15:44:24 [Info] [382214947] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:24 tcp:<IP_ADDRESS>:53394 accepted tcp:yt3.ggpht.com:443 [ws]
2019/11/09 15:44:25 [Info] [382214947] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:yt3.ggpht.com:443 via tcp:???:443
2019/11/09 15:44:26 [Info] [2094777934] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:44:26 tcp:<IP_ADDRESS>:53396 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:44:26 [Info] [2094777934] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:44:26 tcp:<IP_ADDRESS>:53397 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:44:26 [Info] [2094777934] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:26 [Info] [76598316] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:44:26 [Info] [76598316] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:44:26 [Info] [76598316] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:26 [Info] [214678449] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:44:26 tcp:<IP_ADDRESS>:53401 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:44:26 tcp:<IP_ADDRESS>:53402 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:44:26 [Info] [214678449] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:44:26 [Info] [214678449] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:26 [Info] [2481403907] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:44:26 [Info] [2481403907] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:44:26 [Info] [2481403907] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:27 [Info] [76598316] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:44:27 [Info] [2094777934] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:44:27 [Info] [214678449] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:44:27 [Info] [2481403907] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:44:28 [Info] [2774331670] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:44:28 [Info] [2774331670] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:30 [Info] [3731584432] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 15:44:30 tcp:<IP_ADDRESS>:53405 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443 [ws]
2019/11/09 15:44:30 [Info] [3731584432] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-a5meknsd.googlevideo.com:443]
2019/11/09 15:44:30 [Info] [3731584432] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:44:31 [Info] [3731584432] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-a5meknsd.googlevideo.com:443 via tcp:???:443
2019/11/09 15:44:31 [Info] [408288883] v2ray.com/core/proxy/socks: TCP Connect request to tcp:beacons.gcp.gvt2.com:443
2019/11/09 15:44:31 [Info] [408288883] v2ray.com/core/app/dispatcher: taking detour [direct] for [tcp:beacons.gcp.gvt2.com:443]
2019/11/09 15:44:31 [Info] [408288883] v2ray.com/core/proxy/freedom: opening connection to tcp:beacons.gcp.gvt2.com:443
2019/11/09 15:44:31 [Info] [408288883] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:beacons.gcp.gvt2.com:443
2019/11/09 15:44:31 tcp:<IP_ADDRESS>:53407 accepted tcp:beacons.gcp.gvt2.com:443 [direct]
2019/11/09 15:44:32 [Info] [3592358198] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:44:32 [Info] [3592358198] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:35 [Info] [2652465924] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:44:35 [Info] [2652465924] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:44:44 [Info] [4007622444] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:44:44 [Info] [4007622444] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:00 [Info] [214678449] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:45:00 [Info] [214678449] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:01 [Info] [76598316] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > wsasend tcp <IP_ADDRESS>:1080-><IP_ADDRESS>:53397: wsasend: An established connection was aborted by the software in your host machine.
2019/11/09 15:45:01 [Info] [76598316] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:01 [Info] [2094777934] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > wsasend tcp <IP_ADDRESS>:1080-><IP_ADDRESS>:53396: wsasend: An established connection was aborted by the software in your host machine.
2019/11/09 15:45:01 [Info] [2094777934] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:01 [Info] [3246629544] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 15:45:01 [Info] [3246629544] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-a5meknsd.googlevideo.com:443]
2019/11/09 15:45:01 tcp:<IP_ADDRESS>:53409 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443 [ws]
2019/11/09 15:45:01 [Info] [3246629544] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:45:02 [Info] [2340004943] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 15:45:02 [Info] [2340004943] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-a5meknsd.googlevideo.com:443]
2019/11/09 15:45:02 tcp:<IP_ADDRESS>:53412 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443 [ws]
2019/11/09 15:45:02 [Info] [2340004943] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:45:03 [Info] [2340004943] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-a5meknsd.googlevideo.com:443 via tcp:???:443
2019/11/09 15:45:04 [Info] [2481403907] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:45:04 [Info] [2481403907] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:05 [Info] [3246629544] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-a5meknsd.googlevideo.com:443 via tcp:???:443
2019/11/09 15:45:17 [Info] [2948045990] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:45:17 tcp:<IP_ADDRESS>:53414 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:45:17 [Info] [2948045990] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:45:17 [Info] [2948045990] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:45:18 [Info] [3246629544] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:45:18 [Info] [3246629544] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:19 [Info] [2948045990] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:45:31 [Info] [1991397070] v2ray.com/core/proxy/socks: TCP Connect request to tcp:beacons5.gvt3.com:443
2019/11/09 15:45:31 tcp:<IP_ADDRESS>:53417 accepted tcp:beacons5.gvt3.com:443 [ws]
2019/11/09 15:45:31 [Info] [1991397070] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:beacons5.gvt3.com:443]
2019/11/09 15:45:31 [Info] [1991397070] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:45:33 [Info] [1991397070] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:beacons5.gvt3.com:443 via tcp:???:443
2019/11/09 15:45:38 [Info] [3113860390] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:45:38 tcp:<IP_ADDRESS>:53419 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:45:38 [Info] [3113860390] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:45:38 [Info] [3113860390] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:45:39 [Info] [3113860390] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:45:49 [Info] [3731584432] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:45:49 [Info] [3731584432] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:52 [Info] [2340004943] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:45:52 [Info] [2340004943] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:45:56 [Info] [389125497] v2ray.com/core/proxy/socks: TCP Connect request to tcp:clients1.google.com:443
2019/11/09 15:45:56 [Info] [389125497] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:clients1.google.com:443]
2019/11/09 15:45:56 [Info] [389125497] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:45:56 tcp:<IP_ADDRESS>:53426 accepted tcp:clients1.google.com:443 [ws]
2019/11/09 15:45:57 [Info] [389125497] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:clients1.google.com:443 via tcp:???:443
2019/11/09 15:46:01 [Info] [3243508191] v2ray.com/core/proxy/socks: TCP Connect request to tcp:github.com:443
2019/11/09 15:46:01 tcp:<IP_ADDRESS>:53428 accepted tcp:github.com:443 [ws]
2019/11/09 15:46:01 [Info] [3243508191] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:github.com:443]
2019/11/09 15:46:01 [Info] [3243508191] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:03 [Info] [3243508191] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:github.com:443 via tcp:???:443
2019/11/09 15:46:04 [Info] [4107491956] v2ray.com/core/proxy/socks: TCP Connect request to tcp:github.com:443
2019/11/09 15:46:04 tcp:<IP_ADDRESS>:53431 accepted tcp:github.com:443 [ws]
2019/11/09 15:46:04 [Info] [4107491956] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:github.com:443]
2019/11/09 15:46:04 [Info] [4107491956] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:04 [Info] [4204290046] v2ray.com/core/proxy/socks: TCP Connect request to tcp:github.githubassets.com:443
2019/11/09 15:46:04 [Info] [4204290046] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:github.githubassets.com:443]
2019/11/09 15:46:04 tcp:<IP_ADDRESS>:53432 accepted tcp:github.githubassets.com:443 [ws]
2019/11/09 15:46:04 [Info] [4204290046] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:05 [Info] [4107491956] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:github.com:443 via tcp:???:443
2019/11/09 15:46:06 [Info] [4204290046] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:github.githubassets.com:443 via tcp:???:443
2019/11/09 15:46:06 [Info] [882127933] v2ray.com/core/proxy/socks: TCP Connect request to tcp:avatars2.githubusercontent.com:443
2019/11/09 15:46:07 tcp:<IP_ADDRESS>:53435 accepted tcp:avatars2.githubusercontent.com:443 [ws]
2019/11/09 15:46:07 [Info] [882127933] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:avatars2.githubusercontent.com:443]
2019/11/09 15:46:07 [Info] [882127933] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:07 [Info] [1171500569] v2ray.com/core/proxy/socks: TCP Connect request to tcp:avatars1.githubusercontent.com:443
2019/11/09 15:46:07 [Info] [1171500569] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:avatars1.githubusercontent.com:443]
2019/11/09 15:46:07 tcp:<IP_ADDRESS>:53437 accepted tcp:avatars1.githubusercontent.com:443 [ws]
2019/11/09 15:46:07 [Info] [1171500569] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:07 [Info] [477239675] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:46:07 tcp:<IP_ADDRESS>:53439 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:46:07 [Info] [477239675] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:46:07 [Info] [477239675] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:07 [Info] [3919567578] v2ray.com/core/proxy/socks: TCP Connect request to tcp:www.google-analytics.com:443
2019/11/09 15:46:07 [Info] [3919567578] v2ray.com/core/app/dispatcher: taking detour [direct] for [tcp:www.google-analytics.com:443]
2019/11/09 15:46:07 tcp:<IP_ADDRESS>:53441 accepted tcp:www.google-analytics.com:443 [direct]
2019/11/09 15:46:07 [Info] [3919567578] v2ray.com/core/proxy/freedom: opening connection to tcp:www.google-analytics.com:443
2019/11/09 15:46:07 [Info] [3919567578] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:www.google-analytics.com:443
2019/11/09 15:46:07 [Info] [3243508191] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:46:07 [Info] [3243508191] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:46:08 [Info] [1171500569] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:avatars1.githubusercontent.com:443 via tcp:???:443
2019/11/09 15:46:08 [Info] [882127933] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:avatars2.githubusercontent.com:443 via tcp:???:443
2019/11/09 15:46:09 [Info] [4084332874] v2ray.com/core/proxy/socks: TCP Connect request to tcp:collector.githubapp.com:443
2019/11/09 15:46:09 [Info] [3762112530] v2ray.com/core/proxy/socks: TCP Connect request to tcp:api.github.com:443
2019/11/09 15:46:09 [Info] [3762112530] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:api.github.com:443]
2019/11/09 15:46:09 [Info] [3762112530] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:09 tcp:<IP_ADDRESS>:53445 accepted tcp:api.github.com:443 [ws]
2019/11/09 15:46:09 [Info] [4084332874] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:collector.githubapp.com:443]
2019/11/09 15:46:09 tcp:<IP_ADDRESS>:53444 accepted tcp:collector.githubapp.com:443 [ws]
2019/11/09 15:46:09 [Info] [4084332874] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:10 [Info] [3762112530] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:api.github.com:443 via tcp:???:443
2019/11/09 15:46:10 [Info] [4084332874] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:collector.githubapp.com:443 via tcp:???:443
2019/11/09 15:46:11 [Info] [766209158] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:46:11 tcp:<IP_ADDRESS>:53448 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:46:11 [Info] [766209158] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:46:11 [Info] [766209158] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:11 [Info] [382214947] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:46:11 [Info] [382214947] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:46:12 [Info] [766209158] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:46:12 [Info] [3466788818] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:46:12 [Info] [3466788818] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:46:14 [Info] [477239675] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:46:17 [Info] [1838191953] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:46:17 tcp:<IP_ADDRESS>:53450 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:46:17 [Info] [1838191953] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:46:17 [Info] [1838191953] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:17 [Info] [3334263461] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:46:17 [Info] [3334263461] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:46:17 [Info] [554298289] v2ray.com/core/proxy/socks: TCP Connect request to tcp:clients4.google.com:443
2019/11/09 15:46:17 [Info] [554298289] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:clients4.google.com:443]
2019/11/09 15:46:17 [Info] [554298289] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:17 tcp:<IP_ADDRESS>:53452 accepted tcp:clients4.google.com:443 [ws]
2019/11/09 15:46:18 [Info] [1838191953] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:46:18 [Info] [4204290046] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:46:18 [Info] [4204290046] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:46:20 [Info] [554298289] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:clients4.google.com:443 via tcp:???:443
2019/11/09 15:46:24 [Info] [3446913389] v2ray.com/core/proxy/socks: TCP Connect request to tcp:github.com:443
2019/11/09 15:46:24 tcp:<IP_ADDRESS>:53454 accepted tcp:github.com:443 [ws]
2019/11/09 15:46:24 [Info] [3446913389] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:github.com:443]
2019/11/09 15:46:24 [Info] [3446913389] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:24 tcp:<IP_ADDRESS>:53455 accepted tcp:github.githubassets.com:443 [ws]
2019/11/09 15:46:24 [Info] [3779956709] v2ray.com/core/proxy/socks: TCP Connect request to tcp:github.githubassets.com:443
2019/11/09 15:46:24 [Info] [3779956709] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:github.githubassets.com:443]
2019/11/09 15:46:24 [Info] [3779956709] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:25 [Info] [3446913389] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:github.com:443 via tcp:???:443
2019/11/09 15:46:26 [Info] [3779956709] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:github.githubassets.com:443 via tcp:???:443
2019/11/09 15:46:26 [Info] [1680638296] v2ray.com/core/proxy/socks: TCP Connect request to tcp:clients1.google.com:443
2019/11/09 15:46:26 tcp:<IP_ADDRESS>:53458 accepted tcp:clients1.google.com:443 [ws]
2019/11/09 15:46:26 [Info] [1680638296] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:clients1.google.com:443]
2019/11/09 15:46:26 [Info] [1680638296] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:26 [Info] [3049697419] v2ray.com/core/proxy/socks: TCP Connect request to tcp:live.github.com:443
2019/11/09 15:46:26 [Info] [3049697419] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:live.github.com:443]
2019/11/09 15:46:26 tcp:<IP_ADDRESS>:53460 accepted tcp:live.github.com:443 [ws]
2019/11/09 15:46:26 [Info] [3049697419] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:28 [Info] [3049697419] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:live.github.com:443 via tcp:???:443
2019/11/09 15:46:30 [Info] [4254735850] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 15:46:30 tcp:<IP_ADDRESS>:53463 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443 [ws]
2019/11/09 15:46:30 [Info] [4254735850] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-a5meknsd.googlevideo.com:443]
2019/11/09 15:46:30 [Info] [4254735850] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:31 [Info] [4254735850] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-a5meknsd.googlevideo.com:443 via tcp:???:443
2019/11/09 15:46:32 [Info] [1680638296] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:clients1.google.com:443 via tcp:???:443
2019/11/09 15:46:32 [Warning] [1680638296] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > v2ray.com/core/proxy/vmess/outbound: failed to read header > v2ray.com/core/proxy/vmess/encoding: failed to read response header > websocket: close 1000 (normal)
2019/11/09 15:46:32 [Info] [1680638296] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:46:33 [Info] [4106766625] v2ray.com/core/proxy/socks: TCP Connect request to tcp:clients1.google.com:443
2019/11/09 15:46:33 [Info] [4106766625] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:clients1.google.com:443]
2019/11/09 15:46:33 [Info] [4106766625] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:46:33 tcp:<IP_ADDRESS>:53465 accepted tcp:clients1.google.com:443 [ws]
2019/11/09 15:46:34 [Info] [4106766625] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:clients1.google.com:443 via tcp:???:443
2019/11/09 15:46:38 [Info] [3779956709] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:46:38 [Info] [3446913389] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:46:38 [Info] [3779956709] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:46:38 [Info] [3446913389] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:11 [Info] [2948045990] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > wsasend tcp <IP_ADDRESS>:1080-><IP_ADDRESS>:53414: wsasend: An established connection was aborted by the software in your host machine.
2019/11/09 15:47:11 [Info] [2948045990] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:12 [Info] [3754093576] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 15:47:12 [Info] [3754093576] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-a5meknsd.googlevideo.com:443]
2019/11/09 15:47:12 tcp:<IP_ADDRESS>:53469 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443 [ws]
2019/11/09 15:47:12 [Info] [3754093576] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:47:13 [Info] [3754093576] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-a5meknsd.googlevideo.com:443 via tcp:???:443
2019/11/09 15:47:15 [Info] [1991397070] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:47:15 [Info] [1991397070] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:47:24 [Info] [660786599] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 15:47:24 tcp:<IP_ADDRESS>:53471 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443 [ws]
2019/11/09 15:47:24 [Info] [660786599] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-a5meknsd.googlevideo.com:443]
2019/11/09 15:47:24 [Info] [660786599] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:47:25 [Info] [660786599] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-a5meknsd.googlevideo.com:443 via tcp:???:443
2019/11/09 15:47:25 [Info] [3754093576] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:47:25 [Info] [3754093576] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:28 [Info] [4107491956] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:47:28 [Info] [4107491956] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:28 [Info] [3762112530] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:47:28 [Info] [3762112530] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:28 [Info] [3159871344] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 15:47:28 tcp:<IP_ADDRESS>:53473 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443 [ws]
2019/11/09 15:47:28 [Info] [3159871344] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:r2---sn-n4v7sney.googlevideo.com:443]
2019/11/09 15:47:28 [Info] [3159871344] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:47:29 [Info] [4084332874] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:47:29 [Info] [4084332874] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:30 [Info] [3159871344] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r2---sn-n4v7sney.googlevideo.com:443 via tcp:???:443
2019/11/09 15:47:38 [Info] [389125497] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:47:38 [Info] [389125497] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:47:47 [Info] [4254735850] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:47:47 [Info] [4254735850] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:47:48 [Info] [4243875118] v2ray.com/core/proxy/socks: TCP Connect request to tcp:ssl.gstatic.com:443
2019/11/09 15:47:48 tcp:<IP_ADDRESS>:53475 accepted tcp:ssl.gstatic.com:443 [ws]
2019/11/09 15:47:48 [Info] [4243875118] v2ray.com/core/app/dispatcher: taking detour [ws] for [tcp:ssl.gstatic.com:443]
2019/11/09 15:47:48 [Info] [4243875118] v2ray.com/core/transport/internet/websocket: creating connection to tcp:???:443
2019/11/09 15:47:49 [Info] [882127933] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:47:49 [Info] [882127933] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:47:49 [Info] [4243875118] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:ssl.gstatic.com:443 via tcp:???:443
2019/11/09 15:47:58 [Info] [660786599] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2019/11/09 15:47:58 [Info] [660786599] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2019/11/09 15:48:06 [Info] [1171500569] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:48:06 [Info] [1171500569] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2019/11/09 15:48:16 [Info] [4106766625] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2019/11/09 15:48:16 [Info] [4106766625] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe

请附上访问日志。在 Linux 中，日志通常在 /var/log/v2ray/access.log 文件中。

2019/11/09 07:44:22 222.79.???:???:43702 accepted tcp:i.ytimg.com:443
2019/11/09 07:44:22 222.79.???:???:43706 accepted tcp:i.ytimg.com:443
2019/11/09 07:44:22 222.79.???:???:43704 accepted tcp:i.ytimg.com:443
2019/11/09 07:44:23 [240e:d0:2831:9904:71fb:c71c:????:????]:43714 accepted tcp:fonts.gstatic.com:443
2019/11/09 07:44:25 222.79.???:???:43728 accepted tcp:yt3.ggpht.com:443
2019/11/09 07:44:27 222.79.???:???:43732 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 07:44:27 [240e:d0:2831:9904:71fb:c71c:????:????]:43734 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 07:44:27 222.79.???:???:43738 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 07:44:27 222.79.???:???:43742 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 07:44:31 222.79.???:???:43750 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 07:45:03 222.79.???:???:43762 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 07:45:05 [240e:d0:2831:9904:71fb:c71c:????:????]:43766 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 07:45:19 222.79.???:???:43774 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 07:45:32 222.79.???:???:43780 accepted tcp:beacons5.gvt3.com:443
2019/11/09 07:45:39 222.79.???:???:43786 accepted tcp:r2---sn-n4v7sney.googlevideo.com:443
2019/11/09 07:45:57 222.79.???:???:43792 accepted tcp:clients1.google.com:443
2019/11/09 07:46:03 [240e:d0:2831:9904:71fb:c71c:????:????]:43800 accepted tcp:github.com:443
2019/11/09 07:46:05 222.79.???:???:43804 accepted tcp:github.com:443
2019/11/09 07:46:06 222.79.???:???:43808 accepted tcp:github.githubassets.com:443
2019/11/09 07:46:07 222.79.???:???:43812 accepted tcp:avatars1.githubusercontent.com:443
2019/11/09 07:46:08 222.79.???:???:43818 accepted tcp:avatars2.githubusercontent.com:443
2019/11/09 07:46:10 222.79.???:???:43822 accepted tcp:api.github.com:443
2019/11/09 07:46:10 222.79.???:???:43824 accepted tcp:collector.githubapp.com:443
2019/11/09 07:46:12 222.79.???:???:43830 accepted tcp:live.github.com:443
2019/11/09 07:46:14 [240e:d0:2831:9904:71fb:c71c:????:????]:43834 accepted tcp:live.github.com:443
2019/11/09 07:46:18 222.79.???:???:43838 accepted tcp:live.github.com:443
2019/11/09 07:46:20 222.79.???:???:43840 accepted tcp:clients4.google.com:443
2019/11/09 07:46:25 222.79.???:???:43858 accepted tcp:github.com:443
2019/11/09 07:46:25 222.79.???:???:43856 accepted tcp:github.githubassets.com:443
2019/11/09 07:46:28 222.79.???:???:43864 accepted tcp:live.github.com:443
2019/11/09 07:46:30 222.79.???:???:43872 accepted tcp:r2---sn-a5meknsd.googlevideo.com:443
2019/11/09 07:46:32 222.79.???:???:43868 rejected  v2ray.com/core/proxy/vmess/encoding: failed to read request header > read tcp <IP_ADDRESS>:10000->222.79.???:???:43868: i/o timeout
2019/11/09 07:46:34 222.79.???:???:43876 accepted tcp:clients1.google.com:443

其它相关的配置文件（如 Nginx）和相关日志。

如果 V2Ray 无法启动，请附上 --test 输出。

通常的命令为 /usr/bin/v2ray/v2ray --test --config /etc/v2ray/config.json。请按实际情况修改。

如果 V2Ray 服务运行不正常，请附上 journal 日志。

通常的命令为 journalctl -u v2ray。
请预览一下你填的内容再提交。

不用ipv6为什么不从系统关闭ipv6

看你的日志我 Chrome 都卡住了。。不知道为什么，你能具体指出

vmess出站的域名是双栈时，部分流量走了IPv6

出现在错误日志的哪里吗？

这是因为请求DNS时使用了IPV6地址，解决掉这个问题就可以了。

看你的日志我 Chrome 都卡住了。。不知道为什么，你能具体指出

vmess出站的域名是双栈时，部分流量走了IPv6

出现在错误日志的哪里吗？

服务端的access.log可以看到有ipv6的连接


API Add vendor-expose composer command

Cache any installed method to the resources/.method folder so that all subsequent updates follow the prior method by default.
Adds junction action for windows.
Improve console output to log method currently being used.
Fixes https://github.com/silverstripe/silverstripe-installer/issues/206

Great addition :)


Array element index in inline filters / verbose queries?

In inline filters, there's the pseudo variable CURRENT, which refers to the current element. There's no way to figure out the position in the array however:
FOR u IN users
    RETURN u.friends[* RETURN CONCAT(CURRENT.name, " is a friend of ", u.name) ]

AQL doesn't allow mutations to variables, but for the verbose variant, it's possible to do:
FOR u IN users
    FOR i IN 0..LENGTH(u.friends)-1
        RETURN CONCAT(u.friends[i].name, " is a friend of ", u.name)

u.friends[i] should be fine, because it's an array. Probably not a good idea to try the same on a collection, although it seems possible (e.g. users[0]).
For the inline variant, there could be another pseudo variable called CURRENT_INDEX or something along those lines.
For verbose queries, I'm not sure. I really got used to the Python way:
for i, elem in enumerate([6,7,8,9]):
    if i % 2:
        return [elem, i]

but a pseudo variable or function call that returns the current element's array index would also be fine (and not hurt performance I guess, because there's already a counter around, isn't there?)

its currently not possible to enumerate items from the List. The reason is, that its realy hard to tell the sequence in which items show up and are processed. By wanting to make this predictable, many optimizations become very hard, handling it in a distributed setups next to impossible. In general this is a thing the client itself can do much better.

I can see that for the collection case, but what about arrays? The order is defined and there are no dependencies to other documents etc.
Example: http://stackoverflow.com/a/31896052/2044940
Instead of returning a filtered array of procedures, one might want to return the indices of the matching procedures instead. This is possible in a verbose query:
FOR clinic IN clinics
    LET p = (
        FOR i IN 0..LENGTH(clinic.procedures)-1
            FILTER LIKE(clinic.procedures[i].name, "%hemo%", true)
            RETURN i
    )

    RETURN MERGE(
        clinic,
        {procedures: p}
    )

A construct like FOR i, proc IN ENUMERATE(clinic.procedures) would add a huge spoon of syntactic sugar.


bugfix: register workqueue metrics in controller-runtime firstly

What this PR does / why we need it:
Ref to #1372 , because of importing race as https://github.com/kubernetes-sigs/kubefed/issues/1372#issuecomment-801732030, workqueue metrics do not work now.
And this PR try to use an import with highest order to fix this.
Which issue(s) this PR fixes:
Fixes #1372
Signed-off-by: Bruce Ma<EMAIL_ADDRESS>

@mars1024 Could you share an example in this PR of what you are getting solved by importing this package ? What were we missing before ?

Yeah, let's start with the precondition that kubefed is exposing the metrics registry defined in controller-runtime/pkg/metrics.
https://github.com/kubernetes-sigs/kubefed/blob/16b2f5cc4f05c9e9b696970295f353c56d33aa3a/cmd/controller-manager/app/controller-manager.go#L402-L404
So we must make sure that the metrics collectors defined in controller-runtime/pkg/metrics will be used by client-go/util/workqueue through calling SetProvider function to get itself registered, and the SetProvider function has a sync.Once to admit only the first call.
SetProvider is being called in init functions of two packages, k8s.io/component-base/metrics/prometheus/workqueue and sigs.k8s.io/controller-runtime/pkg/metrics, and both of them are imported by kubefed, here is the dependency paths,
kubefed-controller-manager -> k8s.io/apiserver/pkg/server -> k8s.io/apiserver/pkg/storageversion -> k8s.io/component-base/metrics/prometheus/workqueue
kubefed-controller-manager -> sigs.k8s.io/kubefed/cmd/controller-manager/app -> sigs.k8s.io/controller-runtime/pkg/metrics

From the specification of golang, we will know that k8s.io/component-base/metrics/prometheus/workqueue wins, and client-go/util/workqueue will never use the metrics collectors(defined in sigs.k8s.io/controller-runtime/pkg/metrics) which are being exposed.
So this PR is trying to import sigs.k8s.io/controller-runtime/pkg/metrics before k8s.io/component-base/metrics/prometheus/workqueue to make sure calling SetProvider firstly.

In our product environments, we are using kubfed on dependencies of kubernetes 1.17 which has no k8s.io/apiserver/pkg/storageversion.
So the race condition of SetProvider was missed before.

/assign @hectorj2f


Feature/resume parser 2

Release Notes:

Added LinkedIn Partner Verification
Added full resume parsing
Modified i18n of months

Assigning back to Kameron for consideration of comments.

Agree with @TheReal's comments, otherwise LGTM


System.AccessViolationException error causing host process to crash

Description
We have a shared cross platform library that uses a Kafka Consumer on a background long running task.  When run on a windows machine we notice a System.AccessViolationException when the process is finishing up.  This is seen in the event view of our production logs when the application is hosted in IIS and the app pools get recycled.
Up until today I have been unable to reproduce, but a team has reported the same error while running Integration tests with xUnit.  I have created a small sample project and xUnit test project.  When I run the tests directly inside Visual Studio there is no problem but when i run them with dotnet test the error occurs everytime.
KafkaConsumerAccessViolation.zip
How to reproduce
Open the attached project, rebuild then run dotnet test from the root directory

Checklist
Please provide the following information:

[y] A complete (i.e. we can run it), minimal program demonstrating the problem. No need to supply a project file.
[1.5.3 ] Confluent.Kafka nuget version.
[ ] Apache Kafka version.
[ ] Client configuration.
[ Windows] Operating system.
[ ] Provide logs (with "debug" : "..." as necessary in configuration).
[ ] Provide broker log excerpts.
[ ] Critical issue. - while this error is only occurring when the service is shutting down, its creating a lot of prod support warning messages and is now preventing our integration tests from executing

make absolutely sure that no method is being called on the consumer after it is disposed. there are some race conditions under which you can get an access violation exception (rather than object disposed exception) if you do that, which we won't fix for perf. reasons.
you could test this theory by just not disposing the consumer (assuming you only do that on shutdown anyway, it won't matter) and seeing if you continue to see access violation exception.

thanks @mhowlett.  Verified by commenting out the call to consumer.Dispose() in the attached sample program.  The same System.AccessViolationException error is observed.

@mhowlett this issue is increasingly reported, more faced where the data volume is high. I am using dotnet kafka consumer & producer, and have noticed this AccessViolationException, not sure what's causing & how to handle it.
Thanks.

thanks @mhowlett.  I'll try that out and get back to you.  1 other possible usage improvement i'm going to try is to not use the same cancellation token for both the long running Task that hosts the Consumer and the consumer itself.  that way i can cancel the consumer, wait for that to gracefully complete and then stop the Task from StopAsync()

@donalcarpenter Is this still an issue?


Add examples and tutorials for DISTIL

Getting started
CIFAR-10 example
MNIST example
Bio medical example
Imbalance example
Rare class example
Redundancy example
OOD data example

These tutorials are now all present in the tutorials folder.


build: adds built files for #22

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Gather guest disk metrics

I added vm_guest_disk metrics, this builds with docker without any issues. Any feedback would be appreciated.
//erra

Overall looks good. How did you test to make sure it works?

Local tests to make sure the metric page looked ok
Built with build -t vmware_exporter .
Tested with Prometheus and grafana

Prometheus config:

job_name: 'vmware_vcenter'
metrics_path: '/metrics'
static_configs:

targets:

'removed'
relabel_configs:

source_labels: [address]
target_label: __param_target
source_labels: [__param_target]
target_label: instance
target_label: address
replacement: vmware_exporter:9272


Bot sends !pokecatch too late

Loving the bot but recently its started to send the !pokecatch after the pokemon has already escaped. Thanks

Sorry, I wasn't able to reproduce this issue. Please ensure that your system's time is accurate, as the program relies on local time to schedule actions. If the problem persists, could you provide more details about when and how it occurs

Yep timezone issue. My fault, great bot :D

Yep timezone issue, my bad, great bot :D


Remove the pickup cooldown for Baskets when it's collecting items from a Mechanical Belt

Describe the your request
Described in title.
So that it works like a Funnel + Chest, except it lacks of the ability to filter items.

Will this feature enabled by default?


Fixed DateAndSequence archive numbering mode + bugfix no max archives

This PR addresses various issues inherent to the DateAndSequence archive numbering mode :

The Sequence part wouldn't be padded accordingly ;
MaxArchiveFiles wouldn't be respected under some circumstances ;
Using any standard format as ArchiveDateFormat would lead to an ArgumentOutOfRangeException being thrown from a call to String.Substring ;
Performance improvement by using Int32.TryParse instead of Convert.ToInt32 and exception handling as flow control

This looks good, but can you add unit test(s) for this? (for bullet 1 and 3)

@remye06 do you know if this will fix #643?

Your code looks solid, but I think we could improve something in code understanding (comments, methods). Do you agree? See notes.

Hi,
I added a test for the padding.
I factored the file enumeration as you asked to remove duplicate code.
I also found a new bug that I fixed on the fly : the behavior with no MaxArchive (0, the default) was different from the other archive modes. 1 archive would always be replaced instead of an unlimited number of archives being kept.
Further commits are on their way to fulfill the rest of your comments.

Thanks, let us know when it's completed :)
One question, the bug you have found and solved, this was a bug already in the 4.0 release?

PS you can ignore this unit test. It's a race condition issue. But difficult to solve, because it only fails 5% of the times.

Yep, I didn’t introduce it myself if that’s what you mean :p
De : Julian Verdurmen<EMAIL_ADDRESS>Envoyé : mercredi 1 juillet 2015 20:48
À : NLog/NLog
Cc : Rémy Esmery
Objet : Re: [NLog] Fixed DateAndSequence archive numbering mode (#773)
Thanks, let us know when it's completed :)
One question, the bug you have found and solved, this was a bug already in the 4.0 release?
—
Reply to this email directly or view it on GitHubhttps://github.com/NLog/NLog/pull/773#issuecomment-117793384.

I would like to merge this, but IMO I needs some more comments in the code. Can you fix that?

Yep I'll do that ASAP
Sent from my Sony Xperia™ smartphone
---- Julian Verdurmen wrote ----
I would like to merge this, but IMO I needs some more comments in the code. Can you fix that?
—
Reply to this email directly or view it on GitHubhttps://github.com/NLog/NLog/pull/773#issuecomment-122441296.

Thanks in advance!

note to myself: ignore failed unit test

I don't think this will fix #643 since it's a completely different codepath.

Thanks for the feedback!

I will merge this when it has some more comments are mentioned before.

Code looks nice! But there are some small improvements needed:

No Arrays please, but lists. (and dictionaries/hashsets when using .Contains)
Some more documentation is needed. Please document WHY we are doing this, not HOW.
even internal classes should be fully documented. I have seen too many bugs in NLog because of missing docs...(and ambiguous names)

Just noticed another error. When using the following code the MaxArchiveFiles function starts to delete the files starting from sequence number 10 instead of continuing to delete the single digit numbers if it didn't delete all single digit numbers before midnight.
fileTarget.ArchiveFileName = filePath + LogName  +".{##}.log";
fileTarget.KeepFileOpen = false;
fileTarget.ArchiveNumbering = ArchiveNumberingMode.DateAndSequence;
fileTarget.ArchiveEvery = FileArchivePeriod.Day;
fileTarget.MaxArchiveFiles = 30;
fileTarget.ArchiveAboveSize = 1048576; // 1 MB
fileTarget.Layout = "${longdate}|${message}";

The resulting logfile names are:
something.20150812.0.log
...
something.20150812.9.log
something.20150812.10.log
...

Hi,
The last noticed bug can be fixed in another PR?

(maybe we should create a new issue for that, review this and merge it)

I'll go ahead and create and create a new issue.

Thanks!

Can you handle the code comments?

Hi, will do next week, I'm on holidays atm
---- Julian Verdurmen wrote ----
Can you handle the code comments?

Reply to this email directly or view it on GitHubhttps://github.com/NLog/NLog/pull/773#issuecomment-131182261.

OK, I will check it out. Have a good holiday!

I will handle the unit test for #847. Have a good holiday

Working on it atm, I messed up while rebasing. That will be fixed by the day.

Thanks for the up

Just a few reviews of yours to handle (mainly comments) and we're good to go !

OK, let me know when it's done :)

I think we're done here, can you confirm that all is well ?

I will do that this week.

Checked it already! 2 small things and then I will merge it. The refactoring looks very good! :+1:

I'm impressed by your code and style!
Aren't you interested in http://nlog-project.org/2015/08/05/NLog-is-looking-for-developers.html

Merged :)


debug level logging, cleanup and usability in tests

With debug level logging we log too much, however it might allow us to faster to solve regress test failures, so I am proposing that we make debug logging less noisy, but still more noisy than info.
The same would have to be done if we were to consider per-tenant or per-timeline debug or trace logging in prod.
Originally posted by @koivunej in https://github.com/neondatabase/neon/pull/5108#discussion_r1389595844

@arpad-m noted while discussing the pausable failpoint enhancement #6075 that the meaningless "at failpoint X" are useful tracing when understanding the code and when something happens, so even if they were made conditional on actually pausing, we might consider debug! or trace! the not paused case.

Yeah they are "meaningless" in the sense that they don't log anything unexpected, but at the same time we log many such events. It's a question of how much "noise" you want to have in the logs. I personally lean towards a little bit more noise as it might be useful (and for me, during debugging for #5912 it was).


Add Escrow support:

Escrow replaces the existing SusPay implementation with improved code that also adds hashlock support to escrow payments, making RCL ILP enabled.
The new functionality is under the Escrow amendment, which supersedes and replaces the SusPay amendment.
This commit also deprecates the CryptoConditions amendment which is replaced by the CryptoConditionSuite amendment which, once enabled, will allow use of cryptoconditions others than
hashlocks.

Codecov Report

Merging #2038 into develop will decrease coverage by -0.32%.
The diff coverage is 68.33%.

@@             Coverage Diff             @@
##           develop    #2038      +/-   ##
===========================================
- Coverage    67.93%   67.61%   -0.32%
===========================================
  Files          685      680       -5
  Lines        49591    49167     -424
===========================================
- Hits         33689    33244     -445
- Misses       15902    15923      +21

Impacted Files
Coverage Δ

src/ripple/protocol/Indexes.h
100% <ø> (ø)
:white_check_mark:

src/ripple/protocol/TxFormats.h
100% <ø> (ø)
:white_check_mark:

src/ripple/ledger/impl/ApplyStateTable.cpp
86.18% <ø> (ø)
:white_check_mark:

src/ripple/protocol/LedgerFormats.h
100% <ø> (ø)
:white_check_mark:

src/ripple/app/main/Amendments.cpp
100% <ø> (ø)
:white_check_mark:

src/ripple/conditions/Fulfillment.h
100% <100%> (ø)
:white_check_mark:

src/ripple/conditions/Condition.h
100% <100%> (+3.44%)
:white_check_mark:

src/ripple/protocol/impl/LedgerFormats.cpp
100% <100%> (ø)
:white_check_mark:

src/ripple/protocol/impl/TxFormats.cpp
100% <100%> (ø)
:white_check_mark:

src/ripple/app/tx/impl/Escrow.h
100% <100%> (ø)

... and 16 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 b7e2a3b...a7dce81. Read the comment docs.

It might be worth having the escrow unittest test unsupported preamble tags.

@seelabs: the size issue doesn't really concern me at this time because we only accept objects as part of a transaction, and we place limits on the size of transactions. See, for example, https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/Protocol.h#L46
One problem with a limit is this: we don't know the limit of a fulfillment given a condition. A limit means that we might accept a condition, only to then reject the fulfillment for it, something explicitly not allowed in the spec.

:+1:

Unit tests are failing:
#10 failed: PreimageSha256_test.cpp(176)
#12 failed: PreimageSha256_test.cpp(178)

In utils.h, https://github.com/ripple/rippled/pull/2038/commits/c2563984d7616515eb43ae57cb3ece82899cae62#diff-8d3b885a6cc70f3156381be81dd5fc57R118
The check for empty needs to be moved down as s can never be empty here.

:+1:

In 0.60.0-rc1


Assorted improvements to misId code

FYI @hadjichris
List of changes:

cc091e83f20c2f599d0da0e1613a6ec2b7dee3cd: Save text output of UnfoldMisID.cpp and push to repository. Helps spot unwanted/missing changes in the code in future developments.
d039185eec5943a5d3e3c37c7731700bf18697b5: Do not blindly store absolute value of efficiencies. This could lead to negative efficiencies (if there were any) being "swept under the rug". In turn, removing abs exposes some -0 efficiencies. Note that this is not a problem: in the floating point standard zero is signed (e.g. $0 \times -1.2 = -0$) and both $\pm0 = 0$. To avoid being interpreted as a small negative efficiency, store absolute value when the efficiency is exactly zero. To be safe, check for negative values.
0b71f805239582e8fcb56e1d57eea7359c2571dd: small fix to make command in the README.
670f09331a70240b4e8daf26af5f2d02d0266bf5: Add flag to choose between yaml files. Default is rdx-run2.yml. Adding USE_CTRL_SAMPLE=true to make command switches to rdx-run2-misid_ctrl.yml. Avoids manually editing Makefile.
870c6bb489dbde6d14175ee84485ec2304a285d4: Create separete log files for UnfoldMisID.cpp depending on which YAML file is used.
ef97cb68b77578ef08bd8011fade3a882cce496e: Also include logs for ApplyMisIDWeight.cpp to help with future changes.
1b01fcf6a17945e15d6126cc5ac455a5a7bb29a5: Cosmetics.
0fac9e8c5bcd6374c42d80bfbb57399fe2dca158: First attempt at VS Code integration. If you use VS Code, cd to the repository root directory and do code misid-unfold.code-workspace. This will load settings enabling e.g. C/C++ and Python IntelliSense.
e718a1ec55369286a41e700ae06d963ab2d6ff2d: Avoid code duplication by merging rdx-run2.yml and rdx-run2-misid_ctrl.yml. This is bug prone, as eventual changes to one yaml file might not be corretly translate to the other.

The few nodes that differed between the two YAML files were branched into default and misid_ctrl, which correspond to the rdx-run2.yml and rdx-run2-misid_ctrl.yml parameters, respectively.
A --ctrl-sample flag was added added to UnfoldMisID.cpp, ApplyMisIDWeight.cpp and pidcalib_wrapper.py to allow selecting between the default and misid_ctrl nodes. The default and misid_ctrl nodes can be selected by including or omitting the flag.
The Makefile was adapted as well. Now, the USE_CTRL_SAMPLE flag controls the --ctrl-sample flag instead of switching YAML files.

Edit 1:

aaf8ac0e836ec710a6f5329a2206c87cea96a897: Fix helper function printResGeneric in UnfoldMisID.cpp to print matrices correctly. Currently, the matrices get transposed.

Edit 2:

2cb7fec2195e6f131dbfd22120c8112c81adf2cf: Include suffix ctrl_sample in the name of the output file saved in gen directory if --ctrl-sample flag is provided.

The function ensureUnitarity ensures that each row of the response matrices add up to 1 by "fixing" the last element of the row to match $1- ($ sum of previous elements in the row $)$. I understand this amounts to saying "this tagged particle must be of one of the considered true types, i.e., $p$, $\pi$, $K$, $e$ or ghost.

Great majority of changes are below 1% (in absolute value). However, there are a few instances (6) in which the change is of 1% to 10%. There are also 2 other instances in which the last entry is set to 0.
Does RooUnfold require the rows of the response matrix to add to 1 exactly?
By a similar logic, shouldn't the last element of each column also add to one? Meaning each considered true type will be tagged as something.

LGTM!


Intellisense "memorizes" quotation marks after deleted

Issue Type: Bug
Steps to Reproduce:

Before using a variable, type the quotation mark (") and delete.
When you start typing the variable, IntelliSense suggests the variable name with the ".

If you delete and type the @ again, it does not show the quotation marks again (seems to memorize it just once)
Azure Data Studio version: azuredatastudio 1.12.2 (c9bef82ace6c67190d0e83820011a2bbd1f793c1, 2019-10-11T04:56:40.634Z)
OS version: Windows_NT x64 10.0.17763
Extensions (1)

Extension
Author (truncated)
Version

profiler
Mic
0.9.0

The auto-completion list is provided to ADS frontend from the SQL data provider on the intellisense trigger event, like SPACE, COMMA or Ctrl-SPACE keys.  The list won't get updated until the suggestion pop-up is dismissed and reshown, so if the list initially contains surrounding quotes it will until the pop-up is reshown.  This "by design" with the intellisense implementation.  We could fix by not returning the list with quotes at all but seems like the impact is relatively low, as you can not key the first quote character to get an unquoted list.  Please let us know if this workaround doesn't work well for you.


services/horizon: Integration tests

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
services/friendbot, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.
[ ] I've updated any docs (developer docs, .md
files, etc... affected by this change). Take a look in the docs folder for a given service,
like this one.

Release planning

[ ] I've updated the relevant CHANGELOG (here for Horizon) if
needed with deprecations, added features, breaking changes, and DB schema changes.
[ ] I've decided if this PR requires a new major/minor version according to
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.

What
This commit adds a simple integration tests framework for building Horizon tests.
Why
We need integration tests to check how Horizon services work together with each other and Stellar-Core. This is especially important for protocol upgrades where mocking is usually not enough to ensure that everything works correctly and testing different ledger backends (like captive core).
How it works?
To start a new integration test developer should create a new test and use IntegrationTest struct from test package:
func TestProtocol14Sample(t *testing.T) {
	// Prepares the environment for integration tests, see details below
	protocol14Config = test.IntegrationConfig{ProtocolVersion: 14}
	itest := test.NewIntegrationTest(t, protocol14Config)
	defer itest.Close()

	// Client() returns a horizonclient.Client instance connected to the Horizon instance under test.
	root, err := itest.Client().Root()
	assert.NoError(t, err)
	assert.Equal(t, int32(14), root.CoreSupportedProtocolVersion)
	assert.Equal(t, int32(14), root.CurrentProtocolVersion)

	// Ready to accept transactions and HTTP requests.
}

The test above:

Starts a standalone Stellar network at the requested protocol version.
Waits until Horizon starts ingesting.
Gets a root endpoint (using horizonclient.Client pointed at created Horizon instance) and asserts some values.

Under the hood it:

Creates a standalone network using stellar/quickstart:testing image.
Copies a custom horizon binary to a docker container.
Starts all services in a container.
Upgrades the protocol version to the required version.
Waits for ingestion to start.

Additionally, a new CircleCI workspace was added to make the process as easy as possible for developers. It is not started by default (hold) so a developer can start it whenever it's worth checking the integration tests.
To run the integration tests locally a developer:

Needs to have docker installed.
Needs to build a custom horizon binary using the branch they want to test. A binary must be a linux amd64 binary (GOOS=linux GOARCH=amd64 go build -v ./services/horizon).
Run: HORIZON_INTEGRATION_TESTS=true HORIZON_BIN_DIR=$(pwd) go test -v ./services/horizon/internal/integration/...

If a special HORIZON_INTEGRATION_TESTS env variable is not set, the integration tests started with test.IntegrationTest are simply skipped so a normal go test ./... will not be slower because of new tests.
All the steps above are done automatically in CircleCI.
Known limitations

Currently tests are not run in parallel but the API is prepared to do so. Developers should use IntegrationTest.Client() to send requests to a Horizon instance because in the future Horizon may not be present at port 8000.

We've just discussed this with @tamirms and he suggested to use stellar/horizon and docker-compose. I missed the fact that stellar/horizon can build horizon from source so it should definitely work and is more flexible (ex. we can easily switch stellar-core versions only by changing the config instead of rebuilding stellar/quickstart).
Because switching to docker-compose requires some work and changes to stellar/horizon I'm going to merge what we have here to unblock testing and then, when more urgent issues are closed, we'll change the engine in a separate PR. This shouldn't change the API so existing tests should work with new engine.


Querying for a set of entities given their IDs

Hi,
I hope it's OK to ask a question here - always feels a bit odd to me asking a question via an issue.
Assuming I have a set of entity IDs, is there a recommended approach to querying for those entities? Naturally I could just loop over them and query one-by-one, but I was hoping for something more efficient akin to this SQL:
select * from foo
where id IN [1,2,3,4,5]

Currently our support for .Contains() is for literal values only (i.e. specifically not IDs) - see http://brightstardb.readthedocs.org/en/latest/Entity_Framework/#supported-linq-operators
However, I can see that in some cases this would be useful - especially because it would save some roundtrips in client-server setups. It might be possible to extend the LINQ to SPARQL processor to specifically support the use-case of context.Foos.Where(x=>['1', '2', '3', '4', '5'].Contains(x.Id)). I'll log this as an enhancement request.

I've added code for supporting a query of the form:
context.Foos.Where(x=>new []{'1', '2', '3'}.Contains(x.Id))

This would be similar to a SQL query like:
SELECT * from foo where id in [1,2,3]

I have a couple of basic unit tests in there (one to test the generated SPARQL and one to validate that the results of the query are what would be expected). If you hit any problems with it - let me know.


Don't prepend separator before empty window status icons

Only works for catppuccin_window_status_icon_enable = yes

Merge conflict

resolved

OK, I updated the PR not to have conflicts with the latest state of the code.
Also, I removed the second parameter from the prepend_separator function.
Hope that is enough ...


Build PRs in GitHub Actions instead of Travis

Travis is being retired, and we are doing our new automated release workflow (#854) in GitHub Actions.  This is an opportune moment to move our PR and dev builds to GitHub Actions too!

Okay, this had some bloopers in, but is now 🎉 passing 🎉

Okay, this had some bloopers in, but is now 🎉 passing 🎉

@bnookala I don't know how to do that.  Do you have a pointer please?   (Note: at the moment it would only work for merged PRs because I only package on merge, not on PR.)

@bnookala I don't know how to do that.  Do you have a pointer please?   (Note: at the moment it would only work for merged PRs because I only package on merge, not on PR.)

I have also verified the package and archive actions although these will actually run only on merge not on PR.

I have also verified the package and archive actions although these will actually run only on merge not on PR.

Though per discussion with @lstocchi maybe it would be better if the package and archive steps did run on PRs so we could offer people interim builds without having to merge to main.  Luca, let me know what you think, and I will do that and then merge unless you have other concerns:

Don't archive packages at all for now - we don't have proper interim build numbering and we don't want multiple things calling themselves 1.4.7 in circulation (we can revisit once we do have interim build numbering)
Archive on merge to main - we want to offer interim builds but don't want anyone and everyone to be able to create one with a bogus PR.
Archive on PR and merge - we don't want to have to merge a PR just so the customer can test it.

(@bnookala @squillace - would welcome your thoughts too)

Though per discussion with @lstocchi maybe it would be better if the package and archive steps did run on PRs so we could offer people interim builds without having to merge to main.  Luca, let me know what you think, and I will do that and then merge unless you have other concerns:

Don't archive packages at all for now - we don't have proper interim build numbering and we don't want multiple things calling themselves 1.4.7 in circulation (we can revisit once we do have interim build numbering)
Archive on merge to main - we want to offer interim builds but don't want anyone and everyone to be able to create one with a bogus PR.
Archive on PR and merge - we don't want to have to merge a PR just so the customer can test it.

(@bnookala @squillace - would welcome your thoughts too)

@itowlson now i see your point. It could be a good idea. I think that archiving only on merge to main would be enough.
The only reason why a PR is not merged is because we are not able to effectively test it as it happened with snap. We were waiting feedbacks from users that had this particular issue. After several months we got positive responses and we merged. The problem here is the timeframe we receive a feedback. The archive created is stored for 90 days i guess, and we are not sure this timeframe is enough.
So my proposal is, why don't we create a workflow that is triggered by a comment? Users need an archive for a specific PR? They go to that PR, make a new comment (like "/create-archive" or whatever), the workflow is triggered and they can download the vsix. This way even if a user comes to see the PR after 90days, he can still test it without creating the vsix by himself. WDYT?
Not sure if this can work btw, just an idea to be tested.

@itowlson now i see your point. It could be a good idea. I think that archiving only on merge to main would be enough.
The only reason why a PR is not merged is because we are not able to effectively test it as it happened with snap. We were waiting feedbacks from users that had this particular issue. After several months we got positive responses and we merged. The problem here is the timeframe we receive a feedback. The archive created is stored for 90 days i guess, and we are not sure this timeframe is enough.
So my proposal is, why don't we create a workflow that is triggered by a comment? Users need an archive for a specific PR? They go to that PR, make a new comment (like "/create-archive" or whatever), the workflow is triggered and they can download the vsix. This way even if a user comes to see the PR after 90days, he can still test it without creating the vsix by himself. WDYT?
Not sure if this can work btw, just an idea to be tested.

@lstocchi Love the idea of a manual trigger - this would be awesome and might work especially nicely with Bhargav's idea of posting a link back into the triggering PR.  Hopefully we could do this by adding triggers and conditions to this workflow so we don't have parallel ones to maintain.  I'll defer this to a subsequent work item though!

@lstocchi Love the idea of a manual trigger - this would be awesome and might work especially nicely with Bhargav's idea of posting a link back into the triggering PR.  Hopefully we could do this by adding triggers and conditions to this workflow so we don't have parallel ones to maintain.  I'll defer this to a subsequent work item though!


added quotes around factory classes

Updates documentation to reflect suggestions of RuboCop's class factory naming
https://github.com/rubocop-hq/rubocop-rspec/pull/839

Thanks!