Full rework of the BlockFetch logic for bulk sync mode

Integrates a new implementation of the BulkSync mode, where blocks are downloaded from alternative peers as soon as the node has no more blocks to validate while there are longstanding requests in flight.
This PR depends on the new implementation of the BulkSync mode (https://github.com/IntersectMBO/ouroboros-network/pull/4919). cabal.project is made to point to a back-port of the BulkSync implementation on ouroboros-network-<IP_ADDRESS>.
CSJ Changes
CSJ is involved because the new BulkSync mode requires to change the dynamo if it is also serving blocks, and it is not sending them promptly enough. The dynamo choice has an influence in the blocks that are chosen to be downloaded by BlockFetch.
For this sake, b93c379 gives the ability to order the ChainSync clients, so the dynamo role can be rotated among them whenever BlockFetch requests it.
b1c0bf8 provides the implementation of the rotation operation.
BlockFetch tests
c4bfa37 allows to specify in tests in which order to start the peers, which has an effect on what peer is chosen as initial dynamo.
c594c09 in turn adds a new BlockFetch test to show that syncing isn't slowed down by peers that don't send blocks.
Integration of BlockFetch changes
The collection of ChainSync client handles now needs to be passed between BlockFetch and ChainSync so dynamo rotations can be requested by BlockFetch.
The parameter bfcMaxConcurrencyBulkSync has been removed since blocks are not coordinated to be downloaded concurrently.
These changes are in 6926278.
ChainSel changes
Now BlockFetch requires the ability to detect if ChainSel has run out of blocks to validate. This motivates 73187ba, which implements a mechanism to measure if ChainSel is waiting for more blocks (starves), and determines for how long.
The above change is not sufficient to measure starvation. The queue to send blocks for validation used to allow only for one block to sit in the queue. This would interfere with the ability to measure starvation since BlockFetch would block waiting for the queue to become empty, and the queue would quickly become empty after taking just 1 block. For download delays to be amortized, a larger queue capacity was needed. This is the reason why a fix similar to https://github.com/IntersectMBO/ouroboros-network/pull/2721 is part of 0d3fc28.
Miscellaneous fixes
CSJ jump size adjustment
When syncing from mainnet, we discovered that CSJ wouldn't sync the blocks from the Byron era. This was because the jump size was set to the length of the genesis window of the Shelley era, which is much larger than Byron's. When the jump size is larger than the genesis window, the dynamo will block on the forecast horizon before offering a jump that allows the chain selection to advance. In this case, CSJ and chain selection will deadlock.
For this reason we set the default jump size to the size of Byron's genesis window in 028883a. This didn't show an impact on syncing time in our measures. Future work (as part of deploying Genesis) might involve allowing the jump size to vary between different eras.
GDD rate limit
GDD evaluation showed an overhead of 10% if run after every header arrives via ChainSync. Therefore, in b7fa122 we limited how often it could run, so multiple header arrivals could be handled by a single GDD evaluation.
Candidate fragment comparison in the ChainSync client
We stumbled upon a test case where the candidate fragments of the dynamo and an objector were no longer than the current selection (both peers were adversarial). This was problematic because BlockFetch would refuse to download blocks from these candidates, and ChainSync in turn would wait for the selection to advance in order to download more headers.
The fix in e27a73c is to have the ChainSync client disconnect a peer which is about to block on the forecast horizon if its candidate isn't better than the selection.
Candidate fragment truncations
At the moment, it is possible for a candidate fragment to be truncated by CSJ when a jumper jumps to a point that is not younger than the tip of its current candidate fragment. We encountered tests where the jump point could be so old that it would fall behind the immutable tip, and GDD would ignore the peer when computing the Limit on Eagerness. This in turn would cause the selection to advance into potentially adversarial chains.
The fix in dc5f6f7 is to have GDD never drop candidates. When the candidate does not intersect the current selection, the LoE is not advanced. This is a situation guaranteed to be unblocked by the ChainSync client since it will either disconnect the peer or bring the candidate to intersect with the current selection.

The releasing branch has been rebased on top of this one and there is now a test failure there. Is this expected? @Niols https://github.com/IntersectMBO/ouroboros-consensus/pull/1314/checks?check_run_id=34400813212

Looking at the failure case:
      time limited leashing attack:                              FAIL (6.48s)
        *** Failed! Falsified (after 203 tests and 12 shrinks):
        GenesisTest:
          gtSecurityParam: 1
          gtGenesisWindow: 8
          gtForecastRange: 8
          gtDelay: 0
          gtSlotLength: SlotLength 20s
          gtCSJParams: CSJParams {csjpJumpSize = SlotNo 8}
          gtChainSyncTimeouts:
            canAwait = Nothing
            intersect = Just 10s
            mustReply = Nothing
            idle = Nothing
          gtBlockFetchTimeouts:
            busy = Just 60s
            streaming = Just 60s
          gtLoPBucketParams:
            lbpCapacity = 50 tokens
            lbpRate = 10 % 1 ≅ 10.00 tokens per second
          gtBlockTree:
            G | 1-3 2-7 3-11 4-15
            G | 1-3 2-5[4] 3-12 4-15 5-16 6-18
            G | 1-3 2-8[3] 3-18
            G | 1-0[1] 2-8 3-9 4-10
            slots:    0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18
            trunk:  ───────────1───────────2───────────3───────────4
                               ╰─────2────────────────────3────────4──5─────6
                               ╰──────────────2─────────────────────────────3
                   ╰──1───────────────────────2──3──4
          gtSchedule:
            psSchedule =
               0: honest     : TP 4-15          | HP G           | BP G    @ 0.000000
               1: adversary  : TP 6-18[0,4,4x0] | HP G           | BP G    @ 0.000000
               2: adversary 2: TP 3-18[0,3,0]   | HP G           | BP G    @ 0.000000
               3: honest     : TP 4-15          | HP 3-11        | BP G    @ 0.019353
               4: honest     : TP 4-15          | HP 3-11        | BP 1-3  @ 0.032457
               5: honest     : TP 4-15          | HP 4-15        | BP 1-3  @ 0.040614
               6: adversary 2: TP 3-18[0,3,0]   | HP 2-8[0,3]    | BP G    @ 0.057771
               7: adversary  : TP 6-18[0,4,4x0] | HP 3-12[0,4,0] | BP G    @ 0.080588
               8: honest     : TP 4-15          | HP 4-15        | BP 2-7  @ 0.083783
               9: adversary 4: TP G             | HP 4-10[1,3x0] | BP G    @ 0.129071
              10: honest     : TP 4-15          | HP 4-15        | BP 4-15 @ 0.135964
            psStartOrder = []
            psMinEndTime = Time 77.1s
        SelectedChain: 1-3 | 2-7
        TipBlock: 2-7
        PeerSimulatorResults:
          - AdversarialPeer 1 (ChainSyncClient  - Interrupted) : DensityTooLow
          - AdversarialPeer 1 (ChainSyncServer  - Interrupted) : AsyncCancelled
          - AdversarialPeer 1 (BlockFetchClient - Interrupted) : AsyncCancelled
          - AdversarialPeer 1 (BlockFetchServer - Interrupted) : AsyncCancelled
          - AdversarialPeer 4 (ChainSyncClient  - Interrupted) : CandidateTooSparse Origin (Tip (SlotNo 3) (testHashFromList [0]) (BlockNo 1)) (Tip (SlotNo 0) (testHashFromList [1]) (BlockNo 1))
          - AdversarialPeer 4 (ChainSyncServer  - Interrupted) : AsyncCancelled
          - AdversarialPeer 4 (BlockFetchClient - Interrupted) : AsyncCancelled
          - AdversarialPeer 4 (BlockFetchServer - Interrupted) : AsyncCancelled

        Some peers were disconnected: adversary 4, adversary
        The immutable tip is too old: 12
        12 > 9
        Use --quickcheck-replay="(SMGen<PHONE_NUMBER>4358042701<PHONE_NUMBER>786196345,2)" to reproduce.
        Use -p '/time limited leashing attack/' to rerun this test only.

The test looks reasonable, except k = 1? Not sure if that could lead to problems, or why such a case was generated. Somehow, despite k = 1, the client seems blocked on the fork between the honest chain and the chain served by adversary 2, unable to pass the intersection 1-3.
The genesis window is of size 8, the honest chain has 2 blocks in there while adversary 2 has only one. However, adversary 2 never serves its block at 3-18, so maybe that doesn't trigger the GDD? This should be covered by the LoP, in that case, because the adversary shouldn't be allowed to disarm it, and there is more than enough time. I would need to look at the full logs to see why that is not happening.
So either the test is flakey and we didn't catch that before and we're unlucky, or it's actually showing a subtle problem somewhere that we are not aware of, or maybe in the release branch some things changed in a way that impacts this. Will have a closer look.

Checked out this repo on branch neilmayhew/release-srp; got to a commit ef51726fc33b85cbffe17058199e948b5509f208, then ran:
cabal run ouroboros-consensus-diffusion:consensus-test -- --quickcheck-replay="(SMGen<PHONE_NUMBER>4358042701<PHONE_NUMBER>786196345,2)"

in the development environment and got:
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] next goal: ouroboros-network (user goal)
[__0] rejecting: ouroboros-network-<IP_ADDRESS> (constraint from user target requires ==<IP_ADDRESS>)
[__0] rejecting: ouroboros-network; <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS> (constraint from user target requires ==<IP_ADDRESS>)
[__0] fail (backjumping, conflict set: ouroboros-network)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: ouroboros-network

