Filer replication skipped a large range after connection down

Describe the bug
We are using "chain-style active-active" file replication to sync files between three nodes:
Server1 (<IP_ADDRESS>)   -> Server2 (<IP_ADDRESS>) -> Server3 (<IP_ADDRESS>) -> Server1
After setup, everything works well, Server2 and Server 3 are about 10 days behind Server 1 but they are catching up.
To do some maintenance work, I stopped Server1 for about 10mins and restart. After that, the replication on Server2 seems to be disrupted. Instead of resuming the replication form 06-01, the progress jump to 06-09(today)
System Setup

OS version Ubuntu 20.04
output of weed version version 30GB 2.49 42fb03a linux amd64
if using filer, show the content of filer.toml

[leveldb3]
enabled = true
dir = "/data/filerldb3"

Logs on Server2
{"log":"E0609 03:47:20     1 filer_sync.go:113] sync from <IP_ADDRESS>:8888 to <IP_ADDRESS>:8888: GetFilerConfiguration <IP_ADDRESS>:8888: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:18888: connect: connection refused\"\n","stream":"stderr","time":"2021-06-09T03:47:20.998525336Z"}
{"log":"E0609 03:47:21     1 filer_sync.go:101] sync from <IP_ADDRESS>:8888 to <IP_ADDRESS>:8888: GetFilerConfiguration <IP_ADDRESS>:8888: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:18888: connect: connection refused\"\n","stream":"stderr","time":"2021-06-09T03:47:21.80143655Z"}
{"log":"E0609 03:47:23     1 filer_sync.go:113] sync from <IP_ADDRESS>:8888 to <IP_ADDRESS>:8888: GetFilerConfiguration <IP_ADDRESS>:8888: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:18888: connect: connection refused\"\n","stream":"stderr","time":"2021-06-09T03:47:23.167495816Z"}
{"log":"E0609 03:47:23     1 filer_sync.go:101] sync from <IP_ADDRESS>:8888 to <IP_ADDRESS>:8888: GetFilerConfiguration <IP_ADDRESS>:8888: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:18888: connect: connection refused\"\n","stream":"stderr","time":"2021-06-09T03:47:23.57123912Z"}
{"log":"E0609 03:47:25     1 filer_sync.go:113] sync from <IP_ADDRESS>:8888 to <IP_ADDRESS>:8888: GetFilerConfiguration <IP_ADDRESS>:8888: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:18888: connect: connection refused\"\n","stream":"stderr","time":"2021-06-09T03:47:25.336135075Z"}
{"log":"E0609 03:47:25     1 filer_sync.go:101] sync from <IP_ADDRESS>:8888 to <IP_ADDRESS>:8888: GetFilerConfiguration <IP_ADDRESS>:8888: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:18888: connect: connection refused\"\n","stream":"stderr","time":"2021-06-09T03:47:25.33620766Z"}
{"log":"I0609 03:47:27     1 filer_sync.go:146] start sync <IP_ADDRESS>:8888(1777921198) =\u003e <IP_ADDRESS>:8888(-214467355) from 2021-06-01 14:49:06.631752243 +0000 UTC(1622558946631752243)\n","stream":"stderr","time":"2021-06-09T03:47:27.202498144Z"}
{"log":"I0609 03:47:27     1 filer_sync.go:146] start sync <IP_ADDRESS>:8888(-214467355) =\u003e <IP_ADDRESS>:8888(1777921198) from 2021-06-09 03:46:56.886025642 +0000 UTC(1623210416886025642)\n","stream":"stderr","time":"2021-06-09T03:47:27.546940687Z"}
{"log":"I0609 03:47:27     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-09 03:46:56.886025642 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-09T03:47:27.639249818Z"}
{"log":"I0609 03:47:30     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-09 03:47:30.423977505 +0000 UTC 2.67/sec\n","stream":"stderr","time":"2021-06-09T03:47:30.667002413Z"}
{"log":"W0609 03:47:30     1 filer_sink.go:123] replicate entry chunks /store_proneval/11e1939e-4907-4d68-826f-b869588ffa2b.m4a: copy : read part : LookupFileId volume id : rpc error: code = Unknown desc = strconv.Atoi: parsing \"\": invalid syntax\n","stream":"stderr","time":"2021-06-09T03:47:30.852518621Z"}
{"log":"I0609 03:47:30     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-09 03:46:50.295510549 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-09T03:47:30.853899371Z"}
{"log":"W0609 03:47:32     1 filer_sink.go:123] replicate entry chunks /store_proneval/342bc811-0ca6-45aa-bdee-bff3798fa9d3.m4a: copy : read part : LookupFileId volume id : rpc error: code = Unknown desc = strconv.Atoi: parsing \"\": invalid syntax\n","stream":"stderr","time":"2021-06-09T03:47:32.383497494Z"}
{"log":"W0609 03:47:33     1 filer_sink.go:123] replicate entry chunks /store_proneval/4759c2f0-6c5f-4e96-ab2a-356ba2274234.m4a: copy : read part : LookupFileId volume id : rpc error: code = Unknown desc = strconv.Atoi: parsing \"\": invalid syntax\n","stream":"stderr","time":"2021-06-09T03:47:33.433361039Z"}
{"log":"I0609 03:47:35     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-09 03:47:35.265000413 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-09T03:47:35.292595328Z"}

Looks fine to me. Do you just "think" it is a problem?

Thank you for your reply.
From the log, you may notice time jump immediately from  <IP_ADDRESS>:8888(-214467355) from 2021-06-01 14:49:06.631752243 to progressed to 2021-06-09 03:46:50.295510549 +0000 UTC
I "think" it is a problem because I've been importing a large number of small files to Server1 continuously these days and it shouldn't be that fast.
To further verify it, a simple ls shows a large difference.

Yes, they are.
But if you continue following the log, you may see this line, which is a problem IMO
sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-09 03:46:50.295510549 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-09T03:47:30.853899371Z"}

The related client side code is in filer_sync.go. You can also use weed filer.meta.tail to see what meta data is received.
The server side code is here: https://github.com/chrislusf/seaweedfs/blob/c42b95c596f762dcca2bc9c7e7a918ab8ca8b206/weed/server/filer_grpc_server_sub_meta.go#L37
I suspect there might be some error here so the time is reset to now in line 43.

Thank you for your detailed instruction. I'll take some time to look into that code.

Hi, after running replication for serval weeks, I got the following result:
(I do replication over WAN, so even there is no major connection problem during 2 weeks, some packet loss should be expected.)

