TiCDC take long time (may be a day) to recover from TiKV cluster failover

What did you do?
While TiCDC is running well. Rolling update TiKV cluster. After the TiDB back to normal, TiCDC is still hang.
Noted: Pulsar sink is still working properly.
What did you expect to see?
TiCDC will be immediately recovered after TiKV is working back again (SQL is running well and PD dashboard reports that all TiKV is running).
What did you see instead?
TiCDC is hang at the time TiKV was doing rolling update.
TiCDC was stopped at 2022-02-08 03:04:29.671 (current time is Tue Feb  8 05:07:44 UTC 2022).
TiCDC logs at the stopped period:
[2022/02/08 03:02:17.085 +00:00] [INFO] [client.go:189] ["WatchWithChan exited"]
[2022/02/08 03:02:17.085 +00:00] [WARN] [capture.go:302] ["session is disconnected"] [error="[CDC:ErrEtcdSessionDone]the etcd session is done"] [errorVerbose="[CDC:ErrEtcdSessionDone]the etcd session is done\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*EtcdWorker).Run\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/etcd_worker.go:160\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:293\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:02:17.086 +00:00] [INFO] [capture.go:204] ["the processor routine has exited"] [error="[CDC:ErrCaptureSuicide]capture suicide"] [errorVerbose="[CDC:ErrCaptureSuicide]capture suicide\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:303\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:02:17.086 +00:00] [INFO] [acquirer.go:65] ["TimeAcquirer exit"]
[2022/02/08 03:02:17.193 +00:00] [INFO] [capture.go:193] ["the owner routine has exited"] []
[2022/02/08 03:02:17.202 +00:00] [INFO] [capture.go:156] ["capture recovered"] [capture-id=210d58c9-2d98-49ef-9ebd-ee3428f04f8e]
[2022/02/08 03:02:17.220 +00:00] [INFO] [capture.go:121] ["init capture"] [capture-id=5493df0f-97d8-4b6b-87ab-de96185d419b] [capture-addr=<IP_ADDRESS>:8300]
[2022/02/08 03:02:17.241 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=3a74f958-84b0-4f7d-bad2-2f6c193ed78c] [info="{\"id\":\"3a74f958-84b0-4f7d-bad2-2f6c193ed78c\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:02:17.241 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=5493df0f-97d8-4b6b-87ab-de96185d419b] [info="{\"id\":\"5493df0f-97d8-4b6b-87ab-de96185d419b\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:04:19.260 +00:00] [INFO] [client.go:189] ["WatchWithChan exited"]
[2022/02/08 03:04:19.259 +00:00] [WARN] [capture.go:302] ["session is disconnected"] [error="[CDC:ErrEtcdSessionDone]the etcd session is done"] [errorVerbose="[CDC:ErrEtcdSessionDone]the etcd session is done\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*EtcdWorker).Run\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/etcd_worker.go:160\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:293\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:04:19.260 +00:00] [INFO] [capture.go:204] ["the processor routine has exited"] [error="[CDC:ErrCaptureSuicide]capture suicide"] [errorVerbose="[CDC:ErrCaptureSuicide]capture suicide\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:303\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:04:19.261 +00:00] [INFO] [acquirer.go:65] ["TimeAcquirer exit"]
[2022/02/08 03:04:27.298 +00:00] [ERROR] [kv.go:273] ["fail to load safepoint from pd"] [error="context deadline exceeded"] [errorVerbose="context deadline exceeded\ngithub.com/tikv/client-go/v2/tikv.(*EtcdSafePointKV).Get\n\tgithub.com/tikv/client-go/v2@v2.0.0-alpha.0.20211029104011-2fd3841894de/tikv/safepoint.go:148\ngithub.com/tikv/client-go/v2/tikv.loadSafePoint\n\tgithub.com/tikv/client-go/v2@v2.0.0-alpha.0.20211029104011-2fd3841894de/tikv/safepoint.go:183\ngithub.com/tikv/client-go/v2/tikv.(*KVStore).runSafePointChecker\n\tgithub.com/tikv/client-go/v2@v2.0.0-alpha.0.20211029104011-2fd3841894de/tikv/kv.go:266\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:04:30.317 +00:00] [INFO] [capture.go:193] ["the owner routine has exited"] []
[2022/02/08 03:04:30.345 +00:00] [INFO] [capture.go:156] ["capture recovered"] [capture-id=5493df0f-97d8-4b6b-87ab-de96185d419b]
[2022/02/08 03:04:30.403 +00:00] [INFO] [capture.go:121] ["init capture"] [capture-id=02402a06-e96a-448a-94c7-3abd77227877] [capture-addr=<IP_ADDRESS>:8300]
[2022/02/08 03:04:30.644 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=02402a06-e96a-448a-94c7-3abd77227877] [info="{\"id\":\"02402a06-e96a-448a-94c7-3abd77227877\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:04:30.644 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=3a74f958-84b0-4f7d-bad2-2f6c193ed78c] [info="{\"id\":\"3a74f958-84b0-4f7d-bad2-2f6c193ed78c\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:05:26.653 +00:00] [WARN] [pd.go:152] ["get timestamp too slow"] ["cost time"=36.842172ms]
[2022/02/08 03:05:48.654 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=20.701522ms]
[2022/02/08 03:06:30.421 +00:00] [INFO] [reactor_state.go:63] ["remote capture offline"] [capture-id=02402a06-e96a-448a-94c7-3abd77227877]
[2022/02/08 03:06:30.764 +00:00] [INFO] [client.go:189] ["WatchWithChan exited"]
[2022/02/08 03:06:30.764 +00:00] [WARN] [capture.go:302] ["session is disconnected"] [error="[CDC:ErrEtcdSessionDone]the etcd session is done"] [errorVerbose="[CDC:ErrEtcdSessionDone]the etcd session is done\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*EtcdWorker).Run\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/etcd_worker.go:160\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:293\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:06:30.765 +00:00] [INFO] [capture.go:204] ["the processor routine has exited"] [error="[CDC:ErrCaptureSuicide]capture suicide"] [errorVerbose="[CDC:ErrCaptureSuicide]capture suicide\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:303\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:06:30.765 +00:00] [INFO] [acquirer.go:65] ["TimeAcquirer exit"]
[2022/02/08 03:06:37.514 +00:00] [INFO] [capture.go:193] ["the owner routine has exited"] []
[2022/02/08 03:06:37.527 +00:00] [INFO] [capture.go:156] ["capture recovered"] [capture-id=02402a06-e96a-448a-94c7-3abd77227877]
[2022/02/08 03:06:37.569 +00:00] [INFO] [capture.go:121] ["init capture"] [capture-id=ccb8ea81-a1da-4f3b-b306-c2b8676a7949] [capture-addr=<IP_ADDRESS>:8300]
[2022/02/08 03:06:37.590 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=3a74f958-84b0-4f7d-bad2-2f6c193ed78c] [info="{\"id\":\"3a74f958-84b0-4f7d-bad2-2f6c193ed78c\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:06:37.590 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=ccb8ea81-a1da-4f3b-b306-c2b8676a7949] [info="{\"id\":\"ccb8ea81-a1da-4f3b-b306-c2b8676a7949\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:10:48.668 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=33.877846ms]
[2022/02/08 03:15:48.653 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=19.412592ms]
[2022/02/08 03:18:20.061 +00:00] [ERROR] [kv.go:273] ["fail to load safepoint from pd"] [error="context deadline exceeded"] [errorVerbose="context deadline exceeded\ngithub.com/tikv/client-go/v2/tikv.(*EtcdSafePointKV).Get\n\tgithub.com/tikv/client-go/v2@v2.0.0-alpha.0.20211029104011-2fd3841894de/tikv/safepoint.go:148\ngithub.com/tikv/client-go/v2/tikv.loadSafePoint\n\tgithub.com/tikv/client-go/v2@v2.0.0-alpha.0.20211029104011-2fd3841894de/tikv/safepoint.go:183\ngithub.com/tikv/client-go/v2/tikv.(*KVStore).runSafePointChecker\n\tgithub.com/tikv/client-go/v2@v2.0.0-alpha.0.20211029104011-2fd3841894de/tikv/kv.go:266\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:20:48.653 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=18.847963ms]
[2022/02/08 03:25:48.674 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=39.824805ms]
[2022/02/08 03:30:48.656 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=21.735676ms]
[2022/02/08 03:35:48.658 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=23.051845ms]
[2022/02/08 03:40:48.661 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=26.105571ms]
[2022/02/08 03:45:12.657 +00:00] [WARN] [pd.go:152] ["get timestamp too slow"] ["cost time"=32.870307ms]
[2022/02/08 03:45:48.643 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=10.552585ms]
[2022/02/08 03:47:17.051 +00:00] [INFO] [client.go:189] ["WatchWithChan exited"]
[2022/02/08 03:47:17.051 +00:00] [WARN] [capture.go:302] ["session is disconnected"] [error="[CDC:ErrEtcdSessionDone]the etcd session is done"] [errorVerbose="[CDC:ErrEtcdSessionDone]the etcd session is done\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/pkg/orchestrator.(*EtcdWorker).Run\n\tgithub.com/pingcap/tiflow/pkg/orchestrator/etcd_worker.go:160\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:293\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:47:17.051 +00:00] [INFO] [capture.go:204] ["the processor routine has exited"] [error="[CDC:ErrCaptureSuicide]capture suicide"] [errorVerbose="[CDC:ErrCaptureSuicide]capture suicide\ngithub.com/pingcap/errors.AddStack\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/errors.go:174\ngithub.com/pingcap/errors.(*Error).GenWithStackByArgs\n\tgithub.com/pingcap/errors@v0.11.5-0.20210513014640-40f9a1999b3b/normalize.go:159\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).runEtcdWorker\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:303\ngithub.com/pingcap/tiflow/cdc/capture.(*Capture).run.func3\n\tgithub.com/pingcap/tiflow/cdc/capture/capture.go:203\nruntime.goexit\n\truntime/asm_amd64.s:1371"]
[2022/02/08 03:47:17.053 +00:00] [INFO] [acquirer.go:65] ["TimeAcquirer exit"]
[2022/02/08 03:48:06.597 +00:00] [INFO] [capture.go:193] ["the owner routine has exited"] []
[2022/02/08 03:48:06.605 +00:00] [INFO] [capture.go:156] ["capture recovered"] [capture-id=ccb8ea81-a1da-4f3b-b306-c2b8676a7949]
[2022/02/08 03:48:06.619 +00:00] [INFO] [capture.go:121] ["init capture"] [capture-id=fa52a703-230a-40d6-a767-5fdf927b64b2] [capture-addr=<IP_ADDRESS>:8300]
[2022/02/08 03:48:06.639 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=3a74f958-84b0-4f7d-bad2-2f6c193ed78c] [info="{\"id\":\"3a74f958-84b0-4f7d-bad2-2f6c193ed78c\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:48:06.639 +00:00] [INFO] [reactor_state.go:74] ["remote capture online"] [capture-id=fa52a703-230a-40d6-a767-5fdf927b64b2] [info="{\"id\":\"fa52a703-230a-40d6-a767-5fdf927b64b2\",\"address\":\"<IP_ADDRESS>:8300\",\"version\":\"v5.3.0-20211230\"}"]
[2022/02/08 03:50:48.683 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=48.707918ms]
[2022/02/08 03:55:48.651 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=16.650712ms]
[2022/02/08 04:00:48.657 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=21.60413ms]
[2022/02/08 04:05:48.654 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=19.444568ms]
[2022/02/08 04:10:48.663 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=27.630136ms]
[2022/02/08 04:15:42.646 +00:00] [WARN] [pd.go:152] ["get timestamp too slow"] ["cost time"=31.412703ms]
[2022/02/08 04:15:48.661 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=27.337079ms]
[2022/02/08 04:20:48.655 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=20.622079ms]
[2022/02/08 04:25:48.651 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=16.913638ms]
[2022/02/08 04:30:48.660 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=25.508015ms]
[2022/02/08 04:35:48.673 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=36.506651ms]
[2022/02/08 04:40:48.658 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=23.015064ms]
[2022/02/08 04:45:48.653 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=18.7695ms]
[2022/02/08 04:50:48.665 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=29.732531ms]
[2022/02/08 04:55:48.654 +00:00] [INFO] [http_router.go:144] [/metrics] [status=200] [method=GET] [path=/metrics] [query=] [ip=<IP_ADDRESS>] [user-agent=Prometheus/2.30.2] [] [cost=18.95099ms]

Versions of the cluster
Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
Release Version: v5.2.1
Edition: Community
Git Commit Hash: cd8fb24c5f7ebd9d479ed228bb41848bd5e97445
Git Branch: heads/refs/tags/v5.2.1
UTC Build Time: 2021-09-08 02:32:56
GoVersion: go1.16.4
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false

TiCDC version (execute cdc version):
Release Version: v5.3.0-20211230
Git Commit Hash: ca7070c45013c24d34bd9c1e936071253451d707
Git Branch: heads/refs/tags/v5.3.0-20211230
UTC Build Time: 2022-01-05 14:15:40
Go Version: go version go1.16.4 linux/amd64
Failpoint Build: false

What's your TiKV version tikv-server --version?

@overvenus
/tikv-server --version
TiKV
Release Version:   5.2.1
Edition:           Community
Git Commit Hash:   2c99f317d4ba125b772a8b94a6c3c0eb9d07ac59
Git Commit Branch: heads/refs/tags/v5.2.1
UTC Build Time:    2021-09-08 02:32:36
Rust Version:      rustc 1.56.0-nightly (2faabf579 2021-07-27)
Enable Features:   jemalloc mem-profiling portable sse protobuf-codec test-engines-rocksdb cloud-aws cloud-gcp
Profile:           dist_release

@truong-hua Hi, thank you for your feedback!
We found a case that may block TiCDC by TiKV nodes failover. It will be fixed in the next release. See https://github.com/tikv/tikv/pull/11991.

thank @overvenus , but did you mean that we will need to upgrade TiKV to resolve this issue? so it's TiKV related issue?

thank @overvenus , but did you mean that we will need to upgrade TiKV to resolve this issue? so it's TiKV related issue?

Yes, upgrading TiKV is needed, the bug is in TiKV.

thank @overvenus. But do you know any workaround solution from TiCDC side like whether rolling update TiCDC will work? Upgrading TiKV is possible but I'm worry it will take a long time for next TiKV version and it may take us a lot of troubles in upgrading TiKV which will affect all other TiDB components.

There is a workaround,

Step 1, identify "straggler" TiKV in TiCDC dashboard

Step 2, identify "straggler" Region in TiCDC dashboard

Step 3, resolve locks in "straggler" Region
cdc cli unsafe resolve-lock --region=662791, added in #4643
Step 4, wait and see if checkpoint advances, if not repeat step 1 to step 4.

Note: the above only works if there is a region continuously pops up in "Min resolved Region".

unsafe resolve-lock

unsafe resolve-lock

There is a workaround,

Step 1, identify "straggler" TiKV in TiCDC dashboard

Step 2, identify "straggler" Region in TiCDC dashboard

Step 3, resolve locks in "straggler" Region
cdc cli unsafe resolve-lock --region=662791, added in kv,cmd(ticdc): refinement about resolve lock #4643
Step 4, wait and see if checkpoint advances, if not repeat step 1 to step 4.

Note: the above only works if there is a region continuously pops up in "Min resolved Region".

cdc cli unsafe resolve-lock --region=662791 ，Can this command be executed?


Time and duration literals in Z

Z should probably at some point support time and duration literals, like it does for addrs and nets.

Verified in zq commit 28a347d.
Let's isolate a few records containing time and duration types in our zq-sample-data.
zq-sample-data/zeek-default$ zq -z 'head 5 | cut ts,duration,uid' conn.log.gz
{ts:2018-03-24T17:15:21.255387Z,duration:4.266ms,uid:"C8Tful1TvM3Zf5x8fl" (bstring)} (=0)
{ts:2018-03-24T17:15:21.411148Z,duration:486us,uid:"CXWfTK3LRdiuQxBbM6"} (0)
{ts:2018-03-24T17:15:21.926018Z,duration:538us,uid:"CM59GGQhNEoKONb5i"} (0)
{ts:2018-03-24T17:15:22.690601Z,duration:546us,uid:"CuKFds250kxFgkhh8f"} (0)
{ts:2018-03-24T17:15:23.205187Z,duration:605us,uid:"CBrzd94qfowOqJwCHa"} (0)

Revisiting the state of things at zq commit ec3250b that came right before the changes in the linked PR, attempts to match on such values would fail.
zq-sample-data/zeek-default$ zq -version
Version: v0.29.0-160-gec3250b8

zq-sample-data/zeek-default$ zq -z 'head 5 | ts=2018-03-24T17:15:21.411148Z | cut ts,uid' conn.log.gz
cut: no record found with columns ts,uid

zq-sample-data/zeek-default$ zq -z 'head 5 | duration=538us | cut ts,duration,uid' conn.log.gz
cut: no record found with columns ts,duration,uid

However, at zq commit 28a347d, these now succeed.
zq-sample-data/zeek-default$ zq -version
Version: v0.29.0-167-g28a347d7

zq-sample-data/zeek-default$ zq -z 'head 5 | ts=2018-03-24T17:15:21.411148Z | cut ts,uid' conn.log.gz
{ts:2018-03-24T17:15:21.411148Z,uid:"CXWfTK3LRdiuQxBbM6" (bstring)} (=0)

zq-sample-data/zeek-default$ zq -z 'head 5 | duration=538us | cut ts,duration,uid' conn.log.gz
{ts:2018-03-24T17:15:21.926018Z,duration:538us,uid:"CM59GGQhNEoKONb5i" (bstring)} (=0)

Thanks @mccanne!


After last Update my sidebar broken

Since the last update my sidebar is not working properly. It no longer opens. Tested in Firefox, Brave and Chrome, my OS is Windows 11 Pro. Even with a completely fresh ComfyUI installation, the error persists. I have attached the console log from the browser, the terminal shows me no errors. I have also attached a picture of how it currently looks when unfolded.

Me, too. I get that question a lot

Me, too.+1

Hi, it looks like something related to the file that contains the templates in comfyui, I will check as soon as I can 😢

Hi, it looks like something related to the file that contains the templates in comfyui, I will check as soon as I can 😢 If you try to resize it using the mouse it doesn't work?

Hi thanks for your work. Unfortunately, I've only just got around to testing your template. Yes, your type works if you enlarge the bar when the “C” is displayed, it appears again and remains at the size even after a restart of the UI.

Thank you, it worked, occasionally you can show the drag mouse zoom window logo, drag out

Ok, that should be fixed now: if there is no width dimension set, it will fall back to 200px.


Bug: The cluster and environment filter does not work as intended

📜 Description
When we are applying filter of both cluster and environment then the UI shows all the applications of that cluster instead of environment specific apps of that cluster.
👟 Reproduction steps
1.First add a cluster filter.
2.Now add the filter based on environment.
👍 Expected behavior
Show the applications of only that cluster  environment which is filtered.
👎 Actual Behavior
Shows all the applications of that cluster instead of environment specific apps of the filtered cluster.
☸ Kubernetes version
EKS 1.28
Cloud provider

AWS

🌍 Browser
Chrome
🧱 Your Environment
No response
✅ Proposed Solution
No response
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

AB#10042

How can you apply both the filters at the same time ?

Closing as the issue has been fixed.


[missing file]HTTP request sent, awaiting response... 404 Not Found

Version info

bcbio version (bcbio_nextgen.py --version):1.2.3
OS name and version:Ubuntu 18.04

To Reproduce

Exact bcbio command you have used: python bcbio_nextgen_install.py -u development /apps1/local/share/bcbio --tooldir=/apps1/local --genomes hg19 --aligners bwa --aligners bowtie2

Observed behavior
Error message or bcbio output.
' ' '

Running GGD recipe: hg19 genesplicer 2004.04.03
--2020-05-08 16:27:45--  http://www.cs.jhu.edu/~genomics/GeneSplicer/GeneSplicer.tar.gz
Resolving www.cs.jhu.edu (www.cs.jhu.edu)... <IP_ADDRESS>
Connecting to www.cs.jhu.edu (www.cs.jhu.edu)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-05-08 16:27:45 ERROR 404: Not Found.

' ' '
Expected behavior
A clear and concise description of what you expected to happen.
Log files
Please attach (10MB max): bcbio-nextgen.log, bcbio-nextgen-commands.log, and bcbio-nextgen-debug.log.
Additional context
Hello,
I was installing bcbio, but ran into an issue due to a missing web link: http://www.cs.jhu.edu/~genomics/GeneSplicer/GeneSplicer.tar.gz
And fortunately, I found an alternative link to replace the original link:
ftp://ftp.ccb.jhu.edu/pub/software/genesplicer/GeneSplicer.tar.gz
I am not sure if this is a temporary issue, but I would appreciate if you let me know how to fix this.
Thank you.

Thanks for reporting @tykim0109!
It seems they removed the file from the server.
I've fixed the cloudbiolinux script with ftp link you provided.
https://github.com/chapmanb/cloudbiolinux/blob/master/ggd-recipes/GRCh37/genesplicer.yaml.
Please re-open if you still have issues with this recipe.
Sergey


Translate Uniffle - New chapter for the shuffle in the cloud native era

Based on https://docs.qq.com/doc/DYVJwS3FRbmRtZ3J0

Thanks @cdmikechen


dir was not closed if you break the iterator in Lua 5.3

Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> require 'lfs'
table: 0x560a3d27abb0
> while true do; for dir in lfs.dir('/') do; break; end; end
stdin:1: cannot open /: Too many open files
stack traceback:
	[C]: in function 'lfs.dir'
	stdin:1: in main chunk
	[C]: in ?

related commit: https://github.com/keplerproject/luafilesystem/commit/842505b6a33d0b0e2445568ea42f2adbf3c4eb77

@xuzhen Yes, this is a limitation of Lua 5.3. This does not happen on Lua 5.4 because there is explicit support for closing resources in the for loop. In Lua 5.3, the workaround is to call lfs.dir in a separate line to get the dir_obj and close it yourself.


Flashing pre-compiled hex files

For the Teensy boards, I'm wondering if it's possible to flash a previously compiled hex file without having to run fprime-util build to wait for the Teensy window to pop up

You would still need the Teensyduino GUI to be open, but from there you can select any .hex file. If you save a .hex file under build-artifacts/teensy41/BaremetalReference/bin/BaremetalReference.hex outside of build-artifacts, you can re-select that file in the Teensyduino GUI and upload it.

I think I figured it out! Just needed to dig around for where the Teensyduino GUI launcher was located


fix aborted and force complete request not killing the jobs

This is not tested and still has some issues.
Here is possible issues (might not be critical though).

There is race condition if some workflow is not cleaned up by LQ but it moved to aborted-archived status. (This should be rare but need to be fixed by how we propagate aborted-completed and       *-archived status from multiple agent).

Jobs still can be created and submitted between the time user aborted and killing job happens.
a. currently aborted workflow check is made for wmbs population to prevent further pulling down the work
b. But we can also add the check in JobCreator and JobSubmitter. (Not sure how much we will gain this - If we need to choose JobSubmitter check will be more effective)

killWork can be called concurrently (but it should cause the deadlock on db)

@amaltaro, Alan, don't need to review yet. I will update the code.

Since clean up polling cycle is random there are considerable jobs are submitted after aborted and force complete happens. Although they are removed eventually, it is better to add the code not to submit those jobs. (Also somehow the killWorflow doesn't seem to kill pending jobs. I will update the patch.

Since clean up polling cycle is random there are considerable jobs are submitted after aborted and force complete happens.

You mean the WorkQueueManager polling cycle to locally abort the workflow (cancel wq elements, kill jobs, etc)? If the delay between the request status transition (to aborted or force-completed) and killing the jobs and not submitting anything new is < 30min, then it should be good enough.

(Also somehow the killWorflow doesn't seem to kill pending jobs. I will update the patch.

I was force-killing workflows during the last week (which in the end call killWorkflow) and I didn't have any issues. From the PyCondor point of view, there is no distinction between JobStatus.
Now getting back to your initial comments in this PR. The worst case scenario I can see is a race condition between locally killing the workflow and adding new subscriptions to wmbs_subscription (pulling work from LQ to WMBS). To avoid that problem, I think we should split this killing in two steps (two different polling cycles):

marking wq elements to Cancel (in all possible couch databases :-))
then completing work on SQL db (including what is created - in the JobSubmitter queue) and killing jobs from condor.

This would likely prevent some work that was already being processed by WorkQueueManager.
Sorry for being so verbose, checking your code now :)

Test in vm, it seems working OK.

test this please

@amaltaro, Hi Alan. I think patch is ready.
I am not sure why following test fails, it doesn't seem to be related.
WMCore_t.WorkQueue_t.WorkQueue_t.WorkQueueTest:testGlobalBlockSplitting changed from success to failure

test this please

@ericvaandering, Hi Eric, The report looks nice but one thing is missed compare to before is there is no stack trace where the failure occurs.

test this please

@ericvaandering, Hi Eric, The report looks nice but one thing is missed compare to before is there is no stack trace where the failure occurs.

Never mind, Sorry now I found the link for that (default one)

Yeah, there is still the full Jenkins stuff under the "default details". This is just meant to replace the e-mails.

And now I may know why wmbs was still creating jobs for aborted/force-completed workflows.
It seems we only update the workqueue db that is replicated (so global workqueue and local workqueue_inbox). The local workqueue is probably (I didn't find the code) updated by one of the WorkQueueManager threads and it only updates those elements to Done when all the local workqueue_inbox are marked as Canceled (which may as well be gone from the agent by there), see WQ data for a force-completed workflow [1].
Relying on the reqmgr status is certainly better than on the element status in couch. However, if we were marking as Canceled (or Done) local workqueue elements here:
https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/WorkQueue/WorkQueue.py#L515
I think it would have avoided most of these problems.
[1]
cmst1@vocms0230:/data/srv/wmagent/current $ python getWQStatusByWorkflow.py amaltaro_MonteCarlo_eff_December_Patches_161218_182044_5572
Summary for https://cmsweb-testbed.cern.ch/couchdb/workqueue and request amaltaro_MonteCarlo_eff_December_Patches_161218_182044_5572
{u'Canceled': {u'http://vocms0230.cern.ch:5984': 3}, 'numberOfElements': 3}
Summary for http://localhost:5984/workqueue and request amaltaro_MonteCarlo_eff_December_Patches_161218_182044_5572
{u'Running': {None: 3}, 'numberOfElements': 3}
Summary for http://localhost:5984/workqueue_inbox and request amaltaro_MonteCarlo_eff_December_Patches_161218_182044_5572
{u'Canceled': {u'http://vocms0230.cern.ch:5984': 3}, 'numberOfElements': 3}

@ticoann I made this patch to test another approach (without depending on changes in cmsweb): https://github.com/amaltaro/WMCore/commit/bc46eaf3a9113b58bf4e06ece653e76115e58fd2
In plain english, it should behave like:

once WorkQueueManager finds a workflow aborted (CancelRequested)
1.a) it moves the inbox elements to Canceled (but only elements pulled by the agent or available in GQ)
1.b) it moves ALL the local workqueue elements to Canceled (avoiding wmbs to pick up work)
TaskArchiver (in any agent) will only move the request status to {aborted-}completed if ALL the local workqueue_inbox elements (= global workqueue elements) for that workflow were Canceled
2.a.) meaning, all the agents working on that request have to go through and cancel work on their local queue.

First test looks promising. Ping me on slack please and we can discuss it over vidyo.


Partials not picking up correctly when using ViewLocalization.

With this simple html:
<div>
@await Html.PartialAsync("Slider")
</div>

Culture set to "es" for sample purposes.
Having this folder structure:
Views/Home/Index.cshtml
Views/Home/Slider.cshtml
Views/Home/Slider.es.cshtml

The partial call will pick up Slider.cshtml, not Slider.es.cshtml. (aka the generic version, even we have a special localized one)
If we move the slider.cshtml to the Shared folder, it works as expected. (picking Slider.es.cshtml)
If we move both to Shared folder, same problem again, Slider.cshtml is picked.
So, looks like having both views in the same folder it will always picks the non-locale (generic) version of it no matter what. I can provide a repo if needed.

wrong repo :( Should I close this and reopen on mvc?

If this related to MCV I advice to close this and open it again


YARN-11413. Fix Junit Test ERROR Introduced By YARN-6412.

JIRA: YARN-11413. Fix Junit Test ERROR Introduced By YARN-6412.
YARN-6412 (#5242) caused TestCommonConfigurationFields#testCompareXmlAgainstConfigurationClass to be wrong.
We can see the following error message
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5193/15/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-api.txt
[ERROR] testCompareXmlAgainstConfigurationClass  Time elapsed: 0.292 s  <<< FAILURE!
java.lang.AssertionError: yarn-default.xml has 2 properties missing in  class org.apache.hadoop.yarn.conf.YarnConfiguration Entries:   yarn.nodemanager.aux-services.%s.classpath  yarn.nodemanager.aux-services.%s.system-classes expected:<0> but was:<2>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.apache.hadoop.conf.TestConfigurationFieldsBase.testCompareXmlAgainstConfigurationClass(TestConfigurationFieldsBase.java:540)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	.....

@brumi1024 @riyakhdl I found that YARN-6412 (#5242) introduces a unit test bug, I think it is necessary to add instructions in yarn-site.xml, but we should let testCompareXmlAgainstConfigurationClass ignore the newly added property yarn.nodemanager.aux-services.%s.classpath 、yarn.nodemanager.aux-services.%s.system-classes.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  1s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
45m 51s

trunk passed

+1 :green_heart:
compile
23m  7s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
20m 33s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m 14s

trunk passed

+1 :green_heart:
mvnsite
1m 42s

trunk passed

-1 :x:
javadoc
1m 13s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-common in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
0m 49s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m 40s

trunk passed

+1 :green_heart:
shadedclient
25m 36s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  4s

the patch passed

+1 :green_heart:
compile
22m 30s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
22m 30s

the patch passed

+1 :green_heart:
compile
20m 38s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
20m 38s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  5s

the patch passed

+1 :green_heart:
mvnsite
1m 40s

the patch passed

-1 :x:
javadoc
1m  6s
/patch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-common in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
0m 51s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m 41s

the patch passed

+1 :green_heart:
shadedclient
25m  5s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 26s

hadoop-common in the patch passed.

+1 :green_heart:
asflicense
1m  4s

The patch does not generate ASF License warnings.

220m 10s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5289

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux b5eda3c7f44c 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / c014609d872dbd64a082b680eaac086a8214c5cc

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/1/testReport/

Max. process+thread count
1278 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common U: hadoop-common-project/hadoop-common

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Thanks @slfan1989 for the quick reaction! I think the test is at fault here, because the properties that doesn't match this pattern are filtered out. So basically every configuration property that has the %s in its name for string replacement will break this test if it gets documented, which is exactly the opposite of what this test should be doing. Can you please update the pattern instead?

Thanks @slfan1989 for the quick reaction! I agree that the test is at fault here, because the properties that doesn't match this pattern are filtered out from the Configuration file, so basically every configuration property that has the %s in its name for string replacement will break this test once it gets documented, which is exactly the opposite of what this test should be doing. However instead of skipping these props, can you please update the pattern?

@brumi1024 Thanks for your suggestion, I will fix it as soon as possible.

@brumi1024 can you take a look?

@goiri see my comment above. I think adding these two props to the skipped list is just hiding a different problem, the pattern should be fixed. I can provide an update tomorrow if @slfan1989 doesn’t have the time for it.

@goiri @brumi1024 Thank you very much for helping to review the code,  I'll try to fix it.

@goiri @brumi1024
Code modification instructions are as follows:
1.Modify the pattern and add % to identify attributes containing %s.
yarn.nodemanager.aux-services.%s.classpath and yarn.nodemanager.aux-services.%s.system-classes can be identified.
2.There are some properties in YarnConfiguration containing %s, but these properties do not exist in yarn-site.xml, this part of properties, I will add them to configurationPropsToSkipCompare.
The attribute information is as follows:
yarn.log-aggregation.%s.remote-app-log-dir
yarn.log-aggregation.%s.remote-app-log-dir-suffix
yarn.log-aggregation.file-controller.%s.class
yarn.nodemanager.aux-services.%s.class
yarn.nodemanager.health-checker.%s.interval-ms
yarn.nodemanager.health-checker.%s.opts
yarn.nodemanager.health-checker.%s.path
yarn.nodemanager.health-checker.%s.timeout-ms
yarn.nodemanager.aux-services.%s.remote-classpath
yarn.nodemanager.runtime.linux.%s.class

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 40s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 38s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
31m  3s

trunk passed

+1 :green_heart:
compile
23m  4s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
20m 23s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
3m 48s

trunk passed

+1 :green_heart:
mvnsite
2m 43s

trunk passed

-1 :x:
javadoc
1m 15s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-common in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
1m 42s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
4m 50s

trunk passed

+1 :green_heart:
shadedclient
24m 46s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 29s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 51s

the patch passed

+1 :green_heart:
compile
22m 19s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
22m 19s

the patch passed

+1 :green_heart:
compile
20m 26s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
20m 26s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
3m 37s
/results-checkstyle-root.txt
root: The patch generated 2 new + 49 unchanged - 0 fixed = 51 total (was 49)

+1 :green_heart:
mvnsite
2m 45s

the patch passed

-1 :x:
javadoc
1m  5s
/patch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-common in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
1m 39s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
4m 57s

the patch passed

+1 :green_heart:
shadedclient
24m 58s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 20s

hadoop-common in the patch passed.

-1 :x:
unit
1m 16s
/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-api.txt
hadoop-yarn-api in the patch passed.

+1 :green_heart:
asflicense
1m  2s

The patch does not generate ASF License warnings.

238m 43s

Reason
Tests

Failed junit tests
hadoop.yarn.conf.TestYarnConfigurationFields

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5289

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 1569700e1dda 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / f240bd38d3af35a1c7b9dba96b32fdd1c8874fe6

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/2/testReport/

Max. process+thread count
1320 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 59s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 22s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
31m 24s

trunk passed

+1 :green_heart:
compile
23m 15s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
20m 25s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
3m 47s

trunk passed

+1 :green_heart:
mvnsite
2m 43s

trunk passed

-1 :x:
javadoc
1m 15s
/branch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-common in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
1m 41s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
4m 46s

trunk passed

+1 :green_heart:
shadedclient
24m 52s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 29s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
1m 49s

the patch passed

+1 :green_heart:
compile
22m 28s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
22m 28s

the patch passed

+1 :green_heart:
compile
20m 47s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
20m 47s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
3m 34s

the patch passed

+1 :green_heart:
mvnsite
2m 45s

the patch passed

-1 :x:
javadoc
1m  7s
/patch-javadoc-hadoop-common-project_hadoop-common-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-common in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
1m 41s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
4m 58s

the patch passed

+1 :green_heart:
shadedclient
25m  3s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
18m 25s

hadoop-common in the patch passed.

+1 :green_heart:
unit
1m 16s

hadoop-yarn-api in the patch passed.

+1 :green_heart:
asflicense
1m  2s

The patch does not generate ASF License warnings.

239m 47s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5289

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux e9d03bba0c2e 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ae84b7567a17fde6cc9943a329ef8bcce09346b6

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/3/testReport/

Max. process+thread count
1693 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5289/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@brumi1024 Can you help to review this PR again? Thank you very much!

@slfan1989 merged to trunk.

@brumi1024 Thank you very much for helping to review the code!


Added Goatcounter events for About page and FAQ page

Maybe prepend it with "accessed page "

I changed the counter titles to "Accessed Page:About" and "Accessed Page:FAQ"

@NeedADispenserHere I needed to wrap the code in a useEffect otherwise the code would run for each re-render of the page, even those running inside /about/ or /faq/ routes
Heres some documentation about useEffect and why I needed to use it https://react.dev/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means


Needs to support multiple targets

Hi Denny
Could you possibly review https://redmine.pfsense.org/issues/4354 and let us know your thoughts? I am more than happy to donate financially to the cause if that helps. I had a bad outage yesterday on a pfSense 2.3.2_p1 system that was due to a false positive on dpinger. This caused a gateway to get marked "down" when it wasn't really an ISP issue. We believe it was just an <IP_ADDRESS> problem.
It has been suggested by myself and others that allowing additional targets would really help reduce these edge cases and improve reliability.

Hey Luke,
I understand what you are trying to accomplish, but dpinger is not the place to implement that type of logic. Dpinger is a latency/loss monitor, not a decision maker. The concept of monitoring multiple targets, and deciding what if to do if a value for one or both of them reaches a certain threshold, belongs in a higher level. A good example of this higher level decision making is the already exiting latency/loss thresholds present in pfSense 2.3. Another example, and perhaps more direct to the point, is the action disable option offered in 2.4.
There are other less important issues, such as how do you report the combined results? Do you average them? Anything you do in terms of averaging hides information from the upper levels which in general is not a good idea. For example, knowing that the average latency between the two links jumped from 18ms to 80ms isn't sufficient. You really need to know which link is the source of the problem. There are other issues: If one of the sending interfaces is down, do you report an error or do you ignore it?; If one link has high latency and the other link has high loss, what do you report?
In short, the concept of monitoring multiple targets, and combining their results in a decision making process to determine whether a gateway is "down" is something that has to be implemented in pfSense itself. I'll be happy to look at this in pfSense as time permits, although I believe that Phil has already said that he was going to explore it.
Best,
Denny


FP Either proof of concept.

Neither optimized or abstracted, but just so you can see how it works and that it works.

Coverage increased (+0.003%) to 26.71% when pulling 726e29b25adb1ac044b0267a9923cdab0b685db7 on rjstires:either-component-poc into 522dbd026683ba404cd177eec1a4b3d66d8418c5 on linode:develop.


URL's of vrtnu.be give error 403: Forbidden

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2018.05.01. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2018.05.01

Before submitting an issue make sure you have:

[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones
[x] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows
[debug] System config: [u'-f', u'bestvideo[height<=?1080]+bestaudio/best', u'--mark-watched', u'-o', u'/Users/USER/Downloads/YT/%(title)s.%(ext)s', u'-n']
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-v', u'https://www.vrt.be/vrtnu/a-z/the-vietnam-war/1/the-vietnam-war-s1a1/']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.05.01
[debug] Python version 2.7.10 (CPython) - Darwin-17.5.0-x86_64-i386-64bit
[debug] exe versions: ffmpeg 3.2.4, ffprobe 3.2.4
[debug] Proxy map: {}
[VrtNU] Logging in
[VrtNU] Requesting a token
[VrtNU] the-vietnam-war-s1a1: Downloading webpage
[VrtNU] the-vietnam-war-s1a1: Downloading JSON metadata
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading JSON metadata
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading m3u8 information
WARNING: Failed to download m3u8 information: HTTP Error 403: Forbidden
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading MPD manifest
WARNING: Failed to download MPD manifest: HTTP Error 403: Forbidden
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading ISM manifest
WARNING: Failed to download ISM manifest: HTTP Error 403: Forbidden
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading f4m manifest
WARNING: Unable to download f4m manifest: HTTP Error 403: Forbidden
ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "youtube-dl/youtube_dl/YoutubeDL.py", line 789, in extract_info
ie_result = ie.extract(url)
File "youtube-dl/youtube_dl/extractor/common.py", line 440, in extract
ie_result = self._real_extract(url)
File "youtube-dl/youtube_dl/extractor/canvas.py", line 72, in _real_extract
self._sort_formats(formats)
File "youtube-dl/youtube_dl/extractor/common.py", line 1130, in _sort_formats
raise ExtractorError('No video formats found')
ExtractorError: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Description of your issue, suggested solution and other information
When trying to download a video from vrtnu.be the program gives error 403: Forbidden. A free account can be made on the homepage: vrtnu.be
It used to work a couple of months ago.

[VrtNU] the-vietnam-war-s1a1: Downloading webpage
[VrtNU] the-vietnam-war-s1a1: Downloading JSON metadata
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading JSON metadata
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading m3u8 information
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading MPD manifest
WARNING: [Canvas] Unknown MIME type application/mp4 in DASH manifest
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading ISM manifest
[Canvas] pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0: Downloading f4m manifest
[debug] Invoking downloader on 'https://ondemand-b.lwc.vrtcdn.be/content/vod/vid-282b4a61-5af4-495b-80dd-35f278c75ad0-CDN_6/vid-282b4a61-5af4-495b-80dd-35f278c75ad0-CDN_6_nodrm_56a05937-d2e7-485f-819a-7bde4422e4d2.ism/vid-282b4a61-5af4-495b-80dd-35f278c75ad0-CDN_6_nodrm_56a05937-d2e7-485f-819a-7bde4422e4d2-audio_nld=93375-video=1965416.m3u8'
[hlsnative] Downloading m3u8 manifest
[hlsnative] Total fragments: 558
[download] Destination: Déjà vu (1858-1961)-pbs-pub-3a1cfe7b-762a-4bcf-9c4b-52487a3e284d$vid-282b4a61-5af4-495b-80dd-35f278c75ad0.mp4
[download]   0.3% of ~386.77MiB at 251.95KiB/s ETA 35:01

Seeing the same issue with 2018.09.01, just like in
https://github.com/rg3/youtube-dl/issues/17083
There one cannot comment, here is the debug log:
[debug] System config: [u'--prefer-free-formats']
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'--username=PRIVATE', u'--password=PRIVATE', u'https://www.vrt.be/vrtnu/a-z/occupied/1/occupied-s1a1/', u'--verbose']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2018.09.01
[debug] Python version 2.7.15 (CPython) - Linux-4.17.19-200.fc28.x86_64-x86_64-with-fedora-28-Twenty_Eight
[debug] exe versions: ffmpeg 4.0.2, ffprobe 4.0.2, rtmpdump 2.4
[debug] Proxy map: {}
[VrtNU] Logging in
[VrtNU] Requesting a token
[VrtNU] occupied-s1a1: Downloading webpage
[VrtNU] occupied-s1a1: Downloading JSON metadata
[Canvas] pbs-pub-44664a3d-7b0a-4670-a7ea-3c7bcad3a848$vid-26cabcb9-77d8-4df1-9bc0-627a6cbf1351: Downloading JSON metadata
[Canvas] pbs-pub-44664a3d-7b0a-4670-a7ea-3c7bcad3a848$vid-26cabcb9-77d8-4df1-9bc0-627a6cbf1351: Downloading m3u8 information
WARNING: Failed to download m3u8 information: HTTP Error 403: Forbidden
[Canvas] pbs-pub-44664a3d-7b0a-4670-a7ea-3c7bcad3a848$vid-26cabcb9-77d8-4df1-9bc0-627a6cbf1351: Downloading MPD manifest
WARNING: Failed to download MPD manifest: HTTP Error 403: Forbidden
[Canvas] pbs-pub-44664a3d-7b0a-4670-a7ea-3c7bcad3a848$vid-26cabcb9-77d8-4df1-9bc0-627a6cbf1351: Downloading ISM manifest
WARNING: Failed to download ISM manifest: HTTP Error 403: Forbidden
[Canvas] pbs-pub-44664a3d-7b0a-4670-a7ea-3c7bcad3a848$vid-26cabcb9-77d8-4df1-9bc0-627a6cbf1351: Downloading f4m manifest
WARNING: Unable to download f4m manifest: HTTP Error 403: Forbidden
ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

No longer available.


Sort by Requirements

Describe the solution you'd like
Sorting alphabetical but by the requirements tab.
What system(s) do you want this feature to work with?
DnD5e - Fifth Edition System
Additional context

Note: Sorting might not always feel "natural" for class levels ("Paladin 10" will appear between "Paladin 1" and "Paladin 2").
I've written an issue to improve this (#123), but I likely won't resolve this any time soon.


[vis] x label is not shown

Make sure these boxes are checked before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if any
[x] I have reproduced the issue with at least the latest released version of superset
[x] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
latest master branch
Expected results
In line chart, when x label is entered, the x label should be shown in the chart
Actual results
The x label is not shown, neither instantly nor after re-querying, as the following picture shows:

Steps to reproduce

Caused by the code commented as "// Hack to adjust margins to accommodate long axis tick labels." in nvd3_vis.js.
The bottom margin in that part of code does not have room for the x axis text label.
@ascott @mistercrunch


Bumping the NPM version for testing.

Description
This change updates the SDK npm version from 0.0.1 to 0.0.2 to stay in step with what is published to NPM.
Motivation and Context
I had published another version of the package to NPM, but did not commit the change to package.json to the repository.
How Has This Been Tested?
This PR does now involve any code changes.
Checklist:

[x] I have added a Signed-off-by.
[x] I have either added documentation to cover my changes or this change requires no new documentation.
[x] I have either added unit tests to cover my changes or this change requires no new tests.
[x] I have run golint and have fixed valid warnings in code I have added or modified. This tool generates false positives so you may choose to ignore some warnings. The goal is clean, consistent, and readable code.

Signed-off-by: Anna D Derbakova<EMAIL_ADDRESS>

LGTM


Error while attempting to recover GTM

The error happens when restarting gtm after the pod was manually deleted.

Check if source image was modified.
Check if file is corrupt
How to recover?

PGXL:HELM: Starting as global transaction manager (GTM)
PGXL:HELM: Cluster node cannot be defined for type gtm, skipping
PGXL:HELM: GTM configuration found, init skipped.
PGXL:HELM: Set data folder permissions 0700
1:3349067520:2019-10-02 17:10:21.174 UTC -LOG:  Starting GTM server at (<IP_ADDRESS>:6666) -- control file /var/lib/postgresql/storage/data/gtm.control
LOCATION:  main, main.c:631
2:3349067520:2019-10-02 17:10:21.174 UTC -LOG:  Failed to read file version
LOCATION:  GTM_RestoreStart, main.c:2321
3:3349067520:2019-10-02 17:10:21.174 UTC -FATAL:  Unsupported format of "/var/lib/postgresql/storage/data/gtm.control" file
4:3349067520:2019-10-02 17:10:21.174 UTC -HINT:  If you're migrating from a very old XL release,then try to first start with an intermediate version. Else check your "/var/lib/postgresql/storage/data/gtm.control" contents
LOCATION:  GTM_RestoreTxnInfo, main.c:2370

Reproduce:

Start a persistant db.
Manually corrupt gtm.control
Restart the GTM pod.

Bug fix:

Added gtm recovery mode, thus allowing the gtm to restore its last known position.
Gtm will recover to last snapshot of gtm data in case of failure.


Tracker issue for 4.13 readiness

This issue is to track any Jira/BZ which are filed against OCP-4.13 and can block crc bundle creation. We will also incorporate changes which are only for release-4.13 ( like adding more capabilities)

We are seeing a consistent error when building the bundle for 4.13.0-ec.3 this is reproduced on every execution:
+ '[' 9 -lt 10 ']'
+ echo 'Retry 9/10 exited 1, retrying in 256 seconds...'
Retry 9/10 exited 1, retrying in 256 seconds...
+ sleep 256
+ all_pods_are_running_completed none
+ local ignoreNamespace=none
+ ./openshift-clients/linux/oc get pod --no-headers --all-namespaces '--field-selector=metadata.namespace!=none'
+ grep -v Running
+ grep -v Completed
openshift-kube-apiserver                           kube-apiserver-startup-monitor-crc-gj9lv-master-0         0/1   CrashLoopBackOff   7 (119s ago)   12m
+ exit=1
+ wait=512
+ count=10
+ '[' 10 -lt 10 ']'
+ echo 'Retry 10/10 exited 1, no more retries left.'
Retry 10/10 exited 1, no more retries left.

Everytime exact same pod errors with CrashLoopBackOff
Will try to debug to get the logs from the pod

There is 4.13.0-ec.4 bits now available, better to check with it if bundle creation still fails?

closing it since we released with 4.13 bundle.


Resolve Zksync subgraph issue on testnet

Describe the bug
These subgraph providers/deployments are not functional:

ZkSync -<PHONE_NUMBER>

To Reproduce
Steps to reproduce the behavior:

Remove the workarounds introduced - https://github.com/connext/monorepo/commit/a88d024a880fa2131856f3ddd1a66fc255bb5870
https://github.com/connext/monorepo/commit/05a40544f83b820dd9136f72606e65de8ec8da8b
https://github.com/connext/monorepo/commit/5a9824dea418a84623abbe72a0a3f8c451efc12f

Additional context
Redeploy working subgraphs, and reenable the chains.
Linea subgraph issue has been fixed by 2 prs.
https://github.com/connext/monorepo/pull/5044
https://github.com/connext/monorepo/pull/5059
Acceptance criteria:

[x] Restored commented code
[x] Restored packages/adapters/subgraph/.graphclientrc.yml in testnet and staging
[x] Redeployed subgraphs in both staging and testnet
[x] fast and slow paths for zksync are working

Done


DNSecure formula for brew?

Hello everyone; thank you for this superb application for iOS and macOS.
I wondered, is there any interest in maybe making available DNSecure not only via App Store, but also via brew?
Thank you very much in advance.

Thank you for your suggestion.
I don't have any plans to release DNSecure in Homebrew at this time, but if there is a good source of information about publishing a Mac Catalyst app in Homebrew, I will try to start working on it.

For applications like this, someone would write a Homebrew cask, which would simply download the application (the .app, normally in a DMG) from wherever you host it and copy it to /Applications. So all that would be required on your part is to make DNSecure available for download outside of the Mac App Store if you wanted it to be available through Homebrew.