I'm not super up-to-date on how to run this test suite, is there anything I'm missing here?

Since the previous messages, I have been in contact with @jasagredo on the side. We have tracked down this test failure and concluded the following two things:

It is a bug in the peer simulator itself, and therefore a false positive — network safety is not threatened by this.
It is just an extremely rare occurrence, which was present already in blockfetch/milestone-1 as of 7d82cf12fbf08d31cf29f0657ebfb226c595ecae.

For posterity, I will add some details in the following messages, but that was the gist of it. In the coming days, I will push a small fix for this peer simulator bug, probably just by re-enabling timeouts for the canAwait state of the ChainSync client. I will also try to measure the probability for this test failure to appear, so as to gain confidence that it is indeed fixed.

Now, on neilmayhew/release-srp as of ef51726fc33b85cbffe17058199e948b5509f208, running
cabal run ouroboros-consensus-diffusion:consensus-test -- -p '/time limited leashing attack/' --quickcheck-replay="(SMGen<PHONE_NUMBER>4299620761<PHONE_NUMBER>7627667705,4)"

yields:
ouroboros-consensus
  Genesis tests
    uniform
      time limited leashing attack: FAIL (1.55s)
        *** Failed! Falsified (after 1 test and 21 shrinks):
        GenesisTest:
          gtSecurityParam: 2
          gtGenesisWindow: 5
          gtForecastRange: 5
          gtDelay: 1
          gtSlotLength: SlotLength 20s
          gtCSJParams: CSJParams {csjpJumpSize = SlotNo 5}
          gtChainSyncTimeouts:
            canAwait = Nothing
            intersect = Just 10s
            mustReply = Nothing
            idle = Nothing
          gtBlockFetchTimeouts:
            busy = Just 60s
            streaming = Just 60s
          gtLoPBucketParams:
            lbpCapacity = 50 tokens
            lbpRate = 10 % 1 ≅ 10.00 tokens per second
          gtBlockTree:
            G | 1-0 2-1 3-4 4-5 5-6 6-7 7-9
            G | 1-0 2-2[1] 3-8 4-9
            slots:    0  1  2  3  4  5  6  7  8  9
            trunk:  ──1──2────────3──4──5──6─────7
                      ╰─────2─────────────────3──4
          gtSchedule:
            psSchedule =
              0: honest     : TP 7-9          | HP G          | BP G   @ 0.000000
              1: adversary 3: TP 4-9[0,1,2x0] | HP G          | BP G   @ 0.000000
              2: honest     : TP 7-9          | HP G          | BP 3-4 @ 0.029276
              3: honest     : TP 7-9          | HP 7-9        | BP 3-4 @ 0.040478
              4: adversary 3: TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G   @ 0.070241
              5: honest     : TP 7-9          | HP 7-9        | BP 7-9 @ 0.081851
            psStartOrder = []
            psMinEndTime = Time 61.7s
        SelectedChain: 1-0 | 2-1 3-4
        TipBlock: 3-4
        PeerSimulatorResults:

        No peers were disconnected
        The immutable tip is too old: 9
        9 > 7
        Use --quickcheck-replay="(SMGen<PHONE_NUMBER>4299620761<PHONE_NUMBER>7627667705,4)" to reproduce.

...and here are the full logs, obtained by enabling tracing.
GenesisTest:
    gtSecurityParam: 2
    gtGenesisWindow: 5
    gtForecastRange: 5
    gtDelay: 1
    gtSlotLength: SlotLength 20s
    gtCSJParams: CSJParams {csjpJumpSize = SlotNo 5}
    gtChainSyncTimeouts:
    canAwait = Nothing
    intersect = Just 10s
    mustReply = Nothing
    idle = Nothing
    gtBlockFetchTimeouts:
    busy = Just 60s
    streaming = Just 60s
    gtLoPBucketParams:
    lbpCapacity = 50 tokens
    lbpRate = 10 % 1 ≅ 10.00 tokens per second
    gtBlockTree:
    G | 1-0 2-1 3-4 4-5 5-6 6-7 7-9
    G | 1-0 2-2[1] 3-8 4-9
    slots:    0  1  2  3  4  5  6  7  8  9
    trunk:  ──1──2────────3──4──5──6─────7
                ╰─────2─────────────────3──4
    gtSchedule:
    psSchedule =
        0: honest     : TP 7-9          | HP G          | BP G   @ 0.000000
        1: adversary 3: TP 4-9[0,1,2x0] | HP G          | BP G   @ 0.000000
        2: honest     : TP 7-9          | HP G          | BP 3-4 @ 0.029276
        3: honest     : TP 7-9          | HP 7-9        | BP 3-4 @ 0.040478
        4: adversary 3: TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G   @ 0.070241
        5: honest     : TP 7-9          | HP 7-9        | BP 7-9 @ 0.081851
    psStartOrder = []
    psMinEndTime = Time 61.7s
00:00.000   Initiating node startup
00:00.000 BlockFetchLogic | PeersFetch []
00:00.000 GDD | Window: 0 -> 4
00:00.000       Selection: G
00:00.000       Candidates:
00:00.000       Candidate suffixes (bounds):
00:00.000       Density bounds:
00:00.000       New candidate tips:
00:00.000       Losing peers: []
00:00.000       Setting loeFrag: G
00:00.000   Node startup complete with selection G
Running point schedule ...
┌──────────────────────────────────────────────────────────────────────────────┐
└─ 00:00.000
Tick:
    number: 0
    duration: 0s
    peer: honest
    state: TP 7-9 | HP G | BP G
    current chain: G
    candidate fragment: Nothing
    jumping states:

            ChainSyncServer honest       | handling MsgFindIntersect
            ChainSyncServer honest       |   state is TP 7-9 | HP G | BP G
            ChainSyncServer honest       | done handling MsgFindIntersect
            ChainSyncServer honest       |   intersection found: G
            ChainSyncClient honest       | Found intersection at: G
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Received instruction: RunNormally
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP G | BP G
            ChainSyncServer honest       |   last intersection is G
            ChainSyncServer honest       |   intersection is exactly our header point
            ChainSyncServer honest       |   cannot serve at this point; waiting for node state and starting again
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP G | BP G
            ChainSyncServer honest       |   last intersection is G
            ChainSyncServer honest       |   intersection is exactly our header point
            ChainSyncServer honest       |   cannot serve at this point; waiting for node state and starting again
            GDD | Window: 0 -> 4
                Selection: G
                Candidates:
                    honest: G
                    adversary 3: G
                Candidate suffixes (bounds):
                    honest: G
                Density bounds:
                    honest: 0/5[ ], point: G, latest: unknown
                New candidate tips:
                    honest: G
                    adversary 3: G
                Losing peers: []
                Setting loeFrag: G
            BlockFetchLogic | PeersFetch [TraceLabelPeer (HonestPeer 1) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible)]