This problem does exist but hard to reproduce. It occurs 3 times during 2 weeks.
It also exists in a 2 node master-slave setup
There is an error log from CreateEntry just before the problem. (notice the time jump from 06-14 to 06-22

{"log":"I0622 20:01:20     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:27.971062888 +0000 UTC 12.33/sec\n","stream":"stderr","time":"2021-06-22T20:01:20.938702356Z"}
{"log":"I0622 20:01:23     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:28.193956914 +0000 UTC 12.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:23.988718173Z"}
{"log":"I0622 20:01:27     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:28.39445247 +0000 UTC 13.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:27.04946481Z"}
{"log":"W0622 20:01:29     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/4633483d-381a-11e8-80ed-000c29055b24: copy 19,92d5d11f76d10f: read part 19,92d5d11f76d10f: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/4ce51244-381a-11e8-972e-000c29ffef9b: copy 73,92d5d28617f978: read part 73,92d5d28617f978: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/4633483e-381a-11e8-80ed-000c29055b24: copy 72,92d5d3655510b3: read part 72,92d5d3655510b3: LookupFileId locate volume id$
{"log":"I0622 20:01:30     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:28.61849009 +0000 UTC 13.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:30.102590704Z"}
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/58961097-381a-11e8-ad34-000c29e6fad9: copy 17,92d5d481f48d77: read part 17,92d5d481f48d77: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/58961098-381a-11e8-ad34-000c29e6fad9: copy 77,92d5d55b59f42c: read part 77,92d5d55b59f42c: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/58961099-381a-11e8-ad34-000c29e6fad9: copy 72,92d5d655a3d9f7: read part 72,92d5d655a3d9f7: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/4e8f9a85-381a-11e8-80ed-000c29055b24: copy 15,92d5d72ce248af: read part 15,92d5d72ce248af: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/4e8f9a86-381a-11e8-80ed-000c29055b24: copy 74,92d5d8ecab3699: read part 74,92d5d8ecab3699: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/66d45c6b-381a-11e8-ad34-000c29e6fad9: copy 21,92d5d97d8c9cf9: read part 21,92d5d97d8c9cf9: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/66d45c75-381a-11e8-ad34-000c29e6fad9: copy 20,92d5dad4ea7264: read part 20,92d5dad4ea7264: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/5e8783b7-381a-11e8-80ed-000c29055b24: copy 73,92d5dbd5186941: read part 73,92d5dbd5186941: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/66d45c76-381a-11e8-ad34-000c29e6fad9: copy 73,92d5dcf9c57d83: read part 73,92d5dcf9c57d83: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/6eeee983-381a-11e8-ad34-000c29e6fad9: copy 73,92d5deb9dc3bd5: read part 73,92d5deb9dc3bd5: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/65137c33-381a-11e8-80ed-000c29055b24: copy 19,92d5dfba30e1a3: read part 19,92d5dfba30e1a3: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/6e2648b4-381a-11e8-972e-000c29ffef9b: copy 73,92d5e01d8e69b4: read part 73,92d5e01d8e69b4: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/76e1a2a7-381a-11e8-ad34-000c29e6fad9: copy 71,92d5e1958076fa: read part 71,92d5e1958076fa: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/780eec7b-381a-11e8-80ed-000c29055b24: copy 76,92d5e237800742: read part 76,92d5e237800742: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/7e4f82ca-381a-11e8-80ed-000c29055b24: copy 16,92d5e389990f59: read part 16,92d5e389990f59: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/84fe4583-381a-11e8-80ed-000c29055b24: copy 17,92d5e4c4237053: read part 17,92d5e4c4237053: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/84fe4584-381a-11e8-80ed-000c29055b24: copy 73,92d5e59617180b: read part 73,92d5e59617180b: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/8b7b7073-381a-11e8-80ed-000c29055b24: copy 73,92d5e689650cb7: read part 73,92d5e689650cb7: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/8b7b7075-381a-11e8-80ed-000c29055b24: copy 77,92d5e79bde5629: read part 77,92d5e79bde5629: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/93e641bc-381a-11e8-80ed-000c29055b24: copy 74,92d5e8714fce75: read part 74,92d5e8714fce75: LookupFileId locate volume id$
{"log":"W0622 20:01:30     1 filer_sink.go:123] replicate entry chunks /buckets/main/store_user/avatar/9b8490b5-381a-11e8-972e-000c29ffef9b: copy 20,92d5e922025220: read part 20,92d5e922025220: LookupFileId locate volume id$
{"log":"I0622 20:01:33     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:28.898627793 +0000 UTC 15.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:33.10533501Z"}
{"log":"I0622 20:01:36     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.132119132 +0000 UTC 11.33/sec\n","stream":"stderr","time":"2021-06-22T20:01:36.148999629Z"}
{"log":"I0622 20:01:39     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.424563092 +0000 UTC 13.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:39.180197311Z"}
{"log":"I0622 20:01:42     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.66886952 +0000 UTC 12.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:42.196555904Z"}
{"log":"I0622 20:01:45     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.966279305 +0000 UTC 12.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:45.294549473Z"}
{"log":"I0622 20:01:48     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:30.514536129 +0000 UTC 11.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:48.349726312Z"}
{"log":"I0622 20:01:51     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:30.778599377 +0000 UTC 12.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:51.403651319Z"}
{"log":"I0622 20:01:33     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:28.898627793 +0000 UTC 15.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:33.10533501Z"}
{"log":"I0622 20:01:36     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.132119132 +0000 UTC 11.33/sec\n","stream":"stderr","time":"2021-06-22T20:01:36.148999629Z"}
{"log":"I0622 20:01:39     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.424563092 +0000 UTC 13.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:39.180197311Z"}
{"log":"I0622 20:01:42     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.66886952 +0000 UTC 12.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:42.196555904Z"}
{"log":"I0622 20:01:45     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:29.966279305 +0000 UTC 12.67/sec\n","stream":"stderr","time":"2021-06-22T20:01:45.294549473Z"}
{"log":"I0622 20:01:48     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:30.514536129 +0000 UTC 11.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:48.349726312Z"}
{"log":"I0622 20:01:51     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:30.778599377 +0000 UTC 12.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:51.403651319Z"}
{"log":"I0622 20:01:54     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:31.051220806 +0000 UTC 12.00/sec\n","stream":"stderr","time":"2021-06-22T20:01:54.408213554Z"}
{"log":"I0622 20:01:57     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:31.388685577 +0000 UTC 12.33/sec\n","stream":"stderr","time":"2021-06-22T20:01:57.484476589Z"}
{"log":"I0622 20:02:00     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:31.687129859 +0000 UTC 13.00/sec\n","stream":"stderr","time":"2021-06-22T20:02:00.555421851Z"}
{"log":"I0622 20:02:03     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:31.947859213 +0000 UTC 12.67/sec\n","stream":"stderr","time":"2021-06-22T20:02:03.638470284Z"}
{"log":"I0622 20:02:06     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:32.122279455 +0000 UTC 12.33/sec\n","stream":"stderr","time":"2021-06-22T20:02:06.669974673Z"}
{"log":"I0622 20:02:09     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:32.473456209 +0000 UTC 13.00/sec\n","stream":"stderr","time":"2021-06-22T20:02:09.6762414Z"}
{"log":"I0622 20:02:12     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:32.735584748 +0000 UTC 12.33/sec\n","stream":"stderr","time":"2021-06-22T20:02:12.723356878Z"}
{"log":"I0622 20:02:15     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:33.020037375 +0000 UTC 12.33/sec\n","stream":"stderr","time":"2021-06-22T20:02:15.767928557Z"}
{"log":"I0622 20:02:18     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:33.234449423 +0000 UTC 12.67/sec\n","stream":"stderr","time":"2021-06-22T20:02:18.772028939Z"}
{"log":"I0622 20:02:21     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:33.437231285 +0000 UTC 13.00/sec\n","stream":"stderr","time":"2021-06-22T20:02:21.849777397Z"}
{"log":"I0622 20:02:24     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:33.758019451 +0000 UTC 12.33/sec\n","stream":"stderr","time":"2021-06-22T20:02:24.875834136Z"}
{"log":"I0622 20:02:28     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-22 20:00:57.263114027 +0000 UTC 11.00/sec\n","stream":"stderr","time":"2021-06-22T20:02:28.295886029Z"}
{"log":"I0622 20:02:32     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-22 20:01:02.51882558 +0000 UTC 1.00/sec\n","stream":"stderr","time":"2021-06-22T20:02:32.732195986Z"}
{"log":"I0622 20:02:43     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-22 20:01:13.584572906 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-22T20:02:43.757203546Z"}
{"log":"I0622 20:02:48     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-22 20:01:17.766157341 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-22T20:02:48.122585628Z"}
{"log":"I0622 20:02:56     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-22 20:01:25.954372074 +0000 UTC 0.67/sec\n","stream":"stderr","time":"2021-06-22T20:02:56.160784386Z"}
{"log":"I0622 20:03:11     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 =\u003e <IP_ADDRESS>:8888 progressed to 2021-06-22 20:01:41.732070339 +0000 UTC 0.33/sec\n","stream":"stderr","time":"2021-06-22T20:03:11.913778045Z"}

A temporliy fix is to use setOffset to reset offsetTsNs ,After that, replication 'jumps back' and works normally.

I0624 05:43:28     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:06:57.741858372 +0000 UTC 183.00/sec
I0624 05:43:31     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:01.607128862 +0000 UTC 156.00/sec
I0624 05:43:34     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:05.714844743 +0000 UTC 170.67/sec
I0624 05:43:37     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:10.064366139 +0000 UTC 194.33/sec
I0624 05:43:40     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:34.0756201 +0000 UTC 1037.67/sec
I0624 05:43:43     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:34.282255936 +0000 UTC 10.67/sec
I0624 05:43:46     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:34.530498062 +0000 UTC 10.67/sec
I0624 05:43:49     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:34.890042509 +0000 UTC 11.00/sec
I0624 05:43:52     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:35.175039668 +0000 UTC 11.67/sec
I0624 05:43:55     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:35.448225703 +0000 UTC 11.33/sec
I0624 05:43:58     1 filer_sync.go:200] sync <IP_ADDRESS>:8888 => <IP_ADDRESS>:8888 progressed to 2021-06-14 15:07:35.668907359 +0000 UTC 10.33/sec

I think this problem may be caused by the server site fast skip read error, but it's hard for me to locate the exact position.
I just wondering if you can use rapid-fail instead of continuing reading after the error occurs?

I will try to debug this. Are your writes busier or bursty, and sync could not catch up? How fast are the writes?

Thank you for your reply. My debug environment is quite simple:

2 node are connected using VPN over the Internet
several million small files (2Tb) are imported on node 1 (the import process takes 2 days to complete)
start replication between two nodes
this is a cross-region replication, the speed is about 10-15 files/sec, so it'll take quite a long time to catch up.
During replication, node 1 accepts normal workload (about several hundred new files added per hour), there is no write on node 2.

The problem usually happens after 2 or 3 days, so I cannot find out a way to debug it.

Added a change that should solve your problem. Please help to verify.

Thank you, I'll give that a try and get back to you later.


My code currently breaks when I do have the knitr-cache still in there

Not sure if it was anything I added in my last two commits, or what Chris did in my latest merge. It breaks around   main.tv.selex.uncertainty    in main-figures.rnw. Chris does have a warning in the comments there, so maybe something needs tweaking.      I have to leave now so flagging it to look at later/tomrrow.

Just make sure no source("all.r"), answering no to all the questions, then save.image(). I do this every time I fetch/merge, as the R code is always changing. I have just fetched/merged everyone and the document builds properly.

Now works. Merged Chris's latest (which didn't fix it), and restarted both my R windows (one where I do source("all.r") and one where I run knit(..)  ) and that worked. Not quite sure why, I may have redefined something somewhere, and maybe shouldn't keep R windows open for days on end without closing them!


Updated reference to tableau output dir in loader to align poller and…

Updated reference to tableau output dir in loader to align poller and API approaches. Updated postman collection to align table request with Splunk request

Good catch @richardmckinley please double check if the tests are still working - mainly the unit-test-loader-platform-metrics-router.xml where the Tableau input payload is mocked

The unit test continued to pass. The var loaderDetails.outputDir is Null, but the write file operation is mocked so no exception occurs.
I've added an additional assertion to validate the file write path


⚠ ClamAV has degraded performance

In 584b78f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 57 ms

Resolved: ClamAV performance has improved in 933e67b after 540 days, 1 hour, 26 minutes.


Table.TransformColumns - Missing description of 3rd transformation config param

Hello,
The docs for Table.TransformColumns describe parameter transformOptions as having the format "{ column name, transformation }". No mention is made that the transformation spec list is allowed to have an optional third item that specifies the type output by the transformation -- e.g. "{ column name, transformation, type }".
Could this page be updated to reflect this optional third item?
Thank you!

Example of providing this additional config param item:
let
    Data = #table({"X"}, {{123}}),
    // with optional third item *not* provided
    // Transformed = Table.TransformColumns(Data,  {"X", each _ * 2})
    // with optional third item provided - notice how providing this results in the column's icon and formatting changing in Query Editor
    Transformed = Table.TransformColumns(Data,  {"X", each _ * 2, Currency.Type})
in
    Transformed

Please ignore (I'm using bot automation to add tags). #please-open

Hi @bgribaudo
Thanks for the input. The Table.TransformColumns article has been updated with new examples, the fourth of which contains the third optional item.

Thank you, @DougKlopfenstein!


Game crash when breaking double oak slab

crash-2020-03-07_14.07.46-client.txt
A spruce/oak combo didnt crash. Using an axe didnt crash, but pickaxe did.

Should be fixed in the latest version


chore(docs): update material-spec

物料协议规范 - <IP_ADDRESS>基础信息，这里应该为keywords

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

感谢PR，麻烦指向develop分支哈


What fields are editable on payment execute call?

Description
It is stated in the API documentation https://developer.paypal.com/docs/api/payments/#payment_execute
that the Request body transaction array contains the 'cart_base' object, and "For update and execute payment calls, the transactions object accepts only the amount object."
Yet I have managed to add 'invoice_number' during the payment execution, for example:
        {
          payer_id: 'some-payer-id',
          transactions: [{
            amount: {
              currency: 'USD',
              total: '0.99'
            },
            custom: `some-custom-field`,
            invoice_number: 'some-invoice-number'
          }]
        }

After executing the payment with the above mentioned parameters, I can see both the 'invoice_number' and 'custom' fields on payment execution response,  but only 'invoice_number' gets actually attached to the transaction (and I can see it in the Transaction details in sandbox business account), whereas the 'custom' field seem to be ignored without any error whatsoever. Both are attached to transactions if added during payment creation (not execution).
Questions

Is the official documentation misleading and should it state instead "..accepts amount object and invoice_number"?
What fields are indeed can be added/amended during payment execution?

@trainerbill can you help answer this one?

@vblagomir I have recreated your issue here:
https://github.com/paypal/PayPal-REST-API-issues/issues/245
Since it is with our REST api product.


DiffusionIntegrator using MatrixCoefficient on 2D surface in 3D mesh

This is to address an issue reported in https://github.com/mfem/mfem/issues/2111.
When a mesh is 2D defined in 3D space, diffusion coefficient in matrix form is supposed to be spaceDim x spaceDim.
However, dshape, to which grad v * c is stored, has a shape of nd x dim (not nd x spaceDim).  With MFEM_DEBUG flag, the size
mismatch is captured. Without the flag, the data is partially lost and it produces a strange result. Figure below compares  the result of solving div-grad-phi = 1 with essential BCs when an identity matrix is used for coefficient (left: before fix and right: after fix). If the coefficient is scalar one, the result is the same as the right one, as it is expected.

Hi @sshiraiwa, sorry about this problem and thank you for the fix.
We never updated DiffusionIntegrator properly for matrix coefficients on surfaces -- we added support for scalar coefficients and ignored the other cases.
It looks like other methods in DiffusionIntegrator need to be fixed too, e.g. AssembleElementVector, ComputeElementFlux. Also, it looks like some of the methods do not support diagonal coefficients properly.

Thank you @sshiraiwa. When this is ready, can you please label it ready-for-review?

I added a simple unit test based on example 1 but with a matrix coefficient and a fixed mesh. If anyone wants to see what the unit test is computing you can compile and run examples/test_surf_diff.cpp which is the same thing except that it has command line options. We can turn this into a proper example if that would be useful or we can just remove this file from the examples directory before merging this PR.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@ed5604e). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2125   +/-   ##
=========================================
  Coverage          ?   61.43%
=========================================
  Files             ?      395
  Lines             ?   114823
  Branches          ?        0
=========================================
  Hits              ?    70538
  Misses            ?    44285
  Partials          ?        0

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 ed5604e...62668b0. Read the comment docs.

My fault...I added bunch of wrong files which are not supposed to be added here.
Trying to fix them....

Superseded by https://github.com/mfem/mfem/pull/2137


Ability to compare 2 packages, not just 2 versions

OK, here's a curve ball... :wink:
Following the pattern of xunit 2.0, Xbehave 2.0 is now a meta-package containing nothing but a dependency on Xbehave.Core and xunit, where Xbehave.Core is the package containing the actual assemblies. The reason for this is that xunit is a meta-package containing deps on xunit.core and xunit.assert, allowing users to install just xunit.core when they want to use another assertion library. Similarly, users can just install Xbehave.Core which only takes a dep on xunit.core.
So the bottom line is that I'd like to be able to compare Xbehave 1.1.0 with Xbehave.Core 2.0.0-rc002-build543.
I can hear the groans already :stuck_out_tongue_closed_eyes:.

We have similar needs since nsb.interfaces and nsb.core v4 is replaced by nsb.core only in v5

On 26 Apr 2015, at 11:06, Adam Ralph<EMAIL_ADDRESS>wrote:
OK, here's a curve ball...
Following the pattern of xunit 2.0, Xbehave 2.0 is now a meta-package containing nothing but a dependency on Xbehave.Core and xunit, where Xbehave.Core is the package containing the actual assemblies. The reason for this is that xunit is a meta-package containing deps on xunit.core and xunit.assert, allowing users to install just xunit.core when they want to use another assertion library. Similarly, users can just install Xbehave.Core which only takes a dep on xunit.core.
So the bottom line is that I'd like to be able to compare Xbehave 1.1.0 with Xbehave.Core 2.0.0-rc002-build543.
I can hear the groans already .
—
Reply to this email directly or view it on GitHub.

yeah when i created this http://docs.particular.net/nservicebus/upgrades/4to5diff i fudged it.
bottom line is we need metadata in the nuget to achieve this

Ah, great. So not such an edge case then...


Almere endpoint no longer reachable

Description
The Almere endpoint is down
ToDo
Either

Make the Almere endpoint accessible again
Search for a new open endpoint with write functionality enabled

Gerard did a reinstall of the Almere server, but is currently not able to get LinkDale up and running again. @GerwinBosch can you have a look and see what the problem is?

@erwinfolmer the original paths used for sparql (which allowed CORS) are no longer available http://almere.pilod.nl/sparql

Tested locally with using http://virtuoso.almere.pilod.nl/sparql but I am running into CORS errors

This means that the CORS headers haven't been re-enabled with the reinstall, so Gerard Persoon needs to be notified. It's easy to enable in the conductor.

Fixed last week

can't reach the endpoint again


Setting a navigation property to null doesn't set the FK to null

The relationship is configured like this:
modelBuilder.Entity<Post>().HasOne(t => t.Blog).WithMany("PostBlogCollection").HasForeignKey("Blog_Seqnr").OnDelete(DeleteBehavior.Restrict);
The following code:
var post = ctx.Posts.First();
var blog = ctx.Blogs.Where(z => z != post.Blog).First();
Console.WriteLine(post.Blog_Seqnr);
post.Blog = blog;
Console.WriteLine(post.Blog_Seqnr);
post.Blog = null;
Console.WriteLine(post.Blog_Seqnr);

Outputs "1 2 2". I expected the output to be "1 2 ".
It was working as expected in EFCore 1.1.2, the bug only appears in EFCore 2.1.

@Wain123 This is a breaking change we made in 2.0. Previously, "Restrict" meant validate the constraint (rather than setting null or cascading) in the database, but the EF change tracking behavior was still SetNull. Now there is a new behavior--ClientSetNull--for this, and Restrict means never null out FKs. ClientSetNull is the new default for optional relationships, while Restrict used to be the default, which means the behavior is the same unless Restrict is set explicitly for an optional relationship--your case above.
Full details here: https://docs.microsoft.com/en-us/ef/core/saving/cascade-delete


:fix: Replace unstable srtool with subwasm to calculate Circuit Parachain hash

Summary
Replace unstable srtool with subwasm to calculate Circuit Parachain hash
Checklist

[ ] insert any notable changes, in order of commit

Please check that your PR completes the requirements as follows

[ ] Tests have been added for bug fixes/features
[ ] Acceptance criteria from the issue has been completed

overridden by https://github.com/t3rn/t3rn/pull/399/files


fix incomplete progress bar when refresh_rate > num batches

What does this PR do?
Fixes #4565
Fixes edge cases with num batches not being divisibale by refresh rate, leading to an incomplete the progress bar.
Tests here fail on master.
Example:
train_batches: 5, refresh_rate: 3
(master)
Epoch 0:  60%|██████    | 3/5 [00:00<00:00, 111.11it/s, loss=0.131]
(this branch)
Epoch 0: 100%|██████████| 5/5 [00:00<00:00, 125.00it/s, loss=0.124]

this bugfix is a visual fix, I need to figure out how to write the unit test. somehow counting the number of times update is called.

@awaelchli would it be idea for testing to subclass ProgressBar and then decorate the update method? Something like:
class MyProgressBar(ProgressBar):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._update_counter = 0

    def init_train_tqdm(self):
        bar = super().init_train_tqdm()
        bar.update = self.counter_wrap(bar.update)
        return bar

    def counter_wrap(self, update):
        def wrap(*args, **kwargs):
            self._update_counter += 1
            return update(*args, **kwargs)
        return wrap

@awaelchli can you resolve the conflict?

@ananyahjha93 resolved, thanks!


Method not supported when SAML auth is configured

Description
I am trying to configure Structurizer On-Premise with Azure AD SAML Authentication, but when Azure is redirecting to the application it returns 405.
I am using latest docker build (3038).
Steps to reproduce
Configure  SAMl Single Sing-on in Azure AD as described here https://structurizr.com/share/18571/documentation#saml-20
Screenshot
Azure AD

Structurizer configuration

Redirect result

Code sample
No response
Configuration
No response
Severity
Minor
Priority
Medium
Resolution
I have no budget, please fix this for free
More information
No response

we are running into the same issue. Our configuration looks pretty similar to the OP's, we are also getting a 405 Method not allowed on the /saml/sso endpoint. In the logs we see the following error:
DefaultHandlerExceptionResolver - Resolved [org.springframework.web.HttpRequestMethodNotSupportedException: Request method 'POST' not supported

but for completeness sake:

our Structurizr app is running in an Azure Appservice
version 3040
we created an AAD Enterprise Application with return url {my-app-name}/saml/sso (where {my-app-name} is a placeholder for our real app name of course)
added the structurizr.properties and saml-idp-metadata.xml files

structurizr.properties:
structurizr.authentication=saml
structurizr.url=https://{my-app-name}.azurewebsites.net
structurizr.saml.entityId={client id of the AAD Enterprise Application}

Your case may have been already solved by issue #8.
You have to adjust structurizr.saml.maxAuthenticationAge property to higher (90 days ?) than the default value (2 hours): https://structurizr.com/share/18571/documentation#max-authentication-age

Same problem wit keycloak here. Already tried to change the max-authentication-age to 8h, 24h, and 90 days, and didn't worked.

Same on my side, KC+structurizr

Somebody on the Slack group (onpremises channel) has mentioned that the instructions for Keycloak are out of date, and posted an updated screenshot. You may want to jump on there and take a look.

Alternatively, you may want to try forcing authentication -> https://structurizr.com/share/18571/documentation#force-authentication (although this seems to be related to issues with Azure AD).

Thank you for the screenshot, i fixed it now :)
Issue (for me) was that i disabled "sign document" function. Just in case if anyone need, sending my KC screenshot of the working configuration:

That's great, thanks. Would you consider sending a PR for the docs please?
https://github.com/structurizr/onpremises/blob/main/docs/docs/04-authentication.md#keycloak

Done, https://github.com/structurizr/onpremises/pull/47

Have similar problem when integrating with Okta. I receive on server logs
DefaultHandlerExceptionResolver - Resolved [org.springframework.web.HttpRequestMethodNotSupportedException: Request method 'POST' not supported].
This is on the returning from already authenticated user on /saml/SSO
Did anyone resolved that problem? why structurizr is not accepting POST on that url.

In my case it was disabled signing on the request, please check your settings.

In my case it was disabled signing on the request, please check your settings

Thanks for info. I checked and SAML Signed Request is disabled. Anyway guys who managed OKTA said they cannot enable it, possibly there is a need for cert?

What cert then is required? or maybe there is possibility to disable on structurizr this signing?

Thanks @samm-git that was also a problem on my side. Once I enabled SAML signed request then it started to work. BTW, to do that I had to export cert from jks existing on repo for structurizr onprem and upload it to Okta so then it was possible to enable it.

Hi people, i face the same problem with Azure AD and I resolved creating group claim on Enterprise Application:

Closing since the OP hasn't responded, so I'm assuming this is resolved ... please open new issues/discussions as needed.


(maint) Update GCE metadata endpoint

Facter 2 will soon be updated to use the non-deprecated GCE metadata endpoint
see FACT-2102. Update puppet's webmock stub to accept both.

This targets 6.4.x, because that's when the webmock and vcr stubbing were rewritten.

CLA signed by all contributors.

Looks like this is just for test mocks, but just to be clear, after April 2020 any requests to v0.1 or v1beta1 will fail with a 4xx error.
Thanks for taking this on @joshcooper. Very much appreciated!


Rolling engine produces analyzer warnings in IntelliJ

Rolling the engine to https://github.com/flutter/engine/commit/eb467a8b852e607dbf5dc0cab662e89b1495c516 causes various analyzer errors when opening packages/flutter in IntelliJ (see below). Two commits before (https://github.com/flutter/engine/commit/2062ca14ec55934ac27b6a1e69031c44daae1e54) these errors are not present. The commit in between (https://github.com/flutter/engine/commit/66fbebaca3a7bae3fe957c4c829009330a412082) is probably the culprit, but not all artifacts exist for it in cloud storage. Therefore, I wasn't able to confirm that that's actually the culprit.
There are 117 analyzer errors. None of them seem correct. I am including the first few below:
error: The switch case expression type 'AnimationStatus' can't override the == operator. (case_expression_type_implements_equals at [flutter] lib/src/animation/animation.dart:104)
error: The switch case expression type 'SemanticsAction' can't override the == operator. (case_expression_type_implements_equals at [flutter] lib/src/cupertino/slider.dart:338)
error: The argument type 'ValueChanged(bool) → void' can't be assigned to the parameter type 'Object'. (argument_type_not_assignable at [flutter] lib/src/cupertino/switch.dart:248)
error: The switch case expression type 'AnimationStatus' can't override the == operator. (case_expression_type_implements_equals at [flutter] lib/src/cupertino/switch.dart:271)
error: The argument type 'DebugPrintCallback(String, {wrapWidth: int}) → void' can't be assigned to the parameter type 'Object'. (argument_type_not_assignable at [flutter] lib/src/foundation/debug.dart:24)

IntelliJ also complains that the Analyzer crashed:
Analyzer Feedback from IntelliJ
Version information

IDEA IC-171.4694.70
1.25.0-dev.4.0
IC-171.4694.70, JRE 1.8.0_112-release-736-b21x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.12.5 unknown, screens 1920x1200

Exception
Please append the contents of:
file:///private/var/folders/t2/r2h8ytq53_x45hn80bhpb0ww0044f6/T/report2.txt
Dart analysis server, SDK version 1.25.0-dev.4.0, server version 1.18.1, error: Analysis failed: /Users/goderbauer/dev/flutter/packages/flutter/lib/src/animation/animations.dart context: exception_20170706_165647_825
NoSuchMethodError: The getter 'superclass' was called on null.
Receiver: null
Tried calling: superclass
#0      Object._noSuchMethod (dart:core-patch/object_patch.dart:43)
#1      Object.noSuchMethod (dart:core-patch/object_patch.dart:47)
#2      _OverrideChecker._extendsErrorLocation (package:analyzer/src/task/strong/checker.dart:1599)
#3      _OverrideChecker._checkInterfacesOverrides (package:analyzer/src/task/strong/checker.dart:1439)
#4      _OverrideChecker._checkInterfacesOverrides (package:analyzer/src/task/strong/checker.dart:1442)
#5      _OverrideChecker._checkAllInterfaceOverrides (package:analyzer/src/task/strong/checker.dart:1286)
#6      _OverrideChecker.check (package:analyzer/src/task/strong/checker.dart:1251)
#7      CodeChecker.visitClassDeclaration (package:analyzer/src/task/strong/checker.dart:295)
#8      ClassDeclarationImpl.accept (package:analyzer/src/dart/ast/ast.dart:1906)
#9      NodeListImpl.accept (package:analyzer/src/dart/ast/ast.dart:7990)
#10     CompilationUnitImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:2502)
#11     CodeChecker.visitCompilationUnit (package:analyzer/src/task/strong/checker.dart:314)
#12     LibraryAnalyzer._computeVerifyErrors (package:analyzer/src/dart/analysis/library_analyzer.dart:277)

/cc @rmacnak-google as author of the commits in question
/cc @devoncarew

I also filed the analyzer crash separately: https://github.com/dart-lang/sdk/issues/30097

flutter analyze --flutter-repo --watch exposes the same errors.
flutter analyze --flutter-repo runs without issues.

flutter analyze --flutter-repo --watch exposes the same errors.

This command uses the analysis server to generate errors -

flutter analyze --flutter-repo runs without issues.

And this command uses the dartanalyzer cli tool.

To make sure that this is not just a problem with my local system, I created a PR that rolls the engine. Travis is as unhappy as my system: https://github.com/flutter/flutter/pull/11106.

I did some bisecting. The breakage starts with https://github.com/dart-lang/sdk/commit/62bc61b367b14bfe3a265eaddcce0574e0059985.
@lrhn, @brianwilkerson, @floitsch: Anything we need to do in Flutter-land to adopt to that change?

/cc @lrhn

Change in question has been reverted: https://codereview.chromium.org/2968413002. I verified that Flutter is working again as expected now.


simple-app-build-local example builds the same image twice

What steps did you take:
kbld -f examples/simple-app-build-local/build.yml
simple-app | starting build (using Docker): test/e2e/assets/simple-app -> kbld:rand-1652108946742255592-1387725203109-simple-app
simple-app | starting build (using Docker): test/e2e/assets/simple-app -> kbld:rand-1652108946743073128-10522560189175-simple-app
...
resolve | final: simple-app -> kbld:simple-app-sha256-d4ca5dac9eb3959e041a367997debe1d42a8a08d2a34a885d56b65910201a611
resolve | final: simple-app2 -> kbld:simple-app-sha256-d4ca5dac9eb3959e041a367997debe1d42a8a08d2a34a885d56b65910201a611

What happened:
It builds the same image twice
What did you expect:
It only builds the image once
Anything else you would like to add:
[Additional information that will assist in solving the issue.]
Environment:

kbld version (use kbld --version): v0.33.0

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

Hello! @joaopapereira @praveenrewar . I recreated the above issue on my local system on two separate occassions and i got two different shasum's
resolve | final: simple-app -> kbld:simple-app-sha256-2d246faa9fec0e06584274d17d1336e114f2bcf3342fac699e6aa894288baee8
resolve | final: simple-app2 -> kbld:simple-app-sha256-c9e22332a5ec65dc311ff8bc41527ec16a5ef077abd4700d9fd0e12eaecdab34

resolve | final: simple-app -> kbld:simple-app-sha256-c9e22332a5ec65dc311ff8bc41527ec16a5ef077abd4700d9fd0e12eaecdab34
resolve | final: simple-app2 -> kbld:simple-app-sha256-c9e22332a5ec65dc311ff8bc41527ec16a5ef077abd4700d9fd0e12eaecdab34

the outputs are different.
I think here we should have two images but both should be different at every execution, any thoughts on why it's flaking?


Update nva-accelerated-connections.md

Updating the document for VMs in addition to NVAs

Updated Title (+ NVAs or other VMs)

@steveesp

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#swign-off

#sign-off


Double borrow when logging inside a log statement

I think this is what's happening in https://github.com/bytecodealliance/wasmtime/issues/6456
First a log statement borrows the internal writer, then we re-enter the log function another way and an attempt to re-borrow happen.

Fixed with https://github.com/bnjbvr/file-per-thread-logger/commit/515e95e981273ea81141f2a2aa3f957282b73150


Oauth question about browser vs native login UI

Hey guys, I'm learning about oauth and thought I'd take a look at your app as an example of best practices. A lot of blogs seem to suggest using a browser based authentication for mobile apps but I noticed you guys are using a native login UI.
How are you able to achieve the look and feel of native without compromising on security? Is going with a native UI any less secure?
Source: https://auth0.com/docs/design/browser-based-vs-native-experience-on-mobile

Hi @aoben10, app security is not related to a native or web based log in form. If you have a specific implementation question or an issue with building the app, please let me know.

Sorry, I should rephrase. My question mostly relates to what grant type is implemented in the app's Oauth flow.
I assumed it was Resource Owner password credential where a user sends the server login credentials and gets an access token in return. But the documentation I found online suggests using Oauth authentication with a PKCE grant type in a browser as best practice for native apps.
So is the app's current authentication implementation still considered secure even though authentication isn't happening through the browser?


OIDC single logout support

We are planning to set up an identity provider with single sign on and off based on CAS. It raised our attention that in version 5.0 OpenID Connect is supposed to be supported.
Apart from that it hasn't been released yet, what seems to be missing for us is the single sign out support. Is there any plan to support it in any form? We would be glad to contribute.

Yes of course. While it will likely not make the cut for 5, feel free to submit a patch please and/or test this current base functionality.

Or, based on the milestone schedules, if you can contribute a patch prior to RC1, that would be even more terrific. Should give you about 2 months.

Thanks for your quick response. We will inform you about our progress.

@szabatek just checking in to see if you have found OIDC here useful?

Sorry but I haven't informed you that in the meantime we took a completely different approach so we didn't touch too much it and resigned from developing it in CAS.

No problem. Thanks for the update

Closing, due to inactivity and absence of demand. Can be revisited later if need be.


FileCreate() returns NO_WACL_KEY

I'm attempting to create a file without any administrative keys attached.
Here's the code I want to run.
const { Client, FileCreateTransaction, Ed25519PublicKey, Hbar } = require("@hashgraph/sdk");

async function main() {
  const operatorPrivateKey = "...";
  const operatorAccount = "...";

  const client = new Client({
    network: { "0.testnet.hedera.com:50211": "0.0.3" },
    operator: {
      account: operatorAccount,
      privateKey: operatorPrivateKey
    }
  });

  const transactionId = await new FileCreateTransaction()
    .setContents("test file create")
    .setMaxTransactionFee(new Hbar(100))
    .execute(client);

  const receipt = await transactionId.getReceipt(client);
  console.log("new file id = ", receipt.getFileId());
}

main();

Which results in the following error.
 HederaStatusError: Hedera returned response code: NO_WACL_KEY

Based on the Hedera protobuf definitions, I should be able to leave this empty.

This has been a bug in the Hedera network. Not much we can do from the SDK side here. Maybe make the error message nicer.

Is there a timeline for this getting resolved? I understand I could use a throwaway key in the meantime.
cc @donaldthibeau

It's either a bug in the network or an explicit decision and the proto docs weren't updated. I'm not aware of any movement around it.

This will be fixed for the code to match the proto in the 0.5.0 release.

Closing as this isn't actionable here and it'll get fixed in 0.5 ( nice, :+1: ).


Respect requires-python when prefetching

Summary
This is fallout from https://github.com/astral-sh/uv/pull/4705. We need to respect requires-python in the prefetch code to avoid building unsupported distributions.
Closes https://github.com/astral-sh/uv/issues/4898.

Will add test coverage.

As a side-note, are we tracking not hard-failing on errors during pre-fetch? Seems wild that this can crash the resolution.

@zanieb - I don't think so... Part of the problem is that we do need to track failures here, we can't just skip silently, since if we later request the package and it fails in a way that we consider a hard failure (like a build failure), that does need to be surfaced.

I created https://github.com/astral-sh/uv/issues/4901.


def __init__() from Python is being completed incorrectly

Not sure if this is the right spot to report this bug, so please tell me if it isn't.
When trying to complete def __init__() the first option completes to def __init__(self) -> None:^@    super().__init__(). I'm guessing the ^@ is supposed to be converted to a newline. I'm using the pyright language server.

This is not a completion candidate provided by pyright. It is provided by another source, please show me vimrc.
Also, what you want to do can probably be achieved with a snippet engine. Multi-line completion is a different principle and requires a snippet engine (such as vsnip or LuaSnip). Since pyright does not provide snippets, you may want to define your own or use friendly snippet or something similar.

I just tried, ^@ is converted to a newline. Is it because of the newline or character encoding settings? Without looking at init.vim, it is hard to tell what is causing the problem.

Ohhh. I have to press enter. I was just moving on once it selected it as the first option. Could it be made to convert the symbol to a newline if it's automatically selected as the first option?

There is an option that automatically selects the first candidate when you press enter when the list of candidates is displayed.

I'll give that a shot. Thank you!

I will improve temporary text (maybe I will cut off the text till \n)


Long synthesis time on Vitis

Hi,
It seems that synthesis time is really long, specially because the interval requirements for the pipelining are not met and Vitis needs to guess the right parameters (which it does badly).
I have been trying to use this tool to compile a GBDT based on XGBoost with 700 trees, 40 features - 1000000 data points - and the following parameters:
{
            'objective': 'binary:logistic',
            'grow_policy': 'lossguide',
            'eval_metric': 'rmse',
            'eta': 1,
            'gamma': 1,
            'alpha': 1,
            'max_leaves': 7,
            'max_depth': 3,
            'seed': 0,
            'nthread': 16
 }

Trying to compile the resulting HLS code without modifying it fails because of the optimizations. After adjusting the optimizations, synthesis time takes hours. The same happened with a similar GBDT with only 50 trees and without modifying the HLS code.
Is there something I might be doing wrong?
Is this library recommended for such "big" models?

Hi, in this case I would recommend using the VHDL backend, if possible. The long synthesis time with the HLS is an issue that we don't have a solution for yet. You can see a comparison of the synthesis time as a function of the number of estimators (with depth fixed at 3), from our paper:

(Blue x is HLS C Synthesis, blue + is Logic Synthesis of HLS C Synthesis results, orange circle is Logic Synthesis of VHDL backend code)

Hi,
Thanks for the reply.
VHDL will make things a little bit more complicated since I am trying to use this as part of Vitis Design Flow, but I'll try.
Cheers.


public-before-private and static-before-instance are mutually exclusive

Bug Report

TSLint version: 3.7.1
TypeScript version: 1.8.7
Running TSLint via: CLI

TypeScript code being linted
public static foo = 2;
private static bar = 3;
public x: string;
private y: string;

with tslint.json:
{
    "member-ordering": [true,
      "public-before-private",
      "static-before-instance",
      "variables-before-functions"
    ],
}

Actual behavior

Declaration of private static member variable not allowed to appear after declaration of public instance member variable

Expected behavior
no error

Better support for member ordering will be available in TSLint 3.10. These options, public-before-private and static-before-instance, are now deprecated and will be removed in v4 (correct me if I'm wrong here @JKillian).

this is awesome, thanks everyone!
i'd love to use this asap. could you release a minor version?

Yep, coming today!


Feature/dockerfix

Closed as all 16 tests fail to connect to kafka. The current compose file seems to be the only one working


Rethink sampling

Right now we have stream.sampleWith(sampler), which works nicely.  It's fairly narrow in that it allows sampling one stream, and passing through the value directly.
One question this raises is how to sample 2 streams or N streams.  Say you wanted to add the values of two inputs, and display the result only when the user clicks a button.  You could combine the inputs, and then sample the resulting stream:
most.combine(add, s1, s2).sampleWith(buttonClick);

To cut down the noise, you might do:
most.combine(add, s1.distinct(), s2.distinct()).sampleWith(buttonClick);

But that's still doing extra, unnecessary adds: each time s1 or s2 changes, add will be called, even while the user isn't clicking the button.  If add is trivial, then you probably don't care.  On the other hand, it is doing extra work and throwing it away, which could be especially bad if add is nontrivial.
Another option might be to flip the whole thing around in a "sample that's like combine" combinator.  Like:
buttonClick.sample(add, s1, s2);

That allows sampling multiple inputs, and would only call add when the button is actually clicked, no matter how often s1 and s2 change.
Interestingly, it seems like both combine and sampleWith could be reimplemented using sample, although it's not clear the perf impact this may have on combine.
function combine(f, ...streams) {
    return merge(streams).sample(f, streams);
}

function sampleWith(sampler, stream) {
    return sampler.sample(identity, stream);
}

Messy proof of concept in d871f70496d21dc730ceadb69cc7d4ecb6819af6


Headplane advanced integration / features (DNS tab / SETTINGS tab)? Missing? Can't be activated?

Hey,
thank you for bringing headplane to yunohost!
I installed the yunohost headplane package.
I noticed that I dont have access to the DNS tab and the SETTINGs tag. The ACL tab is visible but I cant acctually write (change) ACLs.
I assumed that the advanced integration features are not available?
That is why I read the headplane docs here.
PROBLEM: I can not figure out how to activate the advanced features / do the advanced integration. Maybe I am simply not seeing it? The docs say: "When the configuration is available for editing, the DNS and Settings tabs will become available." I tried to change the access rights to the config file. This didnt change anything :(
QUESTIONS:
Do you know what the steps are to get the advanced features of headplane (mainly DNS)?
Is the headplane yunohost integration not yet ready for the advanced features?
Thank you for your efforts :)

Hey hey, thanks for the input. You are correct, Headplane own documentation on advanced features as it's called is rather vague.
But to my understanding headplane runs in different modes "as in how it communicates with headscale".
The mode that offers all features including the DNS management is called proc and it simply uses headscale's own socket file and authentication interface, that requires heaplane to be running by headscale system user or at least have read/write permissions to headscale directory (both socket and conf files)
As things are now it's just using the configuration api and authenticating using an api key, which isn't really ideal.
I have been testing some ideas, one of them is to install heaplane as a subdirectory to headscale and access it on headscale.domian/admin for example, which might be cleaner and will spare and extra subdomain just for headplane, but I'm not sure how to do it without conflicting with headscale's own configurations and update process yet.
I will create a branch for testing that soon when I find some time but will be happy to hear your ideas if you have any suggestions


ReLoRA - what we've learned

I don't get what you mean in the comment, there are at least 3 paper pertaining with branch merge methods, what are you saying about them? (none are mine, just following and interested)

Marking the items prior to Feb 29th as "closed".


dev: add documentation to makefile vs. invoke

          This delineation is insufficiently documented, likely because it hasn't been relevant until now. We definitely want to remidy that.

Why keep invoke at all? Ovartaci.
Originally posted by @MartinBernstorff in https://github.com/Aarhus-Psychiatry-Research/psycop-common/pull/490#discussion_r1406096118

Def. up for just removing invoke. It is already quite complex (+500 lines) and contains a lot of outdated stuff (docs).
@sarakolding would love your opinion here as well.
Actually, more generally I would like to simplify the CI to make it as simple as possible for others to maintain e.g. 1) remove cruft as I don't think we use it anymore(?), 2) potentially remove PR messages (makes the CI quite complex without adding a lot, an "echo" message in the CI could almost do the same) 3) and potentially other things. I can create the issue if people agree on that.

@KennethEnevoldsen would def be up for simplifying. i regularly use come inv commands, but i guess they could be implemented in makefile instead?

Invoke commands could be turned into makefile commands, but:

Would have to be written in bash/make, rather than Python (which we know well)

We could probably convert it to using subprocess.run instead, and use makefiles for entrypoints

Could not run on Windows/Ovartaci (which I think Jakob does)

Just adding this to the list of things we should think about 👍

Ahh right... not having access to make on overtaci is the biggest problem.
An alternative might be to use the invoke, but simplify it down to essentially something notably simpler.
No chance we can get make on overtaci?

Invoke commands could be turned into makefile commands, but:

Would have to be written in bash/make, rather than Python (which we know well)

We could probably convert it to using subprocess.run instead, and use makefiles for entrypoints

Could not run on Windows/Ovartaci (which I think Jakob does)

Just adding this to the list of things we should think about 👍

@bokajgd

Ahh right... not having access to make on overtaci is the biggest problem.
An alternative might be to use the invoke, but simplify it down to essentially something notably simpler.
No chance we can get make on overtaci?

I looked at using Chocolatey to install it, but:

Would require going through Andreas/Søren
The benefit is quite minor?

I think sticking to Python as much as possible would be a benefit here, but that's just a hunch.

So then remove the makefile?

Superseded by #500.


dracut: improve host distro support

Detecting the host distro allows the rootfs setup to be correctly
carried out.
Fixes: #343
Signed-off-by: Marco Vedovati<EMAIL_ADDRESS>

/test


symfony-cli: add missing compilation flags

Description of changes
I noticed that version displayed by the symfony-cli command line is always dev :

whereas official binaries from symfony-cli repository says 5.4.19, for instance.

I tried to figure out why and it’s actually due to some differences on compilation flags between official build and the current NixOS nix expression.
I tried to get closer of the official way, but without adding a build date to keep reproducibility.
I also added a simple check to be sure that the command can run.
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Hi, thanks for this!
Question, do you think it would be possible to use go realaser and have reproducible builds ?

Hi, thanks for this!

You are welcome.

Question, do you think it would be possible to use go realaser and have reproducible builds ?

I would not bet it. I don’t think it’s a kind of software with reproducibility in mind. But the truth is I can’t tell because I never used it. I would prefer rely on nixpkgs’ buildGoModule as suggested in the documentation

I would not bet it. I don’t think it’s a kind of software with reproducibility in mind. But the truth is I can’t tell because I never used it. Anyway, I would prefer rely on nixpkgs’ buildGoModule as suggested in the documentation

They do it on their side in the Github Action file: https://github.com/symfony-cli/symfony-cli/blob/main/.github/workflows/releaser.yml

Just because they do that doesn't make them build in a reproducible way. Note they also add a build date… :p

Just because they do that doesn't make them build in a reproducible way. Note they also add a build date… :p

Fair enough ! I validated this PR, all good for me then.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-in-distress/3604/58


Bundle Candidates

In the browser, each ICE candidate triggers an event. To prevent sending signalling messages for every single ICE candidate, browser implementations should wait a very short amount of time and bundle candidates before they are being sent.

Is 10 ms acceptable (long enough to catch immediate consecutive events but short enough so the user won't notice the delay)?

I've decided to not specify a timeout or anything like that. It is just recommended to bundle candidates in general. Here's how I would do it in the browser:

On candidate event, add the candidate to the bundled list and use setTimeout with a timeout value of 0 to just enqueue the function at the end of JS's event loop
Check if a new candidate event has been raised in the meantime.

Yes: Use setTimeout again with a timeout value of 0 and continue with 2.
No: Send the bundled candidates.

However, this only suits the browser version (needs to be tested, though) as the browser uses event callbacks for candidates. But usually a bunch of candidates arrive at the same time, so enqueuing at the end of the event loop should do the trick.

@dbrgn You could test that out if you want to - for the browser implementation. :)

@lgrahl sounds fine. I'll try.


Option to use different variant consequence priority list for SNV and SVs

Description of feature
See title

Done!


Refs #32074 -- Backported Enum.repr() from Python 3.10.

Enum.__repr__() was changed in https://bugs.python.org/issue40066 (see https://github.com/python/cpython/commit/b775106d940e3d77c8af7967545bb9a5b7b162df). The new format is more readable and can be used directly. I think we should use the same in Python < 3.10.
Failures on Python 3.10.0a7 without this patch:

model_enums.tests.ChoicesTests.test_integerchoices

Traceback (most recent call last):
  File "C:\Jenkins\workspace\django-windows\database\sqlite3\label\windows\python\Python310\tests\model_enums\tests.py", line 51, in test_integerchoices
    self.assertEqual(repr(Suit.DIAMOND), '<Suit.DIAMOND: 1>')
AssertionError: 'Suit.DIAMOND' != '<Suit.DIAMOND: 1>'
- Suit.DIAMOND
+ <Suit.DIAMOND: 1>

model_enums.tests.ChoicesTests.test_textchoices

Traceback (most recent call last):
  File "C:\Jenkins\workspace\django-windows\database\sqlite3\label\windows\python\Python310\tests\model_enums\tests.py", line 92, in test_textchoices
    self.assertEqual(repr(YearInSchool.FRESHMAN), "<YearInSchool.FRESHMAN: 'FR'>")
AssertionError: 'YearInSchool.FRESHMAN' != "<YearInSchool.FRESHMAN: 'FR'>"
- YearInSchool.FRESHMAN
+ <YearInSchool.FRESHMAN: 'FR'>

constraints.tests.UniqueConstraintTests.test_repr_with_deferrable

Traceback (most recent call last):
  File "C:\Jenkins\workspace\django-windows\database\sqlite3\label\windows\python\Python310\tests\constraints\tests.py", line 273, in test_repr_with_deferrable
    self.assertEqual(
AssertionError: "<Uni[28 chars], 'bar') name='unique_fields' deferrable=IMMEDIATE>" != "<Uni[28 chars], 'bar') name='unique_fields' deferrable=Deferrable.IMMEDIATE>"
- <UniqueConstraint: fields=('foo', 'bar') name='unique_fields' deferrable=IMMEDIATE>
+ <UniqueConstraint: fields=('foo', 'bar') name='unique_fields' deferrable=Deferrable.IMMEDIATE>
```

@pope1ni Thanks for checking :+1:

@carltongibson Thanks :+1:

Could this change be backported to older branches, please?

Hmm, actually that's not the only change needed for py3.10 in 3.1.x, it seems.

Django 4.0 will be the first version of Django to support Python 3.10


chore: add dell sonicwall to ext-firewall definition

Relevant information
adding new vendor telemetry to existing EXT-FIREWALL definition
Checklist

[x] I've read the guidelines and understand the acceptance criteria.
[x] The value of the attribute marked as identifier will be unique and valid.
[x] I've confirmed that my entity type wasn't already defined. If it is I'm providing an
explanation above.

@thezackm Please resolve the conflicts before we can merge.


index.golang.org: exclude unavailable module versions from default results

Background
index.golang.org serves the index of module versions stored in proxy.golang.org and sum.golang.org. Users can access the data using the API ((doc)[https://proxy.golang.org]).
  https://index.golang.org/index?since=<RFC3339Timestamp>

The API returns up to 1000 {module, version, timestamp} tuples added since the specified timestamp.
This index is the data source of pkg.go.dev, and some Go community members rely on it to retrieve data from the proxy and the checksum db for ecosystem-wide data analysis or mirroring.
The index reports all module versions that proxy.golang.org and sum.golang.org have ever served. As of today (March 2023), proxy.golang.org has observed and served ~16.7 million unique module versions
Problems
The current API is designed primarily for users who want to use it as a live feed of newly added module versions. For example, pkg.go.dev periodically polls the API endpoint to learn about newly added module versions.
This API is not ideal if users want the list of module versions available for redistribution from proxy.golang.org:

The result includes all module versions that proxy.golang.org has ever observed. Some may no longer exist in the proxy.golang.org’s storage, or in the source repositories. For example, module versions without recognized licenses may be evicted from proxy's storage after not being requested for some time.

Users of the index.golang.org API most likely send follow-up queries to proxy.golang.org to download the actual contents of the module versions. If these users attempt to download evicted module versions, proxy has to refetch them from the origin servers and service only if the checksums match what it observed before. Refetching causes increased response time and adds extra load to proxy.golang.org and source source hosting servers. The users could set Disable-Module-Fetch HTTP header to avoid refetch But few know about it.

Proposal

Change https://index.golang.org/index to return only module versions proxy.golang.org can serve without refetching. That means the module versions with recognized licenses or whose cached copies are still available in proxy's
storage at the API request time.
Users who need the current behavior must explicitly specify the include=all parameter.

Impact on users
We expect users that watch the index as feed won’t be affected. Users who are interested only in module versions that have recognized licenses or are actually used by go users won't be affected either.
Alternatives Considered
Change proxy.golang.org's default not to refetch
We considered the option to disable module fetch by default and enable module fetch explicitly only for the requests sent by the go command. Given the main goal of this proposal was to help users avoid accidental refetches, this could be the ideal solution to the problem. Unfortunately, HTTP requests coming from the go command are not distinguishable from other HTTP requests constructed using net/http. (https://go.dev/issues/35699)
Change index.golang.org's default to return only redistributable module versions
This could help us make the change without introducing the extra column to track the lifetime of the cached copies. However, proxy.golang.org detects licenses heuristically, and it may result in dropping some popular module versions from the index. This limitation would lead users to resort to using the include=all param and bypass this work.
Publish curated module version lists
Many users access index.golang.org to retrieve data for their Go ecosystem analysis, but they often find that only a small fraction of the 16.6 million module versions are relevant to their needs. This is because many of these versions no longer exist, are not valid Go modules (e.g. https://go.dev/issues/31866), or are no longer actively used by the Go community. To address this, we could consider compiling a curated list of module versions periodically and making it available through a different API endpoint.
This would help users who need the real Go modules and reduce the chance of accidental refetching. It would also make proxy.golang.org more transparent about the module versions it has in its long-term storage. However, this would require new feature work, and we cannot prioritize non-trivial new features at this time.

This is complete. index.golang.org provides updated documentation including the new include parameter.


Unity 3.5.405 - Strong-named assembly

In the latest release the Unity assemblies are no longer strong-named.
Will there be support for strong-named assemblies or is this an intentional change?

Do you have a requirement to have the assemblies strongly signed ?. This was an intentional change. Since the code was donated to us by Microsoft, we are not longer in possession of the original signing key. If you still need strong-named assemblies, we can review that but the signature will different as a new key will have to be used. Thanks

I do have those requirements since we use Unity in all our products to handle dependency injection.
For us, there is no problem in changing the signature key.
We would be more than thankful if you could review this.
Thanks.

I just pushed a new version, which is signed.


Provide option to ignore certain classes

Needed to be able to ignore elements based on their class or their parents class

This is not needed. You already have this functionality in the current version because you can specify exclusions using the jQuery selector syntax. For example, to ignore all H3 elements with the class 'ignored', you can do this:
$("#toc").toc({content: "div.container", headings: "h2,h3:not('.ignored'),h4"})

You can also use data attributes:

The documentation makes it pretty clear that you can use any valid jQuery selectors in this context.

Oh of course!! lol sorry I didn't even think of that.
My use case needs the parents part anyway so not a complete waste of time, but it probably is an edge case.

Sure, no problem!
You could also pass in a jQuery selector or selection object to the content argument, if you can craft your exclusions that way. This library looks for the headings within the content selection so that should do the trick if you want to ignore a container class or whatever from all headings.

Just thought I'd mention that I am closing this now, because like you said it's an edge case, and being minimal is one of the design goals of this library.


error: chroot: failed to run command '/bin/bash'

Describe the bug
When running tern against a debian image with no shell an error occurs
To Reproduce
Steps to reproduce the behavior:

tern report -i us.gcr.io/k8s-artifacts-prod/debian-base:v2.0.0
See default output

Docker image: us.gcr.io/k8s-artifacts-prod/debian-base:v2.0.0:
        Layer: 6ad620932a:
                info: Found 'Debian GNU/Linux 10 (buster)' in /etc/os-release.
                info: Layer created by commands: /bin/sh -c #(nop) ADD file:0b8523be17f9cbad484ec79879dac6357bf0b4d7e2c8a20d3d06d6162870c6fa in /
                info: Retrieved by invoking listing in command_lib/base.yml
versions:
        in container:
        pkgs=`dpkg --get-selections | cut -f1 -d':' | awk '{print $1}'`
        for p in $pkgs; do dpkg -l $p | awk 'NR>5 {print $3}'; done

names:
        in container:
        dpkg --get-selections | cut -f1 -d':' | awk '{print $1}'

copyrights:
        in container:
        pkgs=`dpkg --get-selections | cut -f1 -d':' | awk '{print $1}'`
        for p in $pkgs; do cat /usr/share/doc/$p/copyright; echo LICF; done

                error: chroot: failed to run command ‘/bin/bash’: No such file or directory
chroot: failed to run command ‘/bin/bash’: No such file or directory
chroot: failed to run command ‘/bin/bash’: No such file or directory

Expected behavior
A message saying that tern could not find a shell should be printed.

The issue here is that the binary dpkg exists in the filesystem but the corresponding shell as listed in base.yml which is /bin/bash does not.
@rnjudge What do you think about modifying the operation such that we store a list of possible shell binaries in base.yml and modify get_base_bin to look up the list and see if any of them exist on the filesystem?

@nishakm I like that idea!


Extend the "frame" command to set the current frame.

With this change, sommand
frame 3
sets up so that subsequent "print", "set", "whatis" commands
will operate on frame 3.
frame 3 print foo
continues to work too.
Added "up", "down". They move the current frame up or down.
Implementation note:
This changes removes "scopePrefix" mode from the terminal/command.go and instead
have the command examine the goroutine/frame value to see if it is invoked in a
scoped context.

@yasushi-saito any update on this?

@yasushi-saito ping.

Sorry I've got bogged down in different projects. I'll get back to this in
the weekend.
On Thu, Mar 15, 2018 at 5:59 PM, Derek Parker<EMAIL_ADDRESS>wrote:

@yasushi-saito https://github.com/yasushi-saito ping.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/derekparker/delve/pull/1110#issuecomment-373570021,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhVswWHDKNNvLW1MGArW0owAu5mSCSfks5tew6AgaJpZM4RxxX9
.

--
Yasushi Saito

Sorry for a belated response. I made a few changes:
Changed break and trace commands to use the current scope.
"up", "down" commands can take a subcommand, like "frame".
As for:

IMHO step, stepout, step-instruction and next should return an error if ctx.Scope.Frame != 0 because they don't actually do what's expected of them in that circumstance.

I kept the current code, since I personally use "step" after moving to a different frame a lot. It'd be annoying if we need to manually reset the frame just to step. gdb also works this way.

@aarzilli can you take another look at this and resolve your review if everything looks good?

Thanks, done.


Update solana.tokenlist.json

added a new token name ASHERA code ASH on solana.tokenlist.json. Reborn from Snowshoe's old token.
I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

i changed file :

solana.tokenlist.json (Add ASHERA)
upload logo on assets/mainnet
change version of package.json from 0.2.203 to 0.2.205
change CHANGELOG.md, add info 0.2.204 and 0.2.205 date

get version 0.2.204 from pull request #602


[editor][ez] Fix Resaturation of Editor with Bad Server State

[editor][ez] Fix Resaturation of Editor with Bad Server State
[editor][ez] Fix Resaturation of Editor with Bad Server State
Currently, when re-saturating the webview for an editor with bad server state (e.g. invalid model parsers in the config), the /load call will fail and leave the webview with the loading spinner:
https://github.com/lastmile-ai/aiconfig/assets/5060851/3949274d-fbb1-479f-a54a-9ac8870e617c
To fix, we can serialize the config in webview context and then use it to re-saturate the aiconfig state in the webview:
https://github.com/lastmile-ai/aiconfig/assets/5060851/5d67dc31-7b68-4782-af73-a8b6294a5452
For a webview with working state, note that /load is called successfully after the webview loads and will update the aiconfig state in the editor as needed (now that aiconfig prop updates the editor state)

I think this is good. The only two concerns I have:
1: in the case you trigger an execution, then navigate away from the tab, and come back, there is likely a period of time during which webview state AIConfig is inconsistent with server state -- in that case I think /load will make it eventually consistent.
2: size of webview state. Would recommend testing with huggingface.aiconfig.json which is 8MB I think.
I don't see any other way to solve this, but just wanted to call out some considerations (and why I had avoided saving the aiconfig in webview state)

Ah, ok. I had assumed it wasn't storing the config in state because of the prop not updating the editor state, but size constraint also makes sense. huggingface.aiconfig.json loads/resaturates quickly enough. Maybe we can add logic in the future to not persist state over some threshold size?
For 1. I just tested and toggling back currently only has updated output if the execution completed while toggled away. Otherwise, the outputs are not updated if toggling back before they complete (obviously streaming callback doesn't connect editor to the server anymore, but going to look into why it's not being updated as a result of the server updating the config since I would expect that to update the document itself. Maybe isInternalDocumentChange is true in this case

I think this is good. The only two concerns I have:
1: in the case you trigger an execution, then navigate away from the tab, and come back, there is likely a period of time during which webview state AIConfig is inconsistent with server state -- in that case I think /load will make it eventually consistent.
2: size of webview state. Would recommend testing with huggingface.aiconfig.json which is 8MB I think.
I don't see any other way to solve this, but just wanted to call out some considerations (and why I had avoided saving the aiconfig in webview state)

Ah, ok. I had assumed it wasn't storing the config in state because of the prop not updating the editor state, but size constraint also makes sense. huggingface.aiconfig.json loads/resaturates quickly enough. Maybe we can add logic in the future to not persist state over some threshold size?
For 1. I just tested and toggling back currently only has updated output if the execution completed while toggled away. Otherwise, the outputs are not updated if toggling back before they complete (obviously streaming callback doesn't connect editor to the server anymore, but going to look into why it's not being updated as a result of the server updating the config since I would expect that to update the document itself. Maybe isInternalDocumentChange is true in this case. In any case, this is the current behaviour on main as well and not a result of this change

Sounds good @rholinshead -- please feel free to ship this and we can iterate further on size constraints in the future if we encounter them :D


Feature/pap 9 implement real time direct messaging dm functionality

Problem
Jira Ticket: https://project-ascend-io.atlassian.net/browse/PAP-9?atlOrigin=eyJpIjoiMTQzZDM5YTNmZWIxNDVlNmE1MjczNGI5YzM0N2FkYjkiLCJwIjoiaiJ9
Our application needed the ability to send direct messages from one user to another and a way to persist that data in the database.
Solution
REST endpoints were created to handle the creation of messages and chats, which will be used to persist direct messages from one user to the other.
A Socket.io server was created to handle real-time events transmitted from one client to another, creating real-time direct messaging functionality.
Using AsyncAPI, documentation on how to interact with the Socket.io server from a client is generated using the generate:docs command. That documentation is delivered at the '/socket-docs' path.
Type of change

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Unit Tests
Manual Testing
Postman REST/Socket.io
Checklist:

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Great job @bobbygrdn! Code looks good. Let's keep this PR open until we can integrate it locally with the frontend to test it.


wget: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

I'm trying to use this layer, and I get the following:
wget: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

My CDK function config looks as follows:
import { createRequire } from 'node:module';

import { Duration } from 'aws-cdk-lib';
import { Architecture, Runtime } from 'aws-cdk-lib/aws-lambda';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import { Rule, Schedule } from 'aws-cdk-lib/aws-events';
import { RetentionDays } from 'aws-cdk-lib/aws-logs';
import { Construct } from 'constructs';
import { WgetLayer } from 'cdk-lambda-layer-wget';

const require = createRequire(import.meta.url);

interface Props {
	construct: Construct;
}

export const attach = ({ construct }: Props) => {
	const functionPath = require.resolve('my-function-package');

	const functionConstruct = new NodejsFunction(construct, 'MyFunction', {
		functionName: `MyFunction`,
		runtime: Runtime.NODEJS_20_X,
		// Intel because our wget layer is intel.
		architecture: Architecture.X86_64,
		entry: functionPath,
		handler: 'handler',
		memorySize: 256,
		timeout: Duration.minutes(15),
		logRetention: RetentionDays.ONE_DAY,
		layers: [new WgetLayer(construct, 'WgetLayer')],
	});

	// Schedule it to run every 5 minutes.
	const triggerRule = new Rule(construct, 'CronTrigger', {
		schedule: Schedule.rate(Duration.minutes(5)),
		targets: [new targets.LambdaFunction(functionConstruct)],
	});

	return { functionConstruct, triggerRule };
};

The error happens when I try to spawn wget from the function code. Should I be doing some kind of config to tell the lambda where the shared libs are? Do I need to specify LD_LIBRARY_PATH in the environment?

Try the new version and see if it solves the problem?

Works a treat, thanks so much!


Update patterns diagram to include Qiskit Serverless

Closes https://github.com/Qiskit/documentation/issues/1644.

Do you think we should update the Alt text for the image in index.mdx?  The rest of them are probably OK as-is

@pandasa123 wants us to hold off on merging this for now. We can reopen this PR when ready.


group Bouncy Castle updates into a single PR

When a new major/minor version of Bouncy Castle is released, we want to merge all those updates at once. Hopefully this configures Scala Steward to group those updates into a single PR (which we'll then need to massage to make sure it's checking bincompat successfully).

I can't find documentation around how Scala Steward evaluates the array of filter objects--however, based on filter object examples such as this (from Scala Steward's docs):
{ name = "typelevel", "title" = "Typelevel updates", "filter" = [{"group" = "org.typelevel"}, {"group" = "org.http4s"}] }

I wonder if the evaluated filter expression from the code change in this PR might resemble:
group = "org.bouncycastle" OR "version" = "minor" OR "version" = "major"

whereas my assumption is that the desired evaluated filter expression would be:
group = "org.bouncycastle" AND ("version" = "major" OR "version" = "minor")

Thoughts?

Yeah, good call. I updated it in 5d0418a, wdyt?

Latest commit looks good!
One other thing I noticed in your original PR comment was this phrase (emphasis mine): "we want to merge all those updates at once". I wasn't sure if that is meant to imply some automatic merge functionality should be included in these changes?

I think mergify will do that when the Scala Steward PR is approved, but either way, all the changes would be merged at once if they come in a single PR, which is really what I meant.


Rate limit contract change

Pull Request Test Coverage Report for Build 3455

12 of 13 (92.31%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 70.02%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/src/main/java/com/netflix/conductor/core/orchestration/ExecutionDAOFacade.java
0
1
0.0%

Totals

Change from base Build 3453:
0.04%

Covered Lines:
11129

Relevant Lines:
15894

💛  - Coveralls


Failed to install fiber in macOS. 🤗

Question description
I installed fiber using the instructions but it still won't let me use the fiber command, the console says it doesn't exist. I use macOS and Go version 1.18.

@CarlValenzuela96 Try installing with go install github.com/gofiber/cli/fiber@latest and make sure go bin is in your path.
export PATH=$PATH:$HOME/go/bin

can we add  go install github.com/gofiber/cli/fiber@latest to the readme?
I tried opening a PR but i get a 403 when trying to push.
@ReneWerner87  any thoughts?
Thanks!

https://github.com/gofiber/cli/commit/f105f0320dcf95237b36fd02b8659345fed8ca7e ok ?

closed with commit https://github.com/gofiber/cli/commit/f105f0320dcf95237b36fd02b8659345fed8ca7e


Prevent unpack from copying byte-arrays

byte-array calls clojure.lang.Numbers's byte_array which creates a new
byte array and copies the object into it, regardless of the input type.
This commit changes unpack to only call byte-array if the input is
not already a byte-array.
To demonstrate:
(let [obj {"a" (byte-array (repeat 1000000 0))}
      _ (println "pack:")
      ba (time (pack obj))]
  (println "unpack:")
  (time (unpack ba)))

Small tests locally show ~0.5ms to pack and ~8ms to unpack before the change.
And ~0.5ms to pack and ~0.5ms to unpack after.

nice catch!


Preview suddenly goes blank

Describe the bug
In the last couple of weeks, I experience that the preview goes blank quite often, triggered by a recompilation. Sometimes subsequent recompilation will fix the window, but the guaranteed fix is to open a new preview, confirming that the document compiles just fine. This typically occurs as I am just typing text.
Package/Software version:
Version: 1.83.1
Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
Date: 2023-10-10T23:45:31.402Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 5.15.0-86-generic

typst-preview extension version: v0.8.1
Logs:
typst-preview server log(Output Panel -> typst-preview):
I am unable to figure out how to open this log.
typst-preview client log(Help -> Toggle Developer Tools -> Console):
The Console did not output anything different when things worked, compared to when they did not.
Additional context
Here is a link to a video demonstrating the issue. I compile upon saving, so you can see when the compilation happens as the dot indicating unsaved changes dissapears. As the document contains some personal information, I want to delete the video as soon as possible. Let me know when you have what you need from the video.

my email is<EMAIL_ADDRESS>pls stamp the permission request

my email is<EMAIL_ADDRESS>pls stamp the permission request

Done

it looks like the preview becomes blank when the file is saved?
we previously notice that when saving, vscode will first truncate the file to zero length, then write acutal data. the 'empty' state has chances to trigger typst compilation.

Oh, that could be it! It would explain the "symptoms", as the page goes blank but seems to compile fine (i.e. nothing has crashed).
However, it seems to be the case that the odds of getting a blank page are rather large, making the "compile on save" option useless. Would it be possible to add a delay to the compilation, or just a "while filesize(path) == 0; do nothing; end" loop, to avoid compiling empty files?

I would love to. I am unable to find the "download" button on the linked GitHub action, so I will need a little more installation instructions. Perhaps I could build the master branch from source?

You can scroll down and click on the file names. This will trigger download

After a few minutes, I have not has the issue occuring, so it seems to be fixed! I will close this, and reopen it if the issue reappears. Thanks a bunch ^_^

Cool! glad to see it has been fixed. I will release a new version later this day.


Stuck sidecars and orders in DB

The pool database seems to get cluttered with sidecars and/hash mailboxes/or orders that are unable to be resolved, which can cause issues.
I am able to see a sidecar in a non-terminal state from this command, but I am unable to delete/cancel it.
$ pool s l
{
	"tickets": [
		{
			"id": "e9b329acc58cffff",
			"version": 0,
			"state": "expecting channel",
			"offer_capacity": "500000",
			"offer_push_amount": "0",
			"offer_lease_duration_blocks": 2016,
			"offer_sign_pubkey": "038a08e3fb6f360f1003985e91d33bbce7d084d05ae724202c35b1216f076721b4",
			"offer_signature": "30440220609bd6f9dc78f3037ff0f836cec0f31ea7c4204e146466499bc96d900ac87bb902203d30e8a2737ab4bba64c80ed992c0d5a6716ae1764ec33b686edc07e073e1ceb",
			"offer_auto": true,
			"recipient_node_pubkey": "0360a41eb8c3fe09782ef6c984acbb003b0e1ebc4fe10ae01bab0e80d76618c8f4",
			"recipient_multisig_pubkey": "039ebf4b7e2781662d09b4697b89a3da3a86c0cee9693be8820efba9ee9962653c",
			"recipient_multisig_pubkey_index": 374,
			"order_bid_nonce": "10724c38ef238eaf8351efba31fc1a470aaa0731a18f516da8af62269c18a1fc",
			"order_signature": "304402206137dcd0655e883ba9ab93b7675f3e1b91627f1f6ba5aeb30bd0eeedbd2333a10220039587e1719cd8112cac1f10264fa472445608ecb738e199dfe3007401b0aba6",
			"execution_pending_channel_id": null,
			"encoded_ticket": "sidecar12BbGp5KCgffSVoQYfSSfDVWxPqRn1y9cVR2yWoFq5jJyVabxXGZL9cxXqLADFnGqkDjoDkpJRim3BhWRwpX8mxmZvh5rr3PjLrC835NnfoTUH5v3LB2AUuGpZPE83ff3VVtBkUZ2JwJ7hELw4ox6PNfp1L8HNXkyYudNervE7uo6R4ucGRozyLAB1PGgLP4krEjWjKuN8rvFRLjvryTwux5ejb1vrakCqadndDR9SC9nYPZVQWXhgLVTZzdzsp17Q6nPcUoDd5wpMgH3s95yw3ACMXcJjLNANP8BgZye55e5XmHGpDPq2hMMyFeKbtAzvLpVRc5ERKfyum3D85tLP9AdmtgyyBzEdsUrknguAQyuJ9VihmXHmRyJ6V51fQc69BHxHvMDBUB3GkkRuvWs9Fx1qVDM9PfvfZfiGkkCd8sTtYGGLDtgCNjqUo82v7LR8WEvm"
		}
	]
}

$ pool s c e9b329acc58cffff
[pool] rpc error: code = Unknown desc = error canceling order 10724c38ef238eaf8351efba31fc1a470aaa0731a18f516da8af62269c18a1fc for sidecar ticket e9b329acc58cffff: no order found

Expected behavior
I would expect that deleting the sidecar would delete all references to that sidecar

Actual behavior
It can't find the order

To reproduce
This originally happened because I nuked my ~/.pool data directory, then ran pool a recover, then I tried registering a sidecar that had previously been registered, but was also in a stuck state.

 I guess that from master?

"version": "0.5.2-alpha commit=v0.5.2-alpha-1-gacdc235d50bee417e8637872650672a909860cc7"
commit acdc235d50bee417e8637872650672a909860cc7 (HEAD -> master, origin/master, origin/HEAD)


Bulk Delete API

mutation bulkDeleteTags(ids: ['id1', 'id2', 'id3']) {
   id
   result (success | fail)
   errorMessage
}

@vanpho93 Can you assign this ticket to me? Thank you

@luongtrieuvy202  There is bulk update API so you can take a look at it https://github.com/dryerjs/dryerjs/commit/91cb9ab14457e1a24568ea4969f2947d81eeeff6


KubernetesMinVersionKey check doesn't work with EKS?

Expected Behavior
When the minimum version of kubernetes required is 1.15.11,  EKS 1.15 with KUBERNETES_MIN_VERSION=1.15.11 should pass the minimum version check.
Actual Behavior
Using EKS 1.15 with KUBERNETES_MIN_VERSION=1.15.11 and Tekton Pipelines v0.16.3 raises this error:
kubernetes version \"1.15.11-eks-065dce\" is not compatible, need at least \"1.15.11\" (this can be overridden with the env var \"KUBERNETES_MIN_VERSION\")

Strangely, the Pipelines 0.16.3 docs indicate we actually need 1.16 https://github.com/tektoncd/pipeline/blob/v0.16.3/docs/install.md#before-you-begin but the error seems to indicate that the check is looking for 1.15.11 - I think the question here is whether or not the check is able to handle the string 1.15.11-eks-065dce. If it is, then maybe we're misunderstanding the real root problem.
Additional Info
Bug opened in Tekton: https://github.com/tektoncd/pipeline/issues/3335
/kind bug
Not sure what area to pick!

/assign

OK, so "-eks-065dce" is treated as pre release version. And pre-release versions are reverse, so no pre-release version is larger than any pre-release version. Hence 1.15.11-eks-065... is treated as smaller than 1.15.11.

ugh, yeah, we had this downstream once too. I believe requiring 1.15.11-0 does the track in that case.

I've added test coverage fo the situation and a bespoke error message for the case in the liked pr.