┌──────────────────────────────────────────────────────────────────────────────┐
└─ 00:00.000
Tick:
    number: 1
    duration: 0.029276489858s
    peer: adversary 3
    state: TP 4-9[0,1,2x0] | HP G | BP G
    current chain: G
    candidate fragment: G
    jumping states:
    honest: Dynamo DynamoStarted G
    adversary 3: Jumper _ Happy FreshJumper Nothing

            ChainSyncServer adversary 3  | handling MsgFindIntersect
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP G | BP G
            ChainSyncServer adversary 3  | done handling MsgFindIntersect
            ChainSyncServer adversary 3  |   intersection found: G
            ChainSyncClient adversary 3  | Found intersection at: G
            ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
            GDD | Window: 0 -> 4
                Selection: G
                Candidates:
                    honest: G
                    adversary 3: G
                Candidate suffixes (bounds):
                    honest: G
                    adversary 3: G
                Density bounds:
                    honest: 0/5[ ], point: G, latest: unknown
                    adversary 3: 0/5[ ], point: G, latest: unknown
                New candidate tips:
                    honest: G
                    adversary 3: G
                Losing peers: []
                Setting loeFrag: G
┌──────────────────────────────────────────────────────────────────────────────┐
└─ 00:00.029
Tick:
    number: 2
    duration: 0.011201112595s
    peer: honest
    state: TP 7-9 | HP G | BP 3-4
    current chain: G
    candidate fragment: G
    jumping states:
    honest: Dynamo DynamoStarted G
    adversary 3: Jumper _ Happy FreshJumper Nothing

            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP G | BP 3-4
            ChainSyncServer honest       |   last intersection is G
            ChainSyncServer honest       |   intersection is exactly our header point
            ChainSyncServer honest       |   cannot serve at this point; waiting for node state and starting again
┌──────────────────────────────────────────────────────────────────────────────┐
└─ 00:00.040
Tick:
    number: 3
    duration: 0.029763889298s
    peer: honest
    state: TP 7-9 | HP 7-9 | BP 3-4
    current chain: G
    candidate fragment: G
    jumping states:
    honest: Dynamo DynamoStarted G
    adversary 3: Jumper _ Happy FreshJumper Nothing

            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncServer honest       |   last intersection is G
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: G | 1-0 2-1 3-4 4-5 5-6 6-7 7-9
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainSyncServer honest       |   gotta serve 1-0
            ChainSyncServer honest       |   tip is      7-9
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncServer honest       |   last intersection is 1-0
            ChainSyncClient honest       | Downloaded header: 1-0
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: 1-0 | 2-1 3-4 4-5 5-6 6-7 7-9
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainSyncServer honest       |   gotta serve 2-1
            ChainSyncServer honest       |   tip is      7-9
            GDD | Window: 0 -> 4
                Selection: G
                Candidates:
                    honest: G
                    adversary 3: G
                Candidate suffixes (bounds):
                    honest: G
                    adversary 3: G
                Density bounds:
                    honest: 0/5[ ], point: G, latest: 0
                    adversary 3: 0/5[ ], point: G, latest: unknown
                New candidate tips:
                    honest: G
                    adversary 3: G
                Losing peers: []
                Setting loeFrag: G
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncClient honest       | Validated header: 1-0
            ChainSyncServer honest       |   last intersection is 2-1
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: 2-1 | 3-4 4-5 5-6 6-7 7-9
            ChainSyncClient honest       | Gave LoP token to 1-0 compared to BlockNo 0
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainSyncServer honest       |   gotta serve 3-4
            ChainSyncServer honest       |   tip is      7-9
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            BlockFetchLogic | PeersFetch [TraceLabelPeer (HonestPeer 1) (Right [At (Block {blockPointSlot = SlotNo 0, blockPointHash = (testHashFromList [0])})]),TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible)]
            ChainSyncClient honest       | Received instruction: RunNormally
            BlockFetchServer honest      | handling BlockFetch
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | Starting batch for slice G | 1-0
            ChainSyncClient honest       | Downloaded header: 2-1
            BlockFetchServer honest      | done handling BlockFetch
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | Sending 1-0
            BlockFetchServer honest      | done handling SendBlocks
            ChainSyncClient honest       | Validated header: 2-1
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncClient honest       | Gave LoP token to 2-1 compared to BlockNo 1
            BlockFetchServer honest      | Batch is done
            BlockFetchServer honest      | done handling SendBlocks
            ChainDB                      | ChainSel starvation ended at 00:00.040 thanks to 1-0
            BlockFetchLogic | PeersFetch [TraceLabelPeer (HonestPeer 1) (Right [At (Block {blockPointSlot = SlotNo 1, blockPointHash = (testHashFromList [0,0])})]),TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible)]
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Received instruction: RunNormally
            BlockFetchServer honest      | handling BlockFetch
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | Starting batch for slice 1-0 | 2-1
            BlockFetchServer honest      | done handling BlockFetch
            ChainSyncClient honest       | Downloaded header: 3-4
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | Sending 2-1
            BlockFetchServer honest      | done handling SendBlocks
            ChainDB                      | Current chain: G
            ChainSyncClient honest       | Validated header: 3-4
            ChainDB                      | LoE fragment: G
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | Batch is done
            ChainSyncClient honest       | Gave LoP token to 3-4 compared to BlockNo 2
            BlockFetchServer honest      | done handling SendBlocks
            ChainDB                      | Added to current chain; now: G | 1-0
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Received instruction: RunNormally
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncServer honest       |   last intersection is 3-4
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: 3-4 | 4-5 5-6 6-7 7-9
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainSyncServer honest       |   gotta serve 4-5
            ChainSyncServer honest       |   tip is      7-9
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncServer honest       |   last intersection is 4-5
            ChainSyncClient honest       | Downloaded header: 4-5
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: 4-5 | 5-6 6-7 7-9
            ChainDB                      | Current chain: G | 1-0
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainDB                      | LoE fragment: G
            ChainSyncServer honest       |   gotta serve 5-6
            ChainSyncServer honest       |   tip is      7-9
            ChainSyncClient adversary 3  | Received instruction: JumpTo 3-4
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncClient adversary 3  | Offering jump to 3-4
            ChainSyncClient honest       | Validated header: 4-5
            ChainSyncServer honest       |   last intersection is 5-6
            ChainDB                      | Added to current chain; now: G | 1-0 2-1
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: 5-6 | 6-7 7-9
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainSyncClient honest       | Gave LoP token to 4-5 compared to BlockNo 3
            ChainSyncServer honest       |   gotta serve 6-7
            ChainSyncServer honest       |   tip is      7-9
            ChainSyncServer adversary 3  | handling MsgFindIntersect
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP G | BP G
            ChainSyncServer adversary 3  | done handling MsgFindIntersect
            ChainSyncServer adversary 3  |   no intersection found
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainDB                      | ChainSel starvation started at 00:00.040
            ChainSyncClient adversary 3  | Rejected jump to 3-4
            ChainSyncClient honest       | Received instruction: RunNormally
            ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Downloaded header: 5-6
            ChainSyncClient adversary 3  | Received instruction: JumpTo 2-1
            ChainSyncClient adversary 3  | Offering jump to 2-1
            ChainSyncClient honest       | Validated header: 5-6
            ChainSyncServer adversary 3  | handling MsgFindIntersect
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP G | BP G
            ChainSyncServer adversary 3  | done handling MsgFindIntersect
            ChainSyncClient honest       | Gave LoP token to 5-6 compared to BlockNo 4
            ChainSyncServer adversary 3  |   no intersection found
            ChainSyncClient adversary 3  | Rejected jump to 2-1
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Received instruction: RunNormally
            ChainSyncClient adversary 3  | Received instruction: JumpTo 1-0
            ChainSyncClient adversary 3  | Offering jump to 1-0
            ChainSyncClient honest       | Downloaded header: 6-7
            ChainSyncServer adversary 3  | handling MsgFindIntersect
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP G | BP G
            ChainSyncServer adversary 3  | done handling MsgFindIntersect
            ChainSyncClient honest       | Waiting for SlotNo 7 beyond forecast horizon
            ChainSyncServer adversary 3  |   intersection found: 1-0
            ChainSyncClient adversary 3  | Accepted jump to 1-0
            ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
            ChainSyncClient adversary 3  | Received instruction: JumpToGoodPoint 1-0
            ChainSyncClient adversary 3  | Offering jump to 1-0
            ChainSyncServer adversary 3  | handling MsgFindIntersect
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP G | BP G
            ChainSyncServer adversary 3  | done handling MsgFindIntersect
            ChainSyncServer adversary 3  |   intersection found: 1-0
            ChainSyncClient adversary 3  | Accepted jump to good point: 1-0
            ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
            ChainSyncClient adversary 3  | Received instruction: RunNormally
            ChainSyncServer adversary 3  | handling MsgRequestNext
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP G | BP G
            ChainSyncServer adversary 3  |   last intersection is 1-0
            ChainSyncServer adversary 3  |   intersection is further than our header point
            ChainSyncServer adversary 3  |   cannot serve at this point; waiting for node state and starting again
            GDD | Window: 1 -> 5
                Selection: G | 1-0 2-1
                Candidates:
                    honest: 5-6
                    adversary 3: 1-0
                Candidate suffixes (bounds):
                    honest: 1-0 | 2-1 3-4 4-5
                    adversary 3: 1-0
                Density bounds:
                    honest: 3/3[+], point: 2-1, latest: 7, has header after sgen
                    adversary 3: 0/5[ ], point: 1-0, latest: 0
                New candidate tips:
                    honest: 5-6
                    adversary 3: 1-0
                Losing peers: []
                Setting loeFrag: 1-0
            BlockFetchLogic | PeersFetch [TraceLabelPeer (HonestPeer 1) (Right [At (Block {blockPointSlot = SlotNo 4, blockPointHash = (testHashFromList [0,0,0])}),At (Block {blockPointSlot = SlotNo 5, blockPointHash = (testHashFromList [0,0,0,0])}),At (Block {blockPointSlot = SlotNo 6, blockPointHash = (testHashFromList [0,0,0,0,0])})]),TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible)]
            ChainDB                      | Requested ChainSel run
            BlockFetchServer honest      | handling BlockFetch
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainDB                      | Current chain: G | 1-0 2-1
            BlockFetchServer honest      | Starting batch for slice 2-1 | 3-4 4-5 5-6
            ChainDB                      | LoE fragment: G | 1-0
            BlockFetchServer honest      | done handling BlockFetch
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | Sending 3-4
            BlockFetchServer honest      | done handling SendBlocks
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | BP is behind
            BlockFetchServer honest      |   cannot serve at this point; waiting for node state and starting again
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | BP is behind
            BlockFetchServer honest      |   cannot serve at this point; waiting for node state and starting again
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | BP is behind
            BlockFetchServer honest      |   cannot serve at this point; waiting for node state and starting again
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 3-4
            BlockFetchServer honest      | BP is behind
            BlockFetchServer honest      |   cannot serve at this point; waiting for node state and starting again
            ChainDB                      | Current chain: G | 1-0 2-1
            ChainDB                      | LoE fragment: G | 1-0
            ChainDB                      | Added to current chain; now: G | 1-0 2-1 3-4
            ChainSyncClient honest       | Accessing SlotNo 7, previously beyond forecast horizon
            ChainSyncClient honest       | Validated header: 6-7
            ChainSyncClient honest       | Gave LoP token to 6-7 compared to BlockNo 5
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Received instruction: RunNormally
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncServer honest       |   last intersection is 6-7
            ChainSyncServer honest       |   intersection is before our header point
            ChainSyncServer honest       |   fragment ahead: 6-7 | 7-9
            ChainSyncServer honest       | done handling MsgRequestNext
            ChainSyncServer honest       |   gotta serve 7-9
            ChainSyncServer honest       |   tip is      7-9
            ChainSyncClient honest       | Downloaded header: 7-9
            ChainSyncClient honest       | Validated header: 7-9
            ChainSyncClient honest       | Gave LoP token to 7-9 compared to BlockNo 6
            ChainSyncClient honest       | Waiting for next instruction from the jumping governor
            ChainSyncClient honest       | Received instruction: RunNormally
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
            ChainSyncServer honest       |   last intersection is 7-9
            ChainSyncServer honest       |   chain has been fully served
            ChainSyncServer honest       | done handling MsgRequestNext
            GDD | Window: 1 -> 5
                Selection: 1-0 | 2-1 3-4
                Candidates:
                    honest: 7-9
                    adversary 3: 1-0
                Candidate suffixes (bounds):
                    honest: 1-0 | 2-1 3-4 4-5
                    adversary 3: 1-0
                Density bounds:
                    honest: 3/3[+], point: 2-1, latest: 9, has header after sgen, idling
                    adversary 3: 0/5[ ], point: 1-0, latest: 0
                New candidate tips:
                    honest: 7-9
                    adversary 3: 1-0
                Losing peers: []
                Setting loeFrag: 1-0
            BlockFetchLogic | PeersFetch [TraceLabelPeer (HonestPeer 1) (Right [At (Block {blockPointSlot = SlotNo 7, blockPointHash = (testHashFromList [0,0,0,0,0,0])}),At (Block {blockPointSlot = SlotNo 9, blockPointHash = (testHashFromList [0,0,0,0,0,0,0])})]),TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible)]
┌──────────────────────────────────────────────────────────────────────────────┐
└─ 00:00.070
Tick:
    number: 4
    duration: 0.011609304825s
    peer: adversary 3
    state: TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G
    current chain: 1-0 | 2-1 3-4
    candidate fragment: G | 1-0
    jumping states:
    honest: Disengaged DisengagedDone
    adversary 3: Dynamo 1-0 SlotNo 0

            ChainSyncServer adversary 3  | handling MsgRequestNext
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G
            ChainSyncServer adversary 3  |   last intersection is 1-0
            ChainSyncServer adversary 3  |   intersection is before our header point
            ChainSyncServer adversary 3  |   fragment ahead: 1-0 | 2-2[1] 3-8
            ChainSyncServer adversary 3  | done handling MsgRequestNext
            ChainSyncServer adversary 3  |   gotta serve 2-2[0,1]
            ChainSyncServer adversary 3  |   tip is      4-9[0,1,2x0]
            ChainSyncServer adversary 3  | handling MsgRequestNext
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G
            ChainSyncServer adversary 3  |   last intersection is 2-2[0,1]
            ChainSyncClient adversary 3  | Downloaded header: 2-2[0,1]
            ChainSyncServer adversary 3  |   intersection is before our header point
            ChainSyncServer adversary 3  |   fragment ahead: 2-2[0,1] | 3-8
            ChainSyncServer adversary 3  | done handling MsgRequestNext
            ChainSyncServer adversary 3  |   gotta serve 3-8[0,1,0]
            ChainSyncServer adversary 3  |   tip is      4-9[0,1,2x0]
            GDD | Window: 1 -> 5
                Selection: 1-0 | 2-1 3-4
                Candidates:
                    honest: 7-9
                    adversary 3: 1-0
                Candidate suffixes (bounds):
                    honest: 1-0 | 2-1 3-4 4-5
                    adversary 3: 1-0
                Density bounds:
                    honest: 3/3[+], point: 2-1, latest: 9, has header after sgen, idling
                    adversary 3: 0/5[ ], point: 1-0, latest: 2
                New candidate tips:
                    honest: 7-9
                    adversary 3: 1-0
                Losing peers: []
                Setting loeFrag: 1-0
            ChainSyncServer adversary 3  | handling MsgRequestNext
            ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G
            ChainSyncClient adversary 3  | Validated header: 2-2[0,1]
            ChainSyncServer adversary 3  |   last intersection is 3-8[0,1,0]
            ChainSyncServer adversary 3  |   intersection is exactly our header point
            ChainSyncServer adversary 3  |   cannot serve at this point; waiting for node state and starting again
            ChainSyncClient adversary 3  | Gave LoP token to 2-2[0,1] compared to BlockNo 1
            BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineInFlightThisPeer)]
            ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
            ChainSyncClient adversary 3  | Received instruction: JumpToGoodPoint 1-0
┌──────────────────────────────────────────────────────────────────────────────┐
└─ 00:00.081
Tick:
    number: 5
    duration: 0.1s
    peer: honest
    state: TP 7-9 | HP 7-9 | BP 7-9
    current chain: 1-0 | 2-1 3-4
    candidate fragment: 1-0 | 2-1 3-4 4-5 5-6 6-7 7-9
    jumping states:
    honest: Disengaged DisengagedDone
    adversary 3: Dynamo DynamoStarted SlotNo 0

            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            ChainSyncServer honest       | handling MsgRequestNext
            ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 7-9
            BlockFetchServer honest      | Sending 4-5
            ChainSyncServer honest       |   last intersection is 7-9
            BlockFetchServer honest      | done handling SendBlocks
            ChainSyncServer honest       |   chain has been fully served
            ChainSyncServer honest       | done handling MsgRequestNext
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            BlockFetchServer honest      | Sending 5-6
            BlockFetchServer honest      | done handling SendBlocks
            ChainDB                      | ChainSel starvation ended at 00:00.081 thanks to 4-5
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            BlockFetchServer honest      | Batch is done
            BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineInFlightThisPeer)]
            BlockFetchServer honest      | done handling SendBlocks
            BlockFetchServer honest      | handling BlockFetch
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            BlockFetchServer honest      | Starting batch for slice 5-6 | 6-7 7-9
            BlockFetchServer honest      | done handling BlockFetch
            BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineInFlightThisPeer)]
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            BlockFetchServer honest      | Sending 6-7
            BlockFetchServer honest      | done handling SendBlocks
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            BlockFetchServer honest      | Sending 7-9
            BlockFetchServer honest      | done handling SendBlocks
            ChainDB                      | Current chain: 1-0 | 2-1 3-4
            BlockFetchServer honest      | handling SendBlocks
            BlockFetchServer honest      |   state is TP 7-9 | HP 7-9 | BP 7-9
            ChainDB                      | LoE fragment: 1-0
            BlockFetchServer honest      | Batch is done
            BlockFetchServer honest      | done handling SendBlocks
            ChainDB                      | Current chain: 1-0 | 2-1 3-4
            ChainDB                      | LoE fragment: 1-0
            ChainDB                      | Current chain: 1-0 | 2-1 3-4
            ChainDB                      | LoE fragment: 1-0
            ChainDB                      | Current chain: 1-0 | 2-1 3-4
            ChainDB                      | LoE fragment: 1-0
            ChainDB                      | ChainSel starvation started at 00:00.081
            BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
00:10.081 BlockFetchLogic | PeerStarvedUs (HonestPeer 1)
00:10.081 BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
00:20.081 BlockFetchLogic | PeerStarvedUs (HonestPeer 1)
00:20.081 BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
00:30.081 BlockFetchLogic | PeerStarvedUs (HonestPeer 1)
00:30.081 BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
00:40.081 BlockFetchLogic | PeerStarvedUs (HonestPeer 1)
00:40.081 BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
00:50.081 BlockFetchLogic | PeerStarvedUs (HonestPeer 1)
00:50.081 BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
01:00.081 BlockFetchLogic | PeerStarvedUs (HonestPeer 1)
01:00.081 BlockFetchLogic | PeersFetch [TraceLabelPeer (AdversarialPeer 3) (Left FetchDeclineChainNotPlausible),TraceLabelPeer (HonestPeer 1) (Left FetchDeclineAlreadyFetched)]
╶──────────────────────────────────────────────────────────────────────────────╴
Finished running point schedule
SelectedChain: 1-0 | 2-1 3-4
TipBlock: 3-4
PeerSimulatorResults:

No peers were disconnected
The immutable tip is too old: 9
9 > 7
Use --quickcheck-replay="(SMGen<PHONE_NUMBER>4299620761<PHONE_NUMBER>7627667705,4)" to reproduce.

The story is the following:

Two peers, honest and adversary.
Honest serves its chain entirely, while the adversary only serves some of its headers.
The honest peer is chosen as the dynamo for CSJ, which we can see in tick 1:jumping states:
    honest: Dynamo DynamoStarted G
    adversary 3: Jumper _ Happy FreshJumper Nothing

The honest peer serves all of its chain, and therefore gets disengaged from CSJ. We can see that in tick 3:ChainSyncServer honest       | handling MsgRequestNext
ChainSyncServer honest       |   state is TP 7-9 | HP 7-9 | BP 3-4
ChainSyncServer honest       |   last intersection is 7-9
ChainSyncServer honest       |   chain has been fully served
ChainSyncServer honest       | done handling MsgRequestNext

and in the begining of tick 4:jumping states:
  honest: Disengaged DisengagedDone
  adversary 3: Dynamo 1-0 SlotNo 0

In fact, at this point, the adversary is just starting as a dynamo, and we first have to reset the state of its ChainSync client to the known intersection. This happens in the same tick (4):ChainSyncClient adversary 3  | Waiting for next instruction from the jumping governor
ChainSyncClient adversary 3  | Received instruction: JumpToGoodPoint 1-0

And then... nothing, the ChainSync client goes quiet.

@jasagredo and I tracked it down, and it turns out that the ChainSyncClient for the adversary is stuck in the drainThePipe function. This is because its corresponding ScheduledChainSyncServer is just not answering the MsgRequestNext, by design: indeed, the next header to be served is ahead of the header point, so it cannot be served, but it is not the tip point either, so we cannot say MsgAwaitReply. We could actually see that in tick 4, slightly before the instruction to JumpToGoodPoint 1-0:
ChainSyncServer adversary 3  | handling MsgRequestNext
ChainSyncServer adversary 3  |   state is TP 4-9[0,1,2x0] | HP 3-8[0,1,0] | BP G
ChainSyncServer adversary 3  |   last intersection is 3-8[0,1,0]
ChainSyncServer adversary 3  |   intersection is exactly our header point
ChainSyncServer adversary 3  |   cannot serve at this point; waiting for node state and starting again

So far so good. The test fails because nothing unblocks the situation, so we stay stuck at this intersection forever. In fact, the ChainSync mini-protocol of the adversary stays in StCanAwait for ever. It should be dislodged from it by timeouts, but those have been disabled! (See the very beginning of the first output I pasted.)

Reminder of the ChainSync mini-protocol state machine

Now at this point I am not entirely sure whether there was a deep reason to disable those timeouts or if it was a bit of an oversight. Here is the corresponding test case in Uniform.hs:
-- | Test that the leashing attacks do not delay the immutable tip after. The
-- immutable tip needs to be advanced enough when the honest peer has offered
-- all of its ticks.
--
-- See Note [Leashing attacks]
prop_leashingAttackTimeLimited :: Property
prop_leashingAttackTimeLimited =
  forAllGenesisTest

    (disableCanAwaitTimeout . disableBoringTimeouts <$>
      genChains (QC.choose (1, 4)) `enrichedWith` genTimeLimitedSchedule
    )

    defaultSchedulerConfig
      { scTrace = True
      , scEnableLoE = True
      , scEnableLoP = True
      , scEnableCSJ = True
      , scEnableBlockFetchTimeouts = False
      }

    shrinkPeerSchedules

    theProperty

Note in particular the disableBoringTimeouts and disableCanAwaitTimeout. The latter is probably self-explanatory. The former is:
disableBoringTimeouts :: GenesisTest blk schedule -> GenesisTest blk schedule
disableBoringTimeouts gt =
    gt
      { gtChainSyncTimeouts =
          (gtChainSyncTimeouts gt)
            { mustReplyTimeout = Nothing
            , idleTimeout = Nothing
            }
      }

The conclusion is double:

I think there is a mix-up between canAwait and mustReply; at least, there was one in my head and it is consistent with this piece of code: it is important to disable the mustReply timeout because, in the context of the peer simulator tests, the chains are finite, so an honest node will serve all of it, then send MsgAwaitReply, and then will not be able to do anything else, and it should not get disconnected for this, of course. I think that's the sense of this disableCanAwaitTimeout function, but really it should be disableMustReplyTimeout (look at the state machine again if need be!). I suppose the mix-up comes from the fact that the important message is MsgAwaitReply. I think I might be behind this mistake. It is an easy fix; I will add some documentation in the process.

We cannot just disable the timeouts like this. In particular, the canAwait timeout must be enabled to a value that has an observable effect in the duration of the test (so maybe something like 10s is enough, maybe even much shorter than that). This part of the problem is slightly more delicate to fix, because there might be a reason why they were disabled in the first place, and the people that wrote this test are on PTO for the winter, and because choosing a good value for the timeouts, that is not too high but also doesn't just break good tests, is non-trivial. Still, I will whip something up!

Come to think of it, I think the mix-up is that “can await” sounds much nicer and less urgent than “must reply”, at least in my head, even though those terms don't per se carry any time meaning. In practice, in StCanAwait, we expect a very prompt message, but it can be a message that say that we will take more time (MsgAwaitReply), and in StMustReply, the message has to be a proper reply (MsgRoll*), but it can take much longer to come back.

For the probability of the test failure, I now measured over night 22 test failures over 2,000,000 test cases. This means that it is very unlikely to happen, but that if my fix does pass the same amount of test cases over the next night, then we can be pretty confident that it was a good fix.

Approximate probability that the bug appears at least once after a certain amount of tests:


[redesign] fragmentation does work for some twitter content

Fragmentation for this tweet on plugin mode does not return anything:
https://twitter.com/sp_a/status/998089909369016325
Also the fragmentation page does work on hosted mode.

it works on the current version of the plugin (on the Chromestore)


Encode the object type / protocol into QR code

So that our users:

Will get an error when trying to scan this code from another app
Will open Beam Wallet automatically (if installed) when OS-level scanning will happen

New format:
beam:12d1a5d6dc54af1792dc67325aeb274c38c36e005c730b964e978f0d3afdfddbc26?amount=12.102
Must: read old formats

about design: just add field "Transaction amount" above field "Comment" (like in desktop version)

about design: just add field "Transaction amount" above field "Comment" (like in desktop version)

@Denis-Asipenko Hi. But in the mobile design this field should be on top. Please check https://zpl.io/anpJOmr
@sasha-abramovich Tell me where the field should be?

Should be named "Receive" amount on every platform. And the design https://app.zeplin.io/project/5c73dc8aa74b4b4085a86a91/screen/5c73e6ed1896bf1a964c4fe4 looks right.
not sure what is the question is

BTW, in desktop it's here: https://app.zeplin.io/project/5b379c2c38cb39e73e5f8889/screen/5bd18f9c140d6a09ac8bd6dd
(also called "Receive amount", FYI: @gingervik @Sergei-Beam)

On receive screen max Transaction amount which user can enter should be <=262,800,000

checked


Matomo support multisites

Adds multi-site support for Matomo.
Changes:

Check more keyserver pools for when using gpg to make builds a bit more stable when keyservers do not respond.
Change Matomo nginx setup to support hosting a with/without /matomo path prefix.
Create database entries per configured site, and update if variables change.
Make sure all multi-sites are considered trusted hosts.

Was a couple of commits behind main so I rebased.

Was a couple of commits behind main so I rebased.

Getting this when going to visit Matomo:

The database dump that gets templated out needs to respect the $DOMAIN variable we're setting now.

Oh... maybe it's just an issue with the docker-compose.matomo.yml file in isle-dc.  MATOMO_SITE_HOST should become MATOMO_DEFAULT_SITE_HOST.  Let me try that, and if it's good, i'll merge this.

Yep, I made those changes and now we're good:


Support for NO_PROXY

Would you like to work on this feature?
yes
What problem are you trying to solve?
kube-rs currently supports the HTTP_PROXY (and all its variants) environment variable, but not the NO_PROXY var.
https://github.com/kube-rs/kube/blob/be15f7aab94863b24b7c903dc08812044504b1e3/kube-client/src/config/file_loader.rs#L110-L127
The NO_PROXY var is not standardised, but it's supported by Go and I think we could follow with similar support in here.
Describe the solution you'd like
change the proxy_url fn so that if NO_PROXY is set and the content matches the cluster.server url, return None, otherwise continue as usual.
The matching impl could be similar to https://github.com/seanmonstar/reqwest/pull/877
Describe alternatives you've considered
None
Documentation, Adoption, Migration Strategy
N/A
Target crate for feature
kube-client

Go's NO_PROXY impl also supports cidr blocks which would require something like the ipnet crate.

Seems reasonable to me. PRs welcome.

Ok so I spent some time on this and I had a look at reqwest, attohttpc, the no_proxy crate, Go's implementation and that article.
It's a big mess 🙈
The rust implementations above seem to be closer to curl although they all have some minor differences. They all seem to support CIDR (which curl doesn't), but they are missing support for ports. I'm not sure why they decided to ignore ports, maybe because it simplifies the impl?
As for Kube, given the context we're in, IMO we should match Go's implementation as much as possible. Given the no_proxy's crate goal of following the proposed standard from this article, it's unlikely that it'll ever match Go's. And given that Go has had this feature for years, they probably won't be introducing a breaking change either.
I ended up authoring this crate proxyvars with the explicit goal of matching Go's impl, which I'll be using until no_proxy support lands on kube-rs itself.
But before we move on, what are your thoughts on this? Adding either no_proxy or proxyvars to kube would result in something like:
    pub fn proxy_url(&self) -> Result<Option<http::Uri>, KubeconfigError> {
        if let Some(server_url) = &self.cluster.server {
            if let Some(no_proxy) = proxyvars::no_proxy() {
                if no_proxy.matches(server_url) {
                    return Ok(None);
                }
            }
        }

This package does not actually proxy the connection, you'll need to use something like hyper-proxy for that

Ok. So, it supports http(s)_proxy environment variables but not proxies calls itself. It’s a bit curious for me 😀 thx

Ok. So, it supports http(s)_proxy environment variables but not proxies calls itself. It’s a bit curious for me 😀 thx

So the proxy functionality is not implemented here.


Wrong culture

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
The website is in english the windows OS in dutch but a german language powershell is installed
Expected behavior
Dutch

Actual behavior
German

Error details
wrong culture languages

Environment data
letest

Visuals
No response

As far as I know, the PowerShell (Core) edition (v6+), which this repo is solely devoted to, doesn't even have localized versions - see https://github.com/PowerShell/PowerShell/issues/666.
Does your problem relate to Windows PowerShell or, perhaps, are you seen localized output from a program that is external to PowerShell?
In general, please fill in explicit version information when you create an issue.

@kingma-sbw we can't help you with this little details, so you need to provide more information as to allow us to help you

It is related.
But it's still not clear what your problem is. Where do you see [the wrong] localized elements show up?

Thanks I seem not to be able to reproduce this issue, sorry.


licensescan: Add licenses for more libraries

Thanks - lgtm & verified a few I wasn't familiar with :+1:


Saving logs data streamed from robot

It would be great if we would be able to save the data streamed from the robot live in to a rlog file.

This is now supported in the 2023 beta of AdvantageScope (with WPILOG instead of RLOG).
https://github.com/Mechanical-Advantage/AdvantageScope/blob/main/docs/EXPORT.md


Typed properties and nullable properties not supported on the Matomo-supported PHP version

According to the docs https://matomo.org/faq/on-premise/matomo-requirements/ Matomo 4.x supports PHP version 7.2.5 or greater, but ProtectTrackerID version 2.3.0 contains some code not compatible with this PHP version at
https://github.com/joubertredrat/Matomo-ProtectTrackID/blob/master/PluginSettings.php#L29
URL:
/index.php?module=CoreAdminHome&action=generalSettings&idSite=1&period=day&date=yesterday
Log message:
PHP Parse error:  syntax error, unexpected '?', expecting function (T_FUNCTION) or const (T_CONST) in /home1l/urchin/www/plugins/ProtectTrackID/PluginSettings.php on line 29
This causes the app to die, so a fix would be much appreciated!  We can't upgrade PHP bc our enterprise is dependent on RedHat Software Collections' PHP, which is sticking to old PHP.
Typed properties and nullable properties were not introduced until PHP 7.4 (ref https://php.watch/versions/7.4/typed-properties).

Hi @mwithheld, thanks for your issue.
You're right, I'm going to create fix here, thanks.

Hi @mwithheld, can you provide de exaclty version of PHP are you using?

PHP 7.3.20

@mwithheld I published version 2.4.0. Feel free to update and check it. If issue persist, you can reopen this task.


AngularJS 1.4.8 & IE10: SCRIPT5009: 'angular' is undefined

https://code.angularjs.org/1.4.8/docs/guide/ie doesn't really give any good information.
IE10 doesn't work with the following fiddle: https://jsfiddle.net/basickarl/4behds2y/3/
I'm also running a localhost server (nodejs) and I'm running a IE10 on Win8 VM from https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/ to test.
I get the following error: SCRIPT5009: 'angular' is undefined. I tried setting  but still doesn't work. My includes in the body are set:
        <!-- angular versions must be the same! -->
        <!--[if gte IE 9]> -->
        <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular.min.js"></script>
        <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular-cookies.min.js"></script>
        <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.4.8/angular-animate.min.js"></script>
        <script src="https://cdn.socket.io/socket.io-1.3.6.js"></script>
        <script src="/js/main.js"></script>
        <!-- <![endif]-->

My code and the fiddle linked work both in IE9 and IE11 and all the other major browsers.

I let my Windows 8 software update (on the VM) and now it's working.

Closing as it seems there's no issue. Sounds more like a temporary network or jsFiddle issue.
Feel free to reopen if there is any indication there might be a permanent error with Angular.

I think it was more connected to Windows 8 and the version of IE10 on Windows 8. In any case if anyone stumbles upon this, update your VM Windows to fix this.


Divide by zero error

I searched for a string (ପାଟନା) then clicked on one of the resulting links, and got this:
<IP_ADDRESS> - - [16/Jul/2019 23:25:00] INFO: Saving annotations for IL11_NW_020884_20150525_J00410O4L.conll.txt
<IP_ADDRESS> - - [16/Jul/2019 23:25:00] "POST /save HTTP/1.1" 200 -
<IP_ADDRESS> - - [16/Jul/2019 23:25:00] "POST /save HTTP/1.1" 200 -
<IP_ADDRESS> - - [16/Jul/2019 23:25:00] "GET /IL11_NW_021146_20160921_J00410QQL.conll.txt HTTP/1.1" 500 -
<IP_ADDRESS> - - [16/Jul/2019 23:25:00] "GET /IL11_NW_021146_20160921_J00410QQL.conll.txt HTTP/1.1" 500 -
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2309, in call
return self.wsgi_app(environ, start_response)
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2295, in wsgi_app
response = self.handle_exception(e)
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1741, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/site-packages/flask/_compat.py", line 35, in reraise
raise value
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2292, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1815, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1718, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/site-packages/flask/_compat.py", line 35, in reraise
raise value
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1813, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1799, in dispatch_request
return self.view_functionsrule.endpoint
File "/Users/mayfield/Documents/Projects/dragonfly/dragonfly/views.py", line 48, in view
content = dr.render(app, filename, file_index)
File "/Users/mayfield/Documents/Projects/dragonfly/dragonfly/renderer.py", line 96, in render
row.set_suggestions([freqs.get_percentage(x) for x in row.strings])
File "/Users/mayfield/Documents/Projects/dragonfly/dragonfly/renderer.py", line 96, in
row.set_suggestions([freqs.get_percentage(x) for x in row.strings])
File "/Users/mayfield/Documents/Projects/dragonfly/dragonfly/recommend.py", line 258, in get_percentage
return self.corpus_data.tagged_counts[word] / self.corpus_data.counts[word]
ZeroDivisionError: division by zero
<IP_ADDRESS> - - [16/Jul/2019 23:25:00] "GET /IL11_NW_021146_20160921_J00410QQL.conll.txt?debugger=yes&cmd=resource&f=style.css HTTP/1.1" 200 -

I thought I fixed that before I left tonight. Have you pulled recently?

I blew away all the .dragonfly files, restarted everything, and finally got it working again. But apparently there was a pull I missed, so maybe that will help prevent it from happening again.


Tbman

Fix #67

Implement TBMAN
Implement partial register for clock

Then machine.freq() works as expected.

Awesome, thanks!


Add WineHQ's Wine Build

[X] I have checked that this app does not already have a pending request and has not previously been declined.
App Name: Wine
Download URL: https://wiki.winehq.org/Ubuntu
Website URL: https://www.winehq.org/
App Summary: Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD.

Hi, I'm not entirely sure if this fully fits with the acceptable, but I thought it'd be better to have a definitive rejection if it's not the case.
The reason why I am submitting this is because many guides for gaming on Linux recommends installing Wine build from WineHQ, especially Wine-Staging, and I recall a few guides mentioning pairing Lutris with Wine-Staging as well.
I'd just thought that given both Lutris and CrossOver is here, it might be worth it to add WineHQ's build given how commonly recommended it is, especially as I recall Ubuntu's build is generally outdated, especially for gaming.
If it falls outside of the bound of what's accepted or an exception cannot be made, feel free to close the issue, and thank you for your time regardless.

i have no idea how i missed this, can i assume it's within scope?

Closed by #632


Add IVLE function fetch_role

Features

Add a function in the IVLE module to check the role of the user

While waiting for confirmation as to what role each 'Permission' key in the response JSON corresponds to, I'm assuming O means owner, S is student, and everything in-between is staff.

Refactor the private api_url and api_fetch functions

Had to make them more flexible since some api methods received token as parameter Token, while others used AuthToken.

Todos

Will add this logic in Cadet.Accounts.register/2 after review and merge.

Pull Request Test Coverage Report for Build 525

12 of 12 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 96.923%

Totals

Change from base Build 519:
0.08%

Covered Lines:
315

Relevant Lines:
325

💛  - Coveralls

@ningyuansg Sorry, I was on mobile, merged the wrong PR. Could you help re-create the PR?

Done with #76


Improve logging of input test or provide debugging options

Here, there is an 'attribute error' parsing some part of the yaml input, but it is not clear where the error is in the yaml.

@aih could you provide us with the test yaml file which produced such an error?
@BorodaUA seems like the problem with the skipping JSON path if path leads into the list. Could you please check such a case:
data:
{"a": [{"b": 1}, {"c": 2}]}

and we should skip path:
a.0.b

I thought we had such test case in our self_tests directory. Aren't we?

Unfortunately, I deleted the branch where I had the yaml. I added a check that local_data is an object before using get, but we may want to add types so that we can catch these issues earlier?

Hi team 👋
@alexbojko I've looked into our skips, we can skip element in list with no problem, also we can skip in nested lists, and yes we have running test to check that.
@aih We will need steps to reproduce to find the issue, as of right now it is not clear how to find the error.

I'll close for now and will reopen or open a new issue if we see this again.


How to update items in dropdown/selector based on another cells value?

Hi there,
I am using the SelectTypePlugin() to add a dropdown/selector to revogrid columns. Would it be possible to update the items in the dropdown/selector based on another cells value?
        {
            prop: "type",
            name: "Type",
            source: ["Volume", "Mass", "Length"]
            columnType: "select",
        },
        {
            prop: "units",
            name: "Units",
            source: ["ml, "L", "g", "kg", "m", "km"]
            columnType: "select",
        }

For instance, if for the Type column Volume is selected only the items mL and L should appear in the Units column. Accordingly if Mass is selected only g and kg should be listed, etc...
I was hoping for a callbach function similiar to how the readonly key can be adjusted for a single cell like it was described in issue #323. However, it seems that the source key only accepts a list and not a function (source code).
Is there a workaround to archive the desired result or do you think it might be important enough to implement the callback function logic for one of the next releases?
Thanks,
Christian

Please post issue in @revolist/revogrid repo


loss_box always bigger than rpn_loss_box

As in the title, can we conclude that rcnn isn't really useful for bbox regression?

I am getting better accuracy without using bbox_regression (bbox_pred) and using only rpn_bbox_pred on my dataset.


Remove bluebird dependency.

Requires #70

@paulmillr this project has a lock file that needs to be up to date all the time.
If you want to remove it let me know.


Create a Standup bot for Telegram group

We need a bot on Telegram that allow us to record / dispose our online standup meetings done using Telegram.
More requirements will be added to this ticket.

Closing as this one belongs to a different project


change title on all pages

change title to all pages, currently only index.html have been changed

that is right, take care of it right away

Thank you , change has been made @mengyanl


Yolov7 performance bad - 10 FPS only on Orin AGX 64 GB

I followed the Yolov7 tutorial here.
Exported the onnx from the official pt file. Adjusted the paths in the config files. It successfully built the engine, but I'm getting 10 FPS only (compared to the promised >100).
Here is the output after conversion:
WARNING: [TRT]: If this is not the desired behavior, please modify the weights or retrain with regularization to adjust the magnitude of the weights.
WARNING: [TRT]: Check verbose logs for the list of affected weights.
WARNING: [TRT]: - 82 weights are affected by this issue: Detected subnormal FP16 values.
WARNING: [TRT]: - 2 weights are affected by this issue: Detected values less than smallest positive FP16 subnormal value and converted them to the FP16 minimum subnormalized value.
0:40:28.444976296 26592 0xaaaad0efc090 INFO                 nvinfer gstnvinfer.cpp:680:gst_nvinfer_logger:<primary_gie> NvDsInferContext[UID 1]: Info from NvDsInferContextImpl::buildModel() <nvdsinfer_context_impl.cpp:1955> [UID = 1]: serialize cuda engine to file: /home/nvidia/Documents/yolo_deepstream/deepstream_yolo/yolov7.onnx_b16_gpu0_fp16.engine successfully
INFO: [FullDims Engine Info]: layers num: 2
0   INPUT  kFLOAT images          3x640x640       min: 1x3x640x640     opt: 16x3x640x640    Max: 16x3x640x640
1   OUTPUT kFLOAT output          25200x85        min: 0               opt: 0               Max: 0
...
**PERF:  9.78 (9.76)	9.62 (9.60)	9.63 (9.61)	9.78 (9.76)	9.64 (9.62)	9.62 (9.60)	9.63 (9.61)	9.63 (9.61)	9.78 (9.76)	9.63 (9.61)	9.78 (9.76)	10.20 (10.17)	9.78 (9.76)	9.63 (9.61)	9.78 (9.76)	9.78 (9.76)
**PERF:  10.11 (9.89)	10.11 (9.81)	10.11 (9.81)	10.11 (9.89)	10.11 (9.82)	10.11 (9.81)	10.11 (9.81)	10.11 (9.81)	10.11 (9.89)	10.11 (9.81)	10.11 (9.89)	10.11 (10.08)	10.11 (9.89)	10.11 (9.81)	10.11 (9.89)	10.11 (9.89)
**PERF:  10.11 (10.00)	10.11 (9.95
Have I exported the onnx incorrecly or might I have missed sth.?

I had
num-sources=16
even though I just wanted 1 source..

Just a question again:
I'm getting ~60FPS now on an Orin AGX 64 GB in MAXN mode with the following config:
config_infer_primary_yolov7.txt:
[property]
gpu-id=0
net-scale-factor=0.0039215697906911373
#0=RGB, 1=BGR
model-color-format=0
model-engine-file=yolov7_dy.onnx_b16_gpu0_fp16.engine
#model-engine-file=yolov7_1280.onnx_b1_gpu0_fp16.engine
#model-engine-file=/home/nvidia/Documents/yolo_deepstream/deepstream_yolo/yolov7.onnx_b16_gpu0_fp16.engine
#onnx-file=yolov7_dy.onnx
#onnx-file=yolov7_1280.onnx
labelfile-path=labels.txt
0=FP32, 1=INT8, 2=FP16 mode
network-mode=2
num-detected-classes=80
gie-unique-id=1
network-type=0
is-classifier=0
1=DBSCAN, 2=NMS, 3= DBSCAN+NMS Hybrid, 4 = None(No clustering)
cluster-mode=2
maintain-aspect-ratio=1
symmetric-padding=1
Bilinear Interpolation
scaling-filter=1
#parse-bbox-func-name=NvDsInferParseCustomYoloV7
parse-bbox-func-name=NvDsInferParseCustomYoloV7_cuda
#disable-output-host-copy=0
disable-output-host-copy=1
custom-lib-path=nvdsinfer_custom_impl_Yolo/libnvdsinfer_custom_impl_Yolo.so
#scaling-compute-hw=0
start from DS6.2
crop-objects-to-roi-boundary=1
[class-attrs-all]
#nms-iou-threshold=0.3
#threshold=0.7
nms-iou-threshold=0.65
pre-cluster-threshold=0.25
topk=300
and
[application]
enable-perf-measurement=1
perf-measurement-interval-sec=5
#gie-kitti-output-dir=streamscl
[tiled-display]
enable=0
rows=1
columns=1
width=1280
height=720
gpu-id=0
#(0): nvbuf-mem-default - Default memory allocated, specific to particular platform
#(1): nvbuf-mem-cuda-pinned - Allocate Pinned/Host cuda memory, applicable for Tesla
#(2): nvbuf-mem-cuda-device - Allocate Device cuda memory, applicable for Tesla
#(3): nvbuf-mem-cuda-unified - Allocate Unified cuda memory, applicable for Tesla
#(4): nvbuf-mem-surface-array - Allocate Surface Array memory, applicable for Jetson
nvbuf-memory-type=0
[source0]
enable=1
#Type - 1=CameraV4L2 2=URI 3=MultiURI
type=3
uri=file:/opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4
num-sources=1
gpu-id=0
(0): memtype_device   - Memory type Device
(1): memtype_pinned   - Memory type Host Pinned
(2): memtype_unified  - Memory type Unified
cudadec-memtype=0
[sink0]
enable=1
#Type - 1=FakeSink 2=EglSink 3=File
type=2
sync=0
source-id=0
gpu-id=0
nvbuf-memory-type=0
#1=mp4 2=mkv
container=1
#1=h264 2=h265
codec=1
output-file=yolov4.mp4
[osd]
enable=1
gpu-id=0
border-width=1
text-size=12
text-color=1;1;1;1;
text-bg-color=0.3;0.3;0.3;1
font=Serif
show-clock=0
clock-x-offset=800
clock-y-offset=820
clock-text-size=12
clock-color=1;0;0;0
nvbuf-memory-type=0
[streammux]
gpu-id=0
##Boolean property to inform muxer that sources are live
live-source=0
batch-size=1
##time out in usec, to wait after the first buffer is available
##to push the batch even if the complete batch is not formed
batched-push-timeout=40000
Set muxer output width and height
width=1280
height=720
##Enable to maintain aspect ratio wrt source, and allow black borders, works
##along with width, height properties
enable-padding=0
nvbuf-memory-type=0
config-file property is mandatory for any gie section.
Other properties are optional and if set will override the properties set in
the infer config file.
[primary-gie]
enable=1
gpu-id=0
labelfile-path=labels.txt
batch-size=1
#Required by the app for OSD, not a plugin property
bbox-border-color0=1;0;0;1
bbox-border-color1=0;1;1;1
bbox-border-color2=0;0;1;1
bbox-border-color3=0;1;0;1
interval=0
gie-unique-id=1
nvbuf-memory-type=0
#config-file=config_infer_primary_yoloV4.txt
config-file=config_infer_primary_yoloV7.txt
[tracker]
enable=0
For NvDCF and DeepSORT tracker, tracker-width and tracker-height must be a multiple of 32, respectively
tracker-width=640
tracker-height=384
ll-lib-file=/opt/nvidia/deepstream/deepstream/lib/libnvds_nvmultiobjecttracker.so
ll-config-file required to set different tracker types
ll-config-file=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_tracker_IOU.yml
ll-config-file=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_tracker_NvDCF_perf.yml
ll-config-file=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_tracker_NvDCF_accuracy.yml
ll-config-file=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_tracker_DeepSORT.yml
gpu-id=0
enable-batch-process=1
enable-past-frame=1
display-tracking-id=1
[tests]
file-loop=0
Have I missed a config? Advertised is 120FPS.


[Clean up] Remove getColumnName() from AggregationFunction interface

getColumnName() is only used in the data schema of the server side aggregation results. Since we are not using the column name in the AggregationDataTableReducer (broker side reduce), we can safely remove it.

Codecov Report

Merging #10431 (9406ceb) into master (11b6bcd) will decrease coverage by 28.02%.
The diff coverage is 16.66%.

@@              Coverage Diff              @@
##             master   #10431       +/-   ##
=============================================
- Coverage     63.23%   35.21%   -28.02%
+ Complexity     5068      282     -4786
=============================================
  Files          2028     2053       +25
  Lines        110632   111358      +726
  Branches      16847    16938       +91
=============================================
- Hits          69955    39215    -30740
- Misses        35505    68737    +33232
+ Partials       5172     3406     -1766

Flag
Coverage Δ

integration1
24.54% <16.66%> (+0.15%)
:arrow_up:

integration2
24.36% <16.66%> (+0.04%)
:arrow_up:

unittests1
?

unittests2
13.85% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...n/function/BaseSingleInputAggregationFunction.java
41.66% <ø> (-35.26%)
:arrow_down:

...aggregation/function/CountAggregationFunction.java
48.14% <ø> (-28.69%)
:arrow_down:

...gregation/function/CountMVAggregationFunction.java
0.00% <ø> (-100.00%)
:arrow_down:

...gation/function/CovarianceAggregationFunction.java
0.00% <ø> (-66.67%)
:arrow_down:

...n/FirstDoubleValueWithTimeAggregationFunction.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...on/FirstFloatValueWithTimeAggregationFunction.java
0.00% <ø> (-100.00%)
:arrow_down:

...tion/FirstIntValueWithTimeAggregationFunction.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ion/FirstLongValueWithTimeAggregationFunction.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/FirstStringValueWithTimeAggregationFunction.java
0.00% <ø> (-100.00%)
:arrow_down:

...on/LastDoubleValueWithTimeAggregationFunction.java
0.00% <0.00%> (-97.30%)
:arrow_down:

... and 15 more

... and 1417 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more