Extended elapsed time

Describe the bug
see screen snapshot

Steps to reproduce
run beta.5
Node logs
see log

Platform(s)
Linux (x86)
What version/commit are you on?
beta.5
What database version are you on?
beta.5
What type of node are you running?
Full via --full flag
What prune config do you use, if any?
No response
If you've built Reth from source, provide the full command you used
No response
Code of Conduct

[X] I agree to follow the Code of Conduct

Can you please show the logs from ~/.cache/reth/logs/mainnet/reth.log?

2024-04-09T13:59:01.361106Z DEBUG blockchain_tree: Committing new canonical chain: [(19618534, 0x81b40181caacde9718c1a04844f15e09c15542261e99360646dad789e7993b91)]
2024-04-09T13:59:01.362641Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618534, 0x81b40181caacde9718c1a04844f15e09c15542261e99360646dad789e7993b91)]
2024-04-09T13:59:01.398947Z DEBUG providers::db: Inserted block block_number=19618534 actions=[(InsertCanonicalHeaders, 57.223µs), (InsertHeaders, 27.304µs), (InsertHeaderNumbers, 62.668µs), (GetParentTD, 1.165µs), (InsertHeaderTerminalDifficulties, 14.907µs), (GetNextTxNum, 5.893µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 824.134µs), (InsertTransactionHashNumbers, 35.146442ms), (InsertBlockWithdrawals, 39.372µs), (InsertBlockBodyIndices, 28.965µs), (InsertTransactionBlocks, 31.09µs)]
2024-04-09T13:59:01.514674Z DEBUG providers::db: Appended blocks range=19618534..=19618534 actions=[(InsertBlock, 36.290391ms), (InsertState, 13.630383ms), (InsertHashes, 59.893247ms), (InsertHistoryIndices, 42.161858ms), (UpdatePipelineStages, 22.085µs)]
2024-04-09T13:59:01.554464Z DEBUG storage::db::mdbx: Commit total_duration=39.774118ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 16, audit: 0, write: 0, sync: 2588, ending: 0, whole: 2605, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T13:59:01.554491Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 19.015µs), (FindCanonicalHeader, 14.092µs), (SplitChain, 1.701µs), (SplitChainForks, 1.072µs), (MergeAllChains, 1.138µs), (UpdateCanonicalIndex, 3.953µs), (RetrieveStateTrieUpdates, 1.545516ms), (CommitCanonicalChainToDatabase, 191.834429ms)]
2024-04-09T13:59:01.554531Z DEBUG consensus::engine: Canonicalized new head hash=0x81b40181caacde9718c1a04844f15e09c15542261e99360646dad789e7993b91 number=19618534
2024-04-09T13:59:01.554583Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:01.554592Z  INFO reth_node_core::events::node: Canonical chain committed number=19618534 hash=0x81b40181caacde9718c1a04844f15e09c15542261e99360646dad789e7993b91 elapsed=193.458237ms
2024-04-09T13:59:13.035797Z DEBUG blockchain_tree: Appending block to canonical chain head=0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013 parent=(19618534, 0x81b40181caacde9718c1a04844f15e09c15542261e99360646dad789e7993b91)
2024-04-09T13:59:13.165199Z DEBUG evm: Execution time evm_transact=127.236009ms apply_state=446.968µs apply_post_state=7.495µs merge_transitions=358.046µs receipt_root=896.069µs
2024-04-09T13:59:13.166230Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=328
2024-04-09T13:59:14.137158Z DEBUG blockchain_tree::chain: Validated state root number=19618535 hash=0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013 elapsed=971.945505ms
2024-04-09T13:59:14.137261Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-04-09T13:59:14.137294Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618535 hash=0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013 peers=100 txs=183 mgas=11.655 full=38.8% base_fee=37.95gwei blobs=0 excess_blobs=0 elapsed=1.114892433s
2024-04-09T13:59:14.337915Z DEBUG blockchain_tree: Committing new canonical chain: [(19618535, 0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013)]
2024-04-09T13:59:14.340557Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618535, 0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013)]
2024-04-09T13:59:14.402525Z DEBUG providers::db: Inserted block block_number=19618535 actions=[(InsertCanonicalHeaders, 78.744µs), (InsertHeaders, 41.808µs), (InsertHeaderNumbers, 84.212µs), (GetParentTD, 1.918µs), (InsertHeaderTerminalDifficulties, 19.519µs), (GetNextTxNum, 6.821µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 1.324177ms), (InsertTransactionHashNumbers, 59.631817ms), (InsertBlockWithdrawals, 36.975µs), (InsertBlockBodyIndices, 31.937µs), (InsertTransactionBlocks, 31.728µs)]
2024-04-09T13:59:14.577693Z DEBUG providers::db: Appended blocks range=19618535..=19618535 actions=[(InsertBlock, 61.352892ms), (InsertState, 18.799691ms), (InsertHashes, 92.366928ms), (InsertHistoryIndices, 63.930597ms), (UpdatePipelineStages, 51.451µs)]
2024-04-09T13:59:14.631603Z DEBUG storage::db::mdbx: Commit total_duration=53.893138ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 14, audit: 0, write: 0, sync: 3512, ending: 0, whole: 3527, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T13:59:14.631635Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 23.255µs), (FindCanonicalHeader, 14.401µs), (SplitChain, 2.497µs), (SplitChainForks, 1.42µs), (MergeAllChains, 1.3µs), (UpdateCanonicalIndex, 5.115µs), (RetrieveStateTrieUpdates, 2.70051ms), (CommitCanonicalChainToDatabase, 291.013707ms)]
2024-04-09T13:59:14.631672Z DEBUG consensus::engine: Canonicalized new head hash=0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013 number=19618535
2024-04-09T13:59:14.631725Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:14.631752Z  INFO reth_node_core::events::node: Canonical chain committed number=19618535 hash=0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013 elapsed=293.806594ms
2024-04-09T13:59:25.194775Z DEBUG blockchain_tree: Appending block to canonical chain head=0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3 parent=(19618535, 0x754bf05324e3ff94d6f7ac866657d2e1941ecc5dc26683ac770e9b768ea92013)
2024-04-09T13:59:25.345552Z DEBUG evm: Execution time evm_transact=148.992472ms apply_state=372.721µs apply_post_state=8.192µs merge_transitions=249.89µs receipt_root=810.681µs
2024-04-09T13:59:25.346862Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=260
2024-04-09T13:59:26.098861Z DEBUG blockchain_tree::chain: Validated state root number=19618536 hash=0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3 elapsed=753.294478ms
2024-04-09T13:59:26.098969Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-04-09T13:59:26.098993Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618536 hash=0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3 peers=100 txs=144 mgas=10.422 full=34.7% base_fee=36.89gwei blobs=6 excess_blobs=0 elapsed=917.030315ms
2024-04-09T13:59:26.282929Z DEBUG blockchain_tree: Committing new canonical chain: [(19618536, 0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3)]
2024-04-09T13:59:26.284750Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618536, 0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3)]
2024-04-09T13:59:26.335323Z DEBUG providers::db: Inserted block block_number=19618536 actions=[(InsertCanonicalHeaders, 62.452µs), (InsertHeaders, 19.982µs), (InsertHeaderNumbers, 45.506µs), (GetParentTD, 1.107µs), (InsertHeaderTerminalDifficulties, 13.49µs), (GetNextTxNum, 5.548µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 1.221048ms), (InsertTransactionHashNumbers, 48.949608ms), (InsertBlockWithdrawals, 35.887µs), (InsertBlockBodyIndices, 32.689µs), (InsertTransactionBlocks, 30.013µs)]
2024-04-09T13:59:26.492712Z DEBUG providers::db: Appended blocks range=19618536..=19618536 actions=[(InsertBlock, 50.478881ms), (InsertState, 17.662776ms), (InsertHashes, 87.968463ms), (InsertHistoryIndices, 51.712439ms), (UpdatePipelineStages, 25.65µs)]
2024-04-09T13:59:26.534051Z DEBUG storage::db::mdbx: Commit total_duration=41.322465ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 13, audit: 0, write: 0, sync: 2687, ending: 0, whole: 2701, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T13:59:26.534081Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 20.375µs), (FindCanonicalHeader, 12.836µs), (SplitChain, 2.141µs), (SplitChainForks, 1.057µs), (MergeAllChains, 1.067µs), (UpdateCanonicalIndex, 4.015µs), (RetrieveStateTrieUpdates, 1.829923ms), (CommitCanonicalChainToDatabase, 249.314354ms)]
2024-04-09T13:59:26.534111Z DEBUG consensus::engine: Canonicalized new head hash=0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3 number=19618536
2024-04-09T13:59:26.534162Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:26.534169Z  INFO reth_node_core::events::node: Canonical chain committed number=19618536 hash=0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3 elapsed=251.225412ms
2024-04-09T13:59:36.998674Z DEBUG blockchain_tree: Appending block to canonical chain head=0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519 parent=(19618536, 0x357e6b6810dee0571c2151d285bf35fa5ca36b95961c6f1ac4ce0f2699caa8f3)
2024-04-09T13:59:37.242840Z DEBUG evm: Execution time evm_transact=239.748565ms apply_state=1.05118ms apply_post_state=7.544µs merge_transitions=746.7µs receipt_root=2.17275ms
2024-04-09T13:59:37.244841Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=553
2024-04-09T13:59:38.946742Z DEBUG blockchain_tree::chain: Validated state root number=19618537 hash=0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519 elapsed=1.703888417s
2024-04-09T13:59:38.946903Z DEBUG pruner: Minimum pruning interval reached previous_tip_block_number=Some(19618531) tip_block_number=19618536
2024-04-09T13:59:38.946938Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618537 hash=0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519 peers=100 txs=317 mgas=29.987 full=100.0% base_fee=35.48gwei blobs=3 excess_blobs=3 elapsed=1.953025466s
2024-04-09T13:59:38.946945Z DEBUG consensus::engine::hooks: Polled next hook hook="Prune" result=PolledHook { name: "Prune", event: Started, db_access_level: ReadWrite }
2024-04-09T13:59:38.946956Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:38.947013Z DEBUG pruner: Pruner started tip_block_number=19618536
2024-04-09T13:59:38.947056Z DEBUG pruner: Segment pruning started segment=Transactions purpose=StaticFile to_block=19618454 prune_mode=Before(19618455)
2024-04-09T13:59:38.947093Z DEBUG pruner: Segment pruning finished segment=Transactions purpose=StaticFile to_block=19618454 prune_mode=Before(19618455) output.pruned=0
2024-04-09T13:59:38.947101Z  INFO reth_node_core::events::node: Pruner started tip_block_number=19618536
2024-04-09T13:59:38.947102Z DEBUG pruner: Segment pruning started segment=Headers purpose=StaticFile to_block=19618454 prune_mode=Before(19618455)
2024-04-09T13:59:38.947106Z DEBUG pruner: Segment pruning finished segment=Headers purpose=StaticFile to_block=19618454 prune_mode=Before(19618455) output.pruned=0
2024-04-09T13:59:38.947108Z DEBUG pruner: Segment pruning started segment=Receipts purpose=User to_block=11052983 prune_mode=Before(11052984)
2024-04-09T13:59:38.947112Z DEBUG pruner: Segment pruning finished segment=Receipts purpose=User to_block=11052983 prune_mode=Before(11052984) output.pruned=0
2024-04-09T13:59:38.947115Z DEBUG pruner: Nothing to prune for the segment segment=ContractLogs purpose=User
2024-04-09T13:59:38.947117Z DEBUG pruner: Segment pruning started segment=SenderRecovery purpose=User to_block=19618536 prune_mode=Full
2024-04-09T13:59:38.954822Z DEBUG providers::db: Pruning limit reached limiter=PruneLimiter { deleted_entries_limit: Some(PruneDeletedEntriesLimit { limit: 17500, deleted: 17500 }), time_limit: Some(PruneTimeLimit { limit: 100ms, start: Instant { tv_sec: 341640, tv_nsec: 730750418 } }) } deleted_entries_limit=true time_limit=false table=TransactionSenders
2024-04-09T13:59:38.954967Z DEBUG pruner: Segment pruning finished segment=SenderRecovery purpose=User to_block=19618536 prune_mode=Full output.pruned=17500
2024-04-09T13:59:38.956572Z DEBUG storage::db::mdbx: Commit total_duration=1.597524ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 2, audit: 0, write: 0, sync: 101, ending: 0, whole: 103, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T13:59:38.956588Z DEBUG pruner: Pruner interrupted and has more data to prune tip_block_number=19618536 elapsed=9.550583ms deleted_entries=17500 limiter=PruneLimiter { deleted_entries_limit: Some(PruneDeletedEntriesLimit { limit: 17500, deleted: 17500 }), time_limit: Some(PruneTimeLimit { limit: 100ms, start: Instant { tv_sec: 341640, tv_nsec: 730750418 } }) } progress=HasMoreData(DeletedEntriesLimitReached) stats={SenderRecovery: (HasMoreData(DeletedEntriesLimitReached), 17500)}
2024-04-09T13:59:38.956607Z DEBUG consensus::engine::hooks: Polled running hook with db write access hook="Prune" result=PolledHook { name: "Prune", event: Finished(Ok(())), db_access_level: ReadWrite }
2024-04-09T13:59:38.956619Z  INFO reth_node_core::events::node: Pruner finished tip_block_number=19618536 elapsed=9.550583ms stats={SenderRecovery: (HasMoreData(DeletedEntriesLimitReached), 17500)}
2024-04-09T13:59:38.956775Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:39.157641Z DEBUG blockchain_tree: Committing new canonical chain: [(19618537, 0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519)]
2024-04-09T13:59:39.161423Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618537, 0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519)]
2024-04-09T13:59:39.288493Z DEBUG providers::db: Inserted block block_number=19618537 actions=[(InsertCanonicalHeaders, 41.629µs), (InsertHeaders, 31.703µs), (InsertHeaderNumbers, 34.117µs), (GetParentTD, 913ns), (InsertHeaderTerminalDifficulties, 10.92µs), (GetNextTxNum, 5.45µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 18.673253ms), (InsertTransactionHashNumbers, 108.080696ms), (InsertBlockWithdrawals, 28.183µs), (InsertBlockBodyIndices, 17.978µs), (InsertTransactionBlocks, 23.489µs)]
2024-04-09T13:59:39.621198Z DEBUG providers::db: Appended blocks range=19618537..=19618537 actions=[(InsertBlock, 127.051681ms), (InsertState, 33.47367ms), (InsertHashes, 179.331225ms), (InsertHistoryIndices, 119.852325ms), (UpdatePipelineStages, 27.184µs)]
2024-04-09T13:59:39.708942Z DEBUG storage::db::mdbx: Commit total_duration=87.72686ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 102, audit: 0, write: 0, sync: 5639, ending: 5, whole: 5748, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T13:59:39.708968Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 21.903µs), (FindCanonicalHeader, 11.233µs), (SplitChain, 2.345µs), (SplitChainForks, 1.332µs), (MergeAllChains, 1.447µs), (UpdateCanonicalIndex, 5.314µs), (RetrieveStateTrieUpdates, 3.796423ms), (CommitCanonicalChainToDatabase, 547.528066ms)]
2024-04-09T13:59:39.708994Z DEBUG consensus::engine: Canonicalized new head hash=0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519 number=19618537
2024-04-09T13:59:39.709026Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-04-09T13:59:39.709122Z  INFO reth_node_core::events::node: Canonical chain committed number=19618537 hash=0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519 elapsed=551.400925ms
2024-04-09T13:59:49.044150Z DEBUG blockchain_tree: Appending block to canonical chain head=0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b parent=(19618537, 0x15e4bdc943b30bb20d98c5b4557fc92d69adcfca753f766208f4840b383a1519)
2024-04-09T13:59:49.167894Z DEBUG evm: Execution time evm_transact=121.858587ms apply_state=442.2µs apply_post_state=7.105µs merge_transitions=340.024µs receipt_root=960.217µs
2024-04-09T13:59:49.168885Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=253
2024-04-09T13:59:50.130848Z DEBUG blockchain_tree::chain: Validated state root number=19618538 hash=0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b elapsed=962.941013ms
2024-04-09T13:59:50.130985Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:50.131013Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618538 hash=0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b peers=100 txs=117 mgas=11.762 full=39.2% base_fee=39.91gwei blobs=0 excess_blobs=3 elapsed=1.089502567s
2024-04-09T13:59:50.318276Z DEBUG blockchain_tree: Committing new canonical chain: [(19618538, 0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b)]
2024-04-09T13:59:50.320096Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618538, 0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b)]
2024-04-09T13:59:50.360936Z DEBUG providers::db: Inserted block block_number=19618538 actions=[(InsertCanonicalHeaders, 50.275µs), (InsertHeaders, 18.325µs), (InsertHeaderNumbers, 31.709µs), (GetParentTD, 955ns), (InsertHeaderTerminalDifficulties, 9.407µs), (GetNextTxNum, 5.387µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 1.182774ms), (InsertTransactionHashNumbers, 39.373673ms), (InsertBlockWithdrawals, 37.47µs), (InsertBlockBodyIndices, 31.423µs), (InsertTransactionBlocks, 29.902µs)]
2024-04-09T13:59:50.518984Z DEBUG providers::db: Appended blocks range=19618538..=19618538 actions=[(InsertBlock, 40.825524ms), (InsertState, 15.952588ms), (InsertHashes, 85.765939ms), (InsertHistoryIndices, 56.286369ms), (UpdatePipelineStages, 23.516µs)]
2024-04-09T13:59:50.562434Z DEBUG storage::db::mdbx: Commit total_duration=43.432776ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 15, audit: 0, write: 0, sync: 2824, ending: 1, whole: 2841, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T13:59:50.562461Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 20.582µs), (FindCanonicalHeader, 12.04µs), (SplitChain, 1.582µs), (SplitChainForks, 1.067µs), (MergeAllChains, 1.114µs), (UpdateCanonicalIndex, 3.391µs), (RetrieveStateTrieUpdates, 1.831455ms), (CommitCanonicalChainToDatabase, 242.349794ms)]
2024-04-09T13:59:50.562486Z DEBUG consensus::engine: Canonicalized new head hash=0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b number=19618538
2024-04-09T13:59:50.562518Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-04-09T13:59:50.562642Z  INFO reth_node_core::events::node: Canonical chain committed number=19618538 hash=0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b elapsed=244.25391ms
2024-04-09T13:59:59.577248Z DEBUG blockchain_tree: Appending block to canonical chain head=0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3 parent=(19618538, 0x88535a2db5f891f89833a8636d5fd9c5302fdb7c254652d91db7c157c961125b)
2024-04-09T13:59:59.623518Z DEBUG evm: Execution time evm_transact=45.31121ms apply_state=143.677µs apply_post_state=9.856µs merge_transitions=85.969µs receipt_root=294.703µs
2024-04-09T13:59:59.623881Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=109
2024-04-09T13:59:59.979390Z DEBUG blockchain_tree::chain: Validated state root number=19618539 hash=0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3 elapsed=355.858376ms
2024-04-09T13:59:59.979464Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T13:59:59.979500Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618539 hash=0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3 peers=100 txs=56 mgas=3.584 full=11.9% base_fee=38.84gwei blobs=6 excess_blobs=0 elapsed=414.250887ms
2024-04-09T14:00:00.146365Z DEBUG blockchain_tree: Committing new canonical chain: [(19618539, 0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3)]
2024-04-09T14:00:00.146938Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618539, 0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3)]
2024-04-09T14:00:00.165954Z DEBUG providers::db: Inserted block block_number=19618539 actions=[(InsertCanonicalHeaders, 48.57µs), (InsertHeaders, 20.346µs), (InsertHeaderNumbers, 31.018µs), (GetParentTD, 1.104µs), (InsertHeaderTerminalDifficulties, 10.47µs), (GetNextTxNum, 5.169µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 378.406µs), (InsertTransactionHashNumbers, 18.33865ms), (InsertBlockWithdrawals, 34.302µs), (InsertBlockBodyIndices, 30.493µs), (InsertTransactionBlocks, 27.297µs)]
2024-04-09T14:00:00.222873Z DEBUG providers::db: Appended blocks range=19618539..=19618539 actions=[(InsertBlock, 18.960048ms), (InsertState, 5.340879ms), (InsertHashes, 35.860871ms), (InsertHistoryIndices, 15.675023ms), (UpdatePipelineStages, 24.447µs)]
2024-04-09T14:00:00.244724Z DEBUG storage::db::mdbx: Commit total_duration=21.833381ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 10, audit: 0, write: 0, sync: 1416, ending: 0, whole: 1427, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T14:00:00.244751Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 17.235µs), (FindCanonicalHeader, 9.567µs), (SplitChain, 1.514µs), (SplitChainForks, 1.06µs), (MergeAllChains, 1.319µs), (UpdateCanonicalIndex, 3.073µs), (RetrieveStateTrieUpdates, 582.147µs), (CommitCanonicalChainToDatabase, 97.799468ms)]
2024-04-09T14:00:00.244785Z DEBUG consensus::engine: Canonicalized new head hash=0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3 number=19618539
2024-04-09T14:00:00.244860Z  INFO reth_node_core::events::node: Canonical chain committed number=19618539 hash=0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3 elapsed=98.456395ms
2024-04-09T14:00:00.244925Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-04-09T14:00:13.229139Z DEBUG blockchain_tree: Appending block to canonical chain head=0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467 parent=(19618539, 0x89324b364d5ebce2c17e4a95f167b00bcbdc54f81a4b00f26bb5d27f65d38ab3)
2024-04-09T14:00:13.606938Z DEBUG evm: Execution time evm_transact=370.838271ms apply_state=2.017438ms apply_post_state=8.684µs merge_transitions=1.008716ms receipt_root=2.871373ms
2024-04-09T14:00:13.609281Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=712
2024-04-09T14:00:15.930108Z DEBUG blockchain_tree::chain: Validated state root number=19618540 hash=0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467 elapsed=2.323157314s
2024-04-09T14:00:15.930447Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T14:00:15.930498Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618540 hash=0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467 peers=100 txs=419 mgas=29.997 full=100.0% base_fee=35.14gwei blobs=0 excess_blobs=3 elapsed=2.726967122s
2024-04-09T14:00:16.139957Z DEBUG blockchain_tree: Committing new canonical chain: [(19618540, 0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467)]
2024-04-09T14:00:16.147906Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618540, 0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467)]
2024-04-09T14:00:16.294043Z DEBUG providers::db: Inserted block block_number=19618540 actions=[(InsertCanonicalHeaders, 70.128µs), (InsertHeaders, 26.164µs), (InsertHeaderNumbers, 67.801µs), (GetParentTD, 1.528µs), (InsertHeaderTerminalDifficulties, 16.561µs), (GetNextTxNum, 7.473µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 4.059655ms), (InsertTransactionHashNumbers, 141.629712ms), (InsertBlockWithdrawals, 44.47µs), (InsertBlockBodyIndices, 33.495µs), (InsertTransactionBlocks, 33.436µs)]
2024-04-09T14:00:16.701797Z DEBUG providers::db: Appended blocks range=19618540..=19618540 actions=[(InsertBlock, 146.11326ms), (InsertState, 49.044764ms), (InsertHashes, 222.827914ms), (InsertHistoryIndices, 135.840745ms), (UpdatePipelineStages, 21.966µs)]
2024-04-09T14:00:16.827292Z DEBUG storage::db::mdbx: Commit total_duration=125.478801ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 31, audit: 0, write: 0, sync: 8183, ending: 3, whole: 8218, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T14:00:16.827318Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 20.579µs), (FindCanonicalHeader, 14.947µs), (SplitChain, 2.17µs), (SplitChainForks, 1.276µs), (MergeAllChains, 1.242µs), (UpdateCanonicalIndex, 4.281µs), (RetrieveStateTrieUpdates, 7.965164ms), (CommitCanonicalChainToDatabase, 679.391499ms)]
2024-04-09T14:00:16.827342Z DEBUG consensus::engine: Canonicalized new head hash=0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467 number=19618540
2024-04-09T14:00:16.827372Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-04-09T14:00:16.827448Z  INFO reth_node_core::events::node: Canonical chain committed number=19618540 hash=0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467 elapsed=687.433525ms
2024-04-09T14:00:25.232244Z DEBUG blockchain_tree: Appending block to canonical chain head=0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5 parent=(19618540, 0x52886c1e3c5fbe7e116b040637d30f2bc50ba5bb6c718dc82659492d14e19467)
2024-04-09T14:00:25.594997Z DEBUG evm: Execution time evm_transact=358.018947ms apply_state=1.096105ms apply_post_state=9.222µs merge_transitions=1.208103ms receipt_root=2.054191ms
2024-04-09T14:00:25.597696Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=521
2024-04-09T14:00:27.445808Z DEBUG blockchain_tree::chain: Validated state root number=19618541 hash=0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5 elapsed=1.85079654s
2024-04-09T14:00:27.446014Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T14:00:27.446041Z  INFO reth_node_core::events::node: Block added to canonical chain number=19618541 hash=0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5 peers=100 txs=271 mgas=29.970 full=99.9% base_fee=39.53gwei blobs=6 excess_blobs=0 elapsed=2.219097101s
2024-04-09T14:00:27.664466Z DEBUG blockchain_tree: Committing new canonical chain: [(19618541, 0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5)]
2024-04-09T14:00:27.670515Z DEBUG blockchain_tree: Using cached trie updates blocks=[(19618541, 0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5)]
2024-04-09T14:00:27.770925Z DEBUG providers::db: Inserted block block_number=19618541 actions=[(InsertCanonicalHeaders, 65.004µs), (InsertHeaders, 33.788µs), (InsertHeaderNumbers, 58.39µs), (GetParentTD, 1.266µs), (InsertHeaderTerminalDifficulties, 15.141µs), (GetNextTxNum, 6.081µs), (InsertTransactionSenders, 0ns), (InsertTransactions, 5.08191ms), (InsertTransactionHashNumbers, 94.950634ms), (InsertBlockWithdrawals, 32.171µs), (InsertBlockBodyIndices, 27.912µs), (InsertTransactionBlocks, 29.147µs)]
2024-04-09T14:00:28.067991Z DEBUG providers::db: Appended blocks range=19618541..=19618541 actions=[(InsertBlock, 100.390897ms), (InsertState, 34.076689ms), (InsertHashes, 146.900538ms), (InsertHistoryIndices, 116.049161ms), (UpdatePipelineStages, 20.301µs)]
2024-04-09T14:00:28.136204Z DEBUG storage::db::mdbx: Commit total_duration=68.196367ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 55, audit: 0, write: 0, sync: 4402, ending: 6, whole: 4464, gc_cputime: 15, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T14:00:28.136231Z DEBUG blockchain_tree: Canonicalization finished actions=[(CloneOldBlocks, 27.921µs), (FindCanonicalHeader, 12.198µs), (SplitChain, 2.417µs), (SplitChainForks, 1.926µs), (MergeAllChains, 1.705µs), (UpdateCanonicalIndex, 5.139µs), (RetrieveStateTrieUpdates, 6.066164ms), (CommitCanonicalChainToDatabase, 465.69607ms)]
2024-04-09T14:00:28.136264Z DEBUG consensus::engine: Canonicalized new head hash=0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5 number=19618541
2024-04-09T14:00:28.136312Z DEBUG pruner: Minimum pruning interval reached previous_tip_block_number=Some(19618536) tip_block_number=19618541
2024-04-09T14:00:28.136361Z  INFO reth_node_core::events::node: Canonical chain committed number=19618541 hash=0xb2c2555dfacc57bb062eb30b10b4e1ddcbb3c8cc4af47c642de7a99179a1e9d5 elapsed=471.854056ms
2024-04-09T14:00:28.136376Z DEBUG consensus::engine::hooks: Polled next hook hook="Prune" result=PolledHook { name: "Prune", event: Started, db_access_level: ReadWrite }
2024-04-09T14:00:28.136388Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"
2024-04-09T14:00:28.136506Z  INFO reth_node_core::events::node: Pruner started tip_block_number=19618541
2024-04-09T14:00:28.136488Z DEBUG pruner: Pruner started tip_block_number=19618541
2024-04-09T14:00:28.136547Z DEBUG pruner: Segment pruning started segment=Transactions purpose=StaticFile to_block=19618454 prune_mode=Before(19618455)
2024-04-09T14:00:28.136627Z DEBUG pruner: Segment pruning finished segment=Transactions purpose=StaticFile to_block=19618454 prune_mode=Before(19618455) output.pruned=0
2024-04-09T14:00:28.136637Z DEBUG pruner: Segment pruning started segment=Headers purpose=StaticFile to_block=19618454 prune_mode=Before(19618455)
2024-04-09T14:00:28.136643Z DEBUG pruner: Segment pruning finished segment=Headers purpose=StaticFile to_block=19618454 prune_mode=Before(19618455) output.pruned=0
2024-04-09T14:00:28.136645Z DEBUG pruner: Segment pruning started segment=Receipts purpose=User to_block=11052983 prune_mode=Before(11052984)
2024-04-09T14:00:28.136822Z DEBUG pruner: Segment pruning finished segment=Receipts purpose=User to_block=11052983 prune_mode=Before(11052984) output.pruned=0
2024-04-09T14:00:28.136827Z DEBUG pruner: Nothing to prune for the segment segment=ContractLogs purpose=User
2024-04-09T14:00:28.136848Z DEBUG pruner: Segment pruning started segment=SenderRecovery purpose=User to_block=19618541 prune_mode=Full
2024-04-09T14:00:28.146123Z DEBUG providers::db: Pruning limit reached limiter=PruneLimiter { deleted_entries_limit: Some(PruneDeletedEntriesLimit { limit: 17500, deleted: 17500 }), time_limit: Some(PruneTimeLimit { limit: 100ms, start: Instant { tv_sec: 341689, tv_nsec: 920232996 } }) } deleted_entries_limit=true time_limit=false table=TransactionSenders
2024-04-09T14:00:28.146148Z DEBUG pruner: Segment pruning finished segment=SenderRecovery purpose=User to_block=19618541 prune_mode=Full output.pruned=17500
2024-04-09T14:00:28.147973Z DEBUG storage::db::mdbx: Commit total_duration=1.817931ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 2, audit: 0, write: 0, sync: 112, ending: 0, whole: 115, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-04-09T14:00:28.147996Z DEBUG pruner: Pruner interrupted and has more data to prune tip_block_number=19618541 elapsed=11.475912ms deleted_entries=17500 limiter=PruneLimiter { deleted_entries_limit: Some(PruneDeletedEntriesLimit { limit: 17500, deleted: 17500 }), time_limit: Some(PruneTimeLimit { limit: 100ms, start: Instant { tv_sec: 341689, tv_nsec: 920232996 } }) } progress=HasMoreData(DeletedEntriesLimitReached) stats={SenderRecovery: (HasMoreData(DeletedEntriesLimitReached), 17500)}
2024-04-09T14:00:28.148064Z  INFO reth_node_core::events::node: Pruner finished tip_block_number=19618541 elapsed=11.475912ms stats={SenderRecovery: (HasMoreData(DeletedEntriesLimitReached), 17500)}
2024-04-09T14:00:28.148064Z DEBUG consensus::engine::hooks: Polled running hook with db write access hook="Prune" result=PolledHook { name: "Prune", event: Finished(Ok(())), db_access_level: ReadWrite }
2024-04-09T14:00:28.148206Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"

intel nuc 10 i7
32GB RAM...
Model Number:                       Corsair MP400
Firmware Version:                   ECFM53.0
PCI Vendor/Subsystem ID:            0x1987
IEEE OUI Identifier:                0x6479a7
Total NVM Capacity:                 4,000,787,030,016 [4.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          4,000,787,030,016 [4.00 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            6479a7 5b700000a1
Local Time is:                      Tue Apr  9 16:28:28 2024 CEST

What disk do you have?

Your disk is a QLC NVMe, it might be I/O?

$ sar 5 10
Linux 6.5.0-27-generic 	04/21/2024 	x86_64	(12 CPU)
04:09:35 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
04:09:40 PM     all     11.95      0.00      1.53      2.48      0.00     84.04
04:09:45 PM     all      9.03      0.00      1.17      0.65      0.00     89.15
04:09:50 PM     all     10.63      0.00      1.39      0.80      0.00     87.18
04:09:55 PM     all     12.80      0.00      1.18      0.59      0.00     85.43
04:10:00 PM     all      6.69      0.00      1.12      0.52      0.00     91.67
04:10:05 PM     all     12.02      0.00      2.06      2.88      0.00     83.05
04:10:10 PM     all      9.24      0.00      1.04      0.90      0.00     88.81
04:10:15 PM     all     10.43      0.00      2.07      5.16      0.00     82.35
04:10:20 PM     all      8.76      0.00      1.22      0.82      0.00     89.20
04:10:25 PM     all      7.92      0.00      0.94      1.90      0.00     89.24
Average:        all      9.94      0.00      1.37      1.67      0.00     87.02
$

It is clear to me the I/O has an impact.. another almost identical node (but w/ a better I/O sync'ed far faster and doesnt have those same delays as above (all sub-500ms)... that said, it does seem like an area for efficiency gains to reduce the I/O where possible.


chore: update fastify to ^5.0.0

See  https://github.com/fastify/fastify/issues/5694

Checklist

[x] run npm run test and npm run benchmark
[x] commit message and code follows the Developer's Certification of Origin
and the Code of conduct

@Fdawgs can you take a look at why this is failing?

Issue is that the dist/cjs/index.js file built when running build:cjs has ESM Module import syntax in it:
"use strict";
import { TypeCompiler } from '@sinclair/typebox/compiler';
import { Value } from '@sinclair/typebox/value';
export * from '@sinclair/typebox';
export const TypeBoxValidatorCompiler = ({ schema, httpPart }) => {
    const typeCheck = TypeCompiler.Compile(schema);
    return (value) => {
        const converted = httpPart === 'body' ? value : Value.Convert(schema, value);
        if (typeCheck.Check(converted)) {
            return { value: converted };
        }
        const errors = [...typeCheck.Errors(converted)];
        return {
            error: errors.map((error) => ({
                message: `${error.message}`,
                instancePath: error.path
            }))
        };
    };
};

The build tools haven't changed since the last succesful release: https://github.com/fastify/fastify-type-provider-typebox/actions/runs/10698067891/job/29656641884
Still TypeScript 5.4.5 >:(

Yep, if i pin typescript to 5.4.5 instead of ^5.4.5 then it's fine.

I recommend always use ~ for TypeScript since TypeScript use x.y as major version and .z for patch.


 order sequence matters

[Enter feedback here]
As per TaskPaneAppVersionOverridesV1_0.xsd
sequence order of <Runtimes> matters which is not mentioned in the documentation. 2 has incorrect schema.

1

 <VersionOverrides xmlns="http://schemas.microsoft.com/office/taskpaneappversionoverrides" xsi:type="VersionOverridesV1_0">
    <Hosts>
      <Host xsi:type="Workbook">
        <Runtimes> 👈
          <Runtime resid="Taskpane.Url" lifetime="long" />
        </Runtimes>
        <DesktopFormFactor>...</DesktopFormFactor>
      </Host>
    </Hosts>
</VersionOverrides>

2

 <VersionOverrides xmlns="http://schemas.microsoft.com/office/taskpaneappversionoverrides" xsi:type="VersionOverridesV1_0">
    <Hosts>
      <Host xsi:type="Workbook">
        <DesktopFormFactor>...</DesktopFormFactor>
         <Runtimes> 👈
          <Runtime resid="Taskpane.Url" lifetime="long" />
        </Runtimes>
      </Host>
    </Hosts>
</VersionOverrides>

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3a1bb1ec-f7c0-61c7-bd50-4018a2726e3a
Version Independent ID: dabd68f4-f474-1f01-0022-b2fe55eaafa3
Content: Configure your Office Add-in to use a shared JavaScript runtime - Office Add-ins
Content Source: docs/develop/configure-your-add-in-to-use-a-shared-runtime.md
Product: non-product-specific
Technology: add-ins
GitHub Login: @o365devx
Microsoft Alias: o365devx

Thanks for reporting this @tharshada.
@davidchesnut, can you please investigate the runtime manifest documentation?


templateUser = kuberos / frontend manually shows email

Not sure which is the right answer here but your front end "authenticate manually section" shows the users configured id, where as when you get your kubecfg file, it will be kuberos, which raises the bar for quick and simple credentials updates, and a little sloppy, not sure which you prefer, but possibly using one in both places.
As always thanks for everything!

Good point! I think that's a historical artifact - I used to use someusername everywhere, but then changed to kuberos. Happy to change it for consistency - any preference?

fixed by merging #20


Not an issue, but would you be able to provide api docs?

Hi, this isn't an issue per se, but, do you still have, and would you be able to provide musescore's api documentation?
Or rather, what url and parameters are used in downloading the files? (pdf, mszc etc)
Lastly, thanks for your contributions to the community really agree with your ideals that these scores should not be paid unless the transcriber wants it to be so.

They took down the API docs after this repository gained some traction, however it is archived at https://web.archive.org/web/20200117065437/https://developers.musescore.com/ :)

They did not only take down the API docs, but the API itself, so the docs above won't help you much.
I think he is asking for docs for the unofficial API.


Dockerfile

It would be great, to have a Dockerfile for easy deployment and testing. I have created an example image on docker hub with an open Dockerfile in github:
https://hub.docker.com/r/devsecur/robot-attack/

To be honest I have no clue how to create or use a dockerfile.
Can I just link what you made and you'll keep it up to date?

Sure. Feel free to copy or reference the Dockerfile I made. I would let my repository stay on github, so the image can be build automaticly on docker hub.
You can use the image by installing Docker and then run
docker run devsecur/robot-attack python robot-detect.py <HOST>

If anyone interested in the alpine based minimal docker, here's my try:
https://github.com/ilyaglow/robot-detect/blob/alpine-based-docker/Dockerfile
Usage example:
docker run -it --rm ilyaglow/robot-detect google.com

Ah perfect, thank you. Your image is quite cleaner - I would use this as official Dockerfile for this project.

ok, so it's just this file that is needed? can you make a pull request and add a sentence to the README.md how to run it?

also I'll try to create a pip package, it's just something that I pushed down my todo list in light of more important tasks.

It may be best to use the python:3.6-alpine image on dockerhub, instead of tsutomu7/scientific-python from "some random user?" Probably a smaller footprint, as well.

I think ilyaglow already provide an alpine based image:
https://github.com/ilyaglow/robot-detect/blob/alpine-based-docker/Dockerfile


feat(action): allow to use a custom token for cloning the repository

Hi @allenporter,
I would like to add the option to pass a token for the checkout (this is required if the repository is not public)
The suggestion from @szinn in #353 does not seem to work, I have tested this one and it worked for me.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e76c0fe) 93.45% compared to head (7731153) 93.45%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #502   +/-   ##
=======================================
  Coverage   93.45%   93.45%
=======================================
  Files          19       19
  Lines        1972     1972
=======================================
  Hits         1843     1843
  Misses        129      129

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

have updated it to fallback to ${github.token} (default from the checkout action) as input is optional

closing this one as resolved in #353

Thanks @tyriis for getting this moving!


ERR_RATE_LIMIT_fix

Use a millisecond resolution during the ring buffer sleeps, seems like bitfinex operate on a per sec basis rather than 60(90?) per minute.
This change allows us to send requests every X milliseconds to get around that.
The MA module is also adapted to catch the exception and increase the delay. It means that if the bot is running for a while it will find the exact ms value that should be used. This is useful as everyone has different set ups, so what is too fast for one person may be just right for another.
Defaults to 850ms per request.
Description

TESTING STAGE

Testing on both exchanges currently
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have read CONTRIBUTING.md
[x] I fully understand Github Flow.
[x] My code adheres to the code style of this project.
[N/A] I have updated the documentation in /docs if I have changed the config, arguments, logic in how the bot works, or anything that understandably needs a documentation change.
[N/A] I have updated the config file accordingly if my change requires a new configuration setting or changes an existing one.
[ ] I have tested the bot with no issues for 24 continuous hours. If issues were experienced, they have been patched and tested again.

Just documenting. Only the important parts of my log:
Long  higher: Short higher: Cur:BTC, MACD:0.000111, Perc:0.000122, Best:0.000107
Short higher: Error in returning data from exchange: HTTPSConnectionPool(host='api.bitfinex.com', port=443): Read timed out. (read timeout=30) Requesting https://api.bitfinex.com/v1/lendbook/BCH?limit_asks=3&limit_bids=3
Long  higher: Cur:ETH, MACD:0.000049, Perc:0.000049, Best:0.000045
Long  higher: Long  higher: Cur:BCH, MACD:0.000044, Perc:0.000043, Best:0.000041
...
Short higher: Short higher: Cur:BTC, MACD:0.000091, Perc:0.000085, Best:0.000085
Short higher: Caught ERR_RATE_LIMIT, sleeping capture and reducing request rate. Current 51/min
Short higher: Cur:ETH, MACD:0.000046, Perc:0.000044, Best:0.000043
Short higher: Short higher: Cur:BCH, MACD:0.000037, Perc:0.000034, Best:0.000035
...
Long  higher: Short higher: Cur:BTC, MACD:0.000082, Perc:0.000080, Best:0.000078
Short higher: 2017-09-29 04:16:37 Error Error retrieving ticker for btcusd: HTTPSConnectionPool(host='api.bitfinex.com', port=443): Read timed out. (read timeout=30) Requesting https://api.bitfinex.com/v1/pubticker/btcusd. Continue with next currency.
Error in returning data from exchange: HTTPSConnectionPool(host='api.bitfinex.com', port=443): Max retries exceeded with url: /v1/lendbook/BCH?limit_asks=3&limit_bids=3 (Caused by ConnectTimeoutError(<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fc21c1796d0>, 'Connection to api.bitfinex.com timed out. (connect timeout=30)')) Requesting https://api.bitfinex.com/v1/lendbook/BCH?limit_asks=3&limit_bids=3
Short higher: Cur:ETH, MACD:0.000046, Perc:0.000045, Best:0.000044
Short higher: Long  higher: Cur:BCH, MACD:0.000033, Perc:0.000034, Best:0.000030
...
Long  higher: Long  higher: Cur:BCH, MACD:0.000042, Perc:0.000043, Best:0.000038
Long  higher: Long  higher: Cur:BTC, MACD:0.000087, Perc:0.000087, Best:0.000078
Long  higher: Caught ERR_RATE_LIMIT, sleeping capture and reducing request rate. Current 54/min
Caught ERR_RATE_LIMIT, sleeping capture and reducing request rate. Current 54/min
Caught ERR_RATE_LIMIT, sleeping capture and reducing request rate. Current 54/min
Long  higher: Cur:ETH, MACD:0.000053, Perc:0.000053, Best:0.000046
Long  higher: Caught API Error 429: { "error": "ERR_RATE_LIMIT"} Requesting https://api.bitfinex.com/v1/lendbook/ETH?limit_asks=100&limit_bids=100 from exchange, ignoring.
Long  higher: Cur:ETH, MACD:0.000053, Perc:0.000053, Best:0.000046
Long  higher: Caught API Error 429: { "error": "ERR_RATE_LIMIT"} Requesting https://api.bitfinex.com/v1/lendbook/ETH?limit_asks=100&limit_bids=100 from exchange, ignoring.
Long  higher: Cur:ETH, MACD:0.000053, Perc:0.000053, Best:0.000046
Long  higher: Caught API Error 429: { "error": "ERR_RATE_LIMIT"} Requesting https://api.bitfinex.com/v1/lendbook/ETH?limit_asks=100&limit_bids=100 from exchange, ignoring.
Long  higher: Cur:ETH, MACD:0.000053, Perc:0.000053, Best:0.000046
Long  higher: Long  higher: Cur:BCH, MACD:0.000041, Perc:0.000041, Best:0.000038

That's the previous version I think @utdrmac
I made a number of updates since that.

Ok. Pulled recent. https://ghostbin.com/paste/ezjrd

Noticed a side-effect, ctrl-c has an extreme difficulty stopping the bot. In fact, I usually have to ctrl-z and kill -9 the script

@utdrmac It's just the number of threads running I think. It should exit eventually.
@MoonMaker If you really want to stress it, you can add a load of coins to anaylse. Though you'll almost definitely hit the error. It should sort itself out eventually though I think, but it's not really an intended scenario.

Why not handle all the logic inside the Bitfinex module?

I just want to let you know this patch is working flawless! I'm using it since 48 hours on test account with 5 cryptos on it.
During my testing i have found only one error and i'm not sure if its connected to ERR_RATE_LIMIT or not, but here it is:
Lent: [0.8605 BTC @ 0.0218%] [2.1506 ETH @ 0.0041%] [46.7946 LTC @ 0.0165%] [0.5186 ZEC @ 0.0239%] Caught ERR_RATE_LIMIT, sleeping capture and increasing request delay. Current 1003ms
Caught ERR_RATE_LIMIT, sleeping capture and increasing request delay. Current 1006ms
Caught ERR_RATE_LIMIT, sleeping capture and increasing request delay. Current 1009ms
2017-10-05 09:24:44 Canceling LTC order... Loan offer canceled (10.2154 @ 0.0100%).
2017-10-05 09:24:45 Canceling ETH order... Loan offer canceled (0.2483 @ 0.0040%).
2017-10-05 09:24:46 Canceling XMR order... Loan offer canceled (4.4325 @ 0.0043%).
2017-10-05 09:24:48 Canceling BTC order... Loan offer canceled (0.1407 @ 0.0213%).
Lent: [0.8605 BTC @ 0.0218%] [2.1506 ETH @ 0.0041%] [46.7946 LTC @ 0.0165%] [0.5186 ZEC @ 0.0239%] ZEC : Need more data for analysis, still collecting. I have 222/270 records
Caught exception during MACD analysis, using percentile for now
2017-10-05 09:24:50 Error API Error 429: { "error": "ERR_RATE_LIMIT"} Requesting https://api.bitfinex.com/v1/lendbook/ZEC?limit_asks=100&limit_bids=100
2017-10-05 09:24:50 Error IP has been banned due to many requests. Sleeping for 130.0 seconds
Lent: [0.8605 BTC @ 0.0218%] [2.1506 ETH @ 0.0041%] [46.7946 LTC @ 0.0165%] [0.5186 ZEC @ 0.0239%] Traceback (most recent call last):
File "lendingbot.py", line 128, in
if api.req_period <= self.api.default_req_period * 1.5:
NameError: name 'self' is not defined
After this issue bot use to hanged up :(

Right, I think this is done. @rnevet can you have a look?

@laxdog looks good, there are some conflicts with master currently.


Makefile

Makefile to generate the charts based on the python notebook, other options are available but not fully tested.
This PR also deletes the no longer needed python script that were previously used to generate the charts.
Part of #51.

Pulled out the notebook part, but I think the remainder depends on #43.

@hugo-dc I've trimmed this down so we can merge it. Can you create a new PR which adds the run_benchmarks script for scout-engines and adds it to the makefile?


Add a note about building containers manually

Per some customer questions, we can add a guide for building the containers from the provided Dockerfiles.
I'm building now using the commands I used in the README and will validate that they work. Feedback on terminology or accuracy of the build stages is appreciated.

note: tests do not need to run on this documentation-only PR so I canceled the compute-heavy ones.


Upgrade DaisyUI to the new major release

What would you like to share?
DaisyUI just released a new major version (3.0.0): https://daisyui.com/
We should upgrade our frontend version (2.51.5) to use the new version.
There are some breaking changes, make sure to check the changelog (https://daisyui.com/docs/changelog/)
Additional information
No response

Submitted a pull request to address this issue.

Closed https://github.com/origranot/reduced.to/pull/413

@izdotnet Hey!
Unfortunately I had to revert to the old DaisyUI version because the new DaisyUI is broken.
I came across some weird issues, I think we should wait a bit for more stable version.

@izdotnet Hey!
Unfortunately I had to revert to the old DaisyUI version because I came across some weird issues. I think we should wait for some new releases or at least for a much more stable version.

I did some thorough testing, and I couldn't replicate any bugs on my end.
It's worth it to wait for a more stable version though.

@izdotnet It looks that DaisyUI became more stable.
Do you want to try update it?

I wish to work on this issue. Kindly assign me this.

I wish to work on this issue. Kindly assign me this.

@saku1331
Alight, I assigned you to it.
Please make sure to see the old PR https://github.com/origranot/reduced.to/pull/413
I reverted it because the new version of DaisyUI wasn't stable at the time.

@saku1331 Any updates regarding to this PR?


Add CROSS_CONTAINER_OPTS environment variable.

Rename DOCKER_OPTS to CROSS_CONTAINER_OPTS, and currently prefer CROSS_CONTAINER_OPTS to DOCKER_OPTS, although both are still valid.
Closes #770.

Currently a draft since #771 will require changing how we parse the values here.

ping @otavio

bors r=Emilgardis


Removing As Background Setting to Square Aspect Ratio

Bug Description
Clicking “Remove as background” resets the element to a square aspect ratio (should reset to proper aspect ratio instead). This is only happening when setting as a background via dragging onto the mask zone.
Expected Behaviour
The aspect ratio should not be altered after removing as a background.
Steps to Reproduce

Drag a video onto the masking portion of a page to set it as the background
Remove it as a background

Screenshots

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria
QA Instructions

This got addressed with #1798, closing as fixed.


4.9.0 - Release

Total issues resolved: 12

3058: Implement exception class for Gone Http error thanks to @TheKernelPanic
3086: Update slim/psr7 requirement from ^1.3 to ^1.4 thanks to @dependabot[bot]
3087: Update nyholm/psr7-server requirement from ^1.0.1 to ^1.0.2 thanks to @dependabot[bot]
3093: Update phpstan/phpstan requirement from ^0.12.85 to ^0.12.90 thanks to @dependabot[bot]
3099: Allow updated psr log thanks to @t0mmy742
3104: Drop php7.2 thanks to @t0mmy742
3106: Use PSR-17 factory from Guzzle/psr7 2.0 thanks to @t0mmy742
3108: Update README file thanks to @t0mmy742
3112: Update laminas/laminas-diactoros requirement from ^2.6 to ^2.8 thanks to @dependabot[bot]
3114: Update slim/psr7 requirement from ^1.4 to ^1.5 thanks to @dependabot[bot]
3115: Update phpstan/phpstan requirement from ^0.12.96 to ^0.12.99 thanks to @dependabot[bot]
3116: Remove Zend Diactoros references thanks to @l0gicgate

Coverage remained the same at 100.0% when pulling 759a7a3a9a0af40b9ecfcec0528e0af15ad86d94 on 4.9.0-release into b7feb1351cd91108c14bc9bd7886e6d285c97da8 on 4.x.

Changelog.md is not updated with this. Just FYI: https://github.com/slimphp/Slim/blob/4.x/CHANGELOG.md


Can we disable/remove -msse2 flag used while compiling hs2client code?

Hi,
Its been observed that -msse2 flag is used while compiling the code. It is set in CMakeLists.txt file.  We have not found any SSE/Intel specific code available in source code. Can we remove the flag since it is no longer needed?
Please suggest.
Thanks,
Snehlata Mohite.

Seems fine to me. Can you submit a patch?


Feature/close pr

Adding close PR feature as an option instead of failing it

Hey @xalvarez,
Is there any missing or incomplete step|(s) needed to be done ? so we can proceed with the merge

Hey @xalvarez,
Is there any missing or incomplete step|(s) needed to be done ? so we can proceed with the merge

Hi @HasanHajHasan, thanks for your changes! I'm currently on vacation and I can't properly review these changes right now. I'll take care of this PR as soon as I can.


Add a dashboard switch mechanism

This app displays a dashboard in Chromium in kiosk mode.
Adding a mechanism to switch the dashboard on the fly will allow to have more than one dashboard and periodically rotate the current one being displayed.
There may be more than one way to do it, for example https://stackoverflow.com/questions/31340063/how-to-change-url-on-chromium-kiosk-mode-via-ssh

Another possible way is via the commands API: https://stackoverflow.com/questions/30857390/using-the-chrome-commands-api-in-kiosk-mode?rq=3
There may also exist easier options to solve this specific problem: stop the Chromium container and restart with the new URL.

Or also use some sort of process manager inside the container to only restart Chromium https://github.com/just-containers/s6-overlay

The current approach of forcing the container to restart is too dirty, and it seems that for an unknown reason the board reboots after some restarts.
Instead of try to debug the symptom of the dirty approach, let's try to use a more clean one.


RuntimeException-setParameters failed

Cannot init the program(both LinearDetectColor and DetectColor). it shows that
to attempt recovery, please restart the robot
Error: User code threw an uncaught exception
RuntimeExcepetion - setParameters failed
Driver station: Sony Z5
Robot controller: Hongmi

The setParameters method is calling the built in camera setParameters method. This code has only been tested on ZTE Speed phones (as they're the only ones I have). If you're trying to use it on another phone type you may have to modify the parameter setup to accommodate that phone. What type of phone are you using?

@cheer4ftc I have already test XIaomi and Sony. They both give parameter error.

setParameters is used in for_camera_opmodes/OpModeCamera and for_camera_opmodes/LinearOpModeCamera. It is primarily used to set the preview window size on the Robot Controller device. You can try to comment these lines out and see if it still works (it may). If it doesn't work after that, you may have to research yourself as I have no access to Xlaomi or Sony devices. In the US, the Xlaomi and Sony phones are not legal for use in FTC.

@cheer4ftc i thought it might be caused by api 23. I am using android 6.0 to run the robotcontroller. However, in that sdk, android.hardware.camera has been deprecated, and is replacced by camera2.

Even on the ZTE phones, camera has been deprecated but still works (and works better than camera2 in some cases). But yes, I'm not running android 6.0/api23 so I couldn't tell you if that's causing a problem.
Definitely just try commenting out the calls to setParameters in those two files and see what happens, as they're primarily for setting the preview window size.

@cheer4ftc It worked!!! Thank you!!!
//  camera.setParameters(parameters);

Great! Do you see the preview window on the Robot Controller device? Do you see the red, green, or blue Telemetry message on the Driver Station if you run one of the sample opmodes? Note that the color detected is using the Front facing camera (the selfie camera) in the default settings.

Yeah, I can see the image and the telemetry message. I have found out how to change it to back camera.


Remove port exposure for 44158

Issue

Link:
Summary: As helium transition to use light hotspot, there is no more need to expose port 44158

How

Screenshots

References

Checklist

[ ] Tests added
[ ] Cleaned up commit history (rebase!)
[ ] Documentation added
[ ] Thought about variable and method names

There is work needed in hm-config container as well to remove upnp.
Additionally, this shouldn't be removed until the full transition to light is complete IMO and Erlang codebase is completely removed

Think we can pull this in now @KevinWassermann94 ?

Removing 44158 accessibility shouldn't technically negatively affect the hotspot's functionality, but I and others personally use it to be proactively notified when the hotspot goes offline for any reason, by using a service like https://www.port-monitor.com/, which continuously checks for connectivity to that port and sends an email when it becomes inaccessible.
I'd suggest adding a different means of proactive downtime notification, such as through the Nebra Dashboard, before removing 44158 exposure.

@Ryan-Goldstein we already have that kind of monitoring available via the dashboard.
I am not sure this is a good enough reason to leave port 44158 exposed when it doesn't need to be though, frankly. And the extra bloat of using uPnP in config when it is not required anymore.
Could you not just monitor port 80?

@Ryan-Goldstein we already have that kind of monitoring available via the dashboard.
I am not sure this is a good enough reason to leave port 44158 exposed when it doesn't need to be though, frankly. And the extra bloat of using uPnP in config when it is not required anymore.
Could you not just monitor port 80?

I'm referring to more proactive monitoring; as far as I know, the Nebra Dashboard doesn't have the ability to send an email when a hotspot loses connectivity (which would be a great value-add feature making the price more palatable, IMO).
I suppose forwarding and monitoring port 80 instead of 44158 is a reasonable alternative, though I'm not as thrilled about that, as port 80 is extremely commonly scanned 24/7 by bots searching for vulnerabilities to exploit.

@shawaj We surely can if you want me to

@Ryan-Goldstein ahh - i missed the fact you were monitoring it from an external service and not something on your local network, so wouldn't have port 80 exposed outside of your local network.
@KevinWassermann94 - do we have email notifications for when hotspot loses connectivity on the roadmap for dashboard?

@Ryan-Goldstein how do you actually use port 44158?
Do you just ping to see if it's open or something?
I think we can remove upnp and still leave this port open.
I guess that is probably sufficient for your use case as you can just do the port forwarding manually in your router?

@Ryan-Goldstein how do you actually use port 44158?
Do you just ping to see if it's open or something?
I think we can remove upnp and still leave this port open.
I guess that is probably sufficient for your use case as you can just do the port forwarding manually in your router?

I use a service that just checks if the port is open. If https://portchecker.co/ shows 44158 as open, then that'd be sufficient. Thanks!

@Ryan-Goldstein ok great.  We will roll in the upnp removal and if all still works with your method then we are good to go 👌

@Ryan-Goldstein ok great.  We will roll in the upnp removal and if all still works with your method then we are good to go 👌

Of course!

@Ryan-Goldstein ok great.  We will roll in the upnp removal and if all still works with your method then we are good to go 👌

Of course!

@Ryan-Goldstein the UPnP has been removed now.
Can you test if the port checker thing you are doing is still working?

@Ryan-Goldstein ok great.  We will roll in the upnp removal and if all still works with your method then we are good to go 👌

Of course!

@Ryan-Goldstein the UPnP has been removed now.
Can you test if the port checker thing you are doing is still working?

Indeed - it's still working fine!

Awesome. Thanks for your help @Ryan-Goldstein

@Ryan-Goldstein is this still working for you after the latest update?

@Ryan-Goldstein is this still working for you after the latest update?

It is, thanks for checking!

@Ryan-Goldstein are you using BalenaCloud or directly on our OTA?
The latest version should be v1.0.2-2

@shawaj using the built-in/OTA updates.

@shawaj All of my hotspots are online and still running 2<IP_ADDRESS>-28 - possibly the auto-updating mechanism detected that version as later than v1.... and didn't grab the update?

@Ryan-Goldstein are they Nebra hotspots? Which type?

@shawaj Yeah, they are all Nebra Indoor Hotspot Gen 1.

@shawaj Yeah, they are all Nebra Indoor Hotspot Gen 1.

Ah ok, we only pushed the update yesterday evening so may take some time to get the latest update.
I think the 44158 thing may break with this update. The port is still open in the docker-compose.yml but there's nothing listening on it. And have had reports from others that it has stopped working.

For example https://discord.com/channels/859018795262410782/899683146075881544/1097284126857494528

@shawaj Yeah, they are all Nebra Indoor Hotspot Gen 1.

Ah ok, we only pushed the update yesterday evening so may take some time to get the latest update.
I think the 44158 thing may break with this update. The port is still open in the docker-compose.yml but there's nothing listening on it. And have had reports from others that it has stopped working.

I'm not so sure that it's going to update automatically - with prior merges to production, my whole fleet updated within an hour or so. And I think 2<IP_ADDRESS>-28 is a few production versions back at this point?

That's the previous release. We only updated to production yesterday...
https://github.com/NebraLtd/helium-nebra-indoor1/commit/5bc07b5377cfd374da71dac7634cced37ce646bc

Got it, thanks - will keep an eye out and hopefully they'll be updated by tomorrow!

@shawaj None of my Nebra Indoor Hotspot Gen 1 fleet have updated yet. They're all online, deployed all around the US, and still running 2<IP_ADDRESS>-28:

Seems like something may have been overlooked preventing them from updating? If you need it, one of their Ethernet MAC addresses is: 00:BD:27:00:28:E1
Happy to provide any other info you may need!

Seems they are just being slow. But thanks will take a look 😃

Seems they are just being slow. But thanks will take a look 😃

Thanks for taking a look, @shawaj! It has been over 24 hours since the push you linked to (https://github.com/NebraLtd/helium-nebra-indoor1/commit/5bc07b5377cfd374da71dac7634cced37ce646bc), and none of my fleet has updated - all online and still running 2<IP_ADDRESS>-28.
Sorry if I'm being annoying, but with the Solana migration starting in about 20 hours, I (and I'm sure the thousands of other people with Gen 1 Indoor Nebras) would need them updated so they continue working post-migration. 🙂

@shawaj The Solana migration is starting in about 2 hours, and my whole fleet of Gen 1 Indoor Nebras are still on 2<IP_ADDRESS>-28. Would appreciate if you could take a look to see why none of them have updated to v1.0.2-2!

To close the loop, some of my fleet have started updating and are now showing v1.0.2-4. 🍻

To close the loop, some of my fleet have started updating and are now showing v1.0.2-4. 🍻

Awesome, glad to hear they're updating ok 🙂

@Ryan-Goldstein we've heard that 44158 has stopped working so definitely check that and let us know

@Ryan-Goldstein we've heard that 44158 has stopped working so definitely check that and let us know

@shawaj I can confirm that as soon as my hotspots were updated to v1.0.2-4, the remote check for port 44158 accessibility started failing - the port check shows it as closed.
Also have noticed that a RAKv2 firmware update pushed out today also similarly stopped listening on 44158.
Probably a nice-to-have feature if it'd be easy to set up some simple listening service on that port to determine remotely whether it's online, given a proper port forwarding configuration. But getting near-real-time inaccessibility notifications through the Nebra Dashboard (email, push through the Nebra app, etc) or similar would probably work equally well.


Removed timezone enforcement from calendar link

Google's calendar web view can detect one's timezone from browser / OS settings, and this is actually the preferred way to use it to be friendlier to people from non-Pacific timezones.

I signed it


[Hardware][CPU] Support AWQ for CPU backend

This PR added a new ipex_quant configuration to support various weight-only quantization method with IPEX for the CPU backend.
AWQ is supported for now, a basic test is included.

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

Thanks!

Hi @mgoin , would you please help to review this PR? Because I added a platform filter in awq_marlin compatibility checking. Thanks! :)

Hi @mgoin , do you have any further comments about this? I think this PR is ready to go :)
BTW, seems the CPU CI on the main branch is broken due to a new MOE model test and the lack of the AZP epilogue. I disabled the compressed-tensor test and will fix it recently.

Hi @mgoin , looks the tests get green, please help to merge this PR, thanks :)
I'll open a PR for the AZP soon, will let you know for review.


ref/remove_default_aspectratio_from_mediaview

Remove the default aspect ratio of a media view from the native ad properties.   Currently, the default value is provided when the network does not give it.   However, the default value differs from network to network.   The pub should decide the best value for the target network when unavailable.

Why do we not make this change on iOS as well?

Totally forgot about iOS.   Please review it again.


[fix][cli] Quit PerformanceConsumer after receiving numMessages messages

Fixes #17747
Motivation
PerformanceConsumer command line tool does not use its -m flag thus misleading its users.
Modifications
Check the total number of messages received against numMessages if the latter is non-zero.
Added integration test for pulsar-perf tool.
Verifying this change

[x] Make sure that the change passes the CI checks.

This change can be verified as follows:

Added integration test.

Does this pull request potentially affect one of the following parts:
If the box was checked, please highlight the changes

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[ ] The schema
[ ] The default values of configurations
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[ ] Anything that affects deployment

Documentation

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] doc-not-needed
This is a bugfix

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

Matching PR in forked repository
PR in forked repository: https://github.com/andrasbeni/pulsar/pull/3

/pulsarbot rerun-failure-checks

/pulsarbot rerun-failure-checks

Closing and reopening because pulsarbot did not rerun checks


Mal-Sync

Describe your suggested feature
Is it possible to have mal-sync in aniyomi? I also watch anime on my laptop but the battery dies pretty fast. So, it would be pretty convenient if aniyomi knows what timestamp I'm in by using mal-sync. Like, watching from laptop/PC to phone. I don't if it's possible tho.
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I will fill out all of the requested information in this form.

I dont believe MAL saves the timestamp of a specific episode

I dont believe MAL saves the timestamp of a specific episode

Not MAL. Mal-Sync. It's a chrome extension. It automatically updates your MyAnimeList(also kitsu and anilist) when you watch on anime websites. Search it up for more details.

There is no way for the app to communicate with a  browser extension. If it had a public location where it stored the data, then and only then can aniyomi use it. In this case, the connection is MAL, which doesn't support episode save data.
So this feature isn't possible

There is no way for the app to communicate with a browser extension. If it had a public location where it stored the data, then and only then can aniyomi use it. In this case, the connection is MAL, which doesn't support episode save data.
So this feature isn't possible

I see, that's a bummer then. You can close this now


Cannot access "chrome-devtools://devtools/bundled/devtools.html ... manifest must request permission

Hi, I'm trying to use this extension with an external YouTrack site, and this stack trace is occurring:
Unchecked runtime.lastError while running tabs.executeScript: Cannot access contents of url "chrome-devtools://devtools/bundled/devtools.html?&dockSide=undocked&toolbarColor=rgba(223,223,223,1)&textColor=rgba(61,66,68,1)". Extension manifest must request permission to access this host.
    at TogglButton.checkUrl (chrome-extension://cblhgnnnpnonkonnfcfkfhhkoldjpdno/scripts/background.js:206:29)
extensions::sendRequest:82
 handleResponse
extensions::binding:355
 (anonymous function)
background.js:206
 TogglButton.checkUrl
extensions::SafeBuiltins:19
 target.(anonymous function)
extensions::event_bindings:395
 EventImpl.dispatchToListener
extensions::SafeBuiltins:19
 target.(anonymous function)
extensions::utils:94
 $Array.forEach.publicClass.(anonymous function)
extensions::event_bindings:379
 EventImpl.dispatch_
extensions::event_bindings:247
 dispatchArgs
extensions::event_bindings:256
 dispatchEvent

This should be resolved with the updated version of this extension (v<IP_ADDRESS>). Please feel free to reopen this issue if not!


Keyboard shortcuts do not update button status

Try video or audio mute ("c" and "m") and look at the buttons, no change. You can clearly see/hear that the shortcuts work (it's also printed in the console).

Thanks for heads-up – will fix in the next couple of days.
On 25 May 2015 at 04:59, Christoffer Jansson<EMAIL_ADDRESS>wrote:

Assigned #157 https://github.com/webrtc/apprtc/issues/157 to @samdutton
https://github.com/samdutton.
—
Reply to this email directly or view it on GitHub
https://github.com/webrtc/apprtc/issues/157#event-312997496.

In #66, but looks like I already have commits outstanding for adding robots.txt handler.
@jiayliu PTAL to make sure I've done the icon toggle the right way.

Anything more to be done here?

Anything more to be done here?

No.
Pressing C or M keys mute video/audio and change the button icons as expected.

Thanks for fixing!


[Performance]: Delayed Python module load

Describe your changes
[Performance]: Delayed Python module load
Introducing olive_config.json to encapsulates all the different global environment properties to setup olive. Also, merged extra_dependencies.json into olive_config.json.
User can provide a alternative configuration file with the command line argument '--olive-config'.
Instead of loading all modules (specifically passes) at launch, delay the load of modules until after the run config is parsed and load only the ones that are explicitly required.
Moved a few hard-coded dependency management into the olive config.
Deprecation:
Marked command line option '--config' as deprecated. Use '--run-config' instead. NOTE: The deprecated option is still availabe as of now.
Checklist before requesting a review

[ ] Add unit tests for this change.
[ ] Make sure all tests can pass.
[x] Update documents if necessary.
[x] Lint and apply fixes to your code by running lintrunner -a
[x] Is this a user-facing change? If yes, give a description of this change to be included in the release notes.
[ ] Is this PR including examples changes? If yes, please remember to update example documentation in a follow-up PR.

(Optional) Issue link

Instead of loading all modules (specifically passes) at launch, delay the load of modules until after the run config is parsed and load only the ones that are explicitly required.

What's the perf improvement compared with all passes are imported? From the time being, only the pass itself is imported and the dependencies only be imported until run. So, could I suppose the perf improvement is limit? What's the consideration of this PR?

What's the perf improvement number compared with all passes are imported? From the time being, only the pass itself is imported and the dependencies only be imported until run. So, could I suppose the perf improvement is limited? What's the consideration of this PR?

need to understand the consideration or background about why we need the delay load PR.

I don't think one would notice a significant performance gain with this change. All that loading/initialization is one time thing and not a hot path to really show up in any profiles.
Primary motivation for this change -

This approach gives the user a way to add his/her own pass and drive all with data.
Load/initialization time might be small today with the limited passes we have but over time as the list of passes grow this might become significant. This change attempt to preemptively circumvent that scenario.
Passes can now freely include the necessary imports at package level rather than having to be localized in functions and such. Since the packages aren't loaded until a pass needs them, those dependencies won't matter.

@devang-ml can add more.

Can you complete the 5th checklist:  add a description of this change to be included in the release notes.

@guotuofeng Can you review the change please! Thx

the PR looks good to me except above comments. I will let @devang-ml for more comments.


Create the concept of ServiceModule and ResourceModule

ResourceModule has N instances;
ServiceModule has 1 instance.

ResourceModule is requested and distributed by ServiceModule

A ResourceModule has access policies.

For now, the Module System will not cover this abstraction. This kind of abstraction is expected to be easily done with the current API definitions.


Migrate kafka to keda 2.0

Signed-off-by: Harsh Thakur<EMAIL_ADDRESS>Tested this PR out manually

Need to fix this : https://github.com/fission/keda-connectors/issues/44


(%TheTrueLtaker) gen9capconverge: updating bans

%TheTrueLtaker: "updating bans"
Created via Iolanthe on Fri, 07 Apr 2023 22:06:37 GMT.

Already covered by https://github.com/OperationTourCode/OTC/pull/275


Add setting to show Triggers at Table/Views/etc level in DBeaver Database Navigator

DBeaver - Version 4.3.0 CE
DBeaver JDBC driver: Microsoft
Operating System: Windows 7 / Windows 8.1
Database Server: Microsoft SQL Express 2014
Of couse it is a personal preference. But I would like to see a setting in DBeaver that had the effect when set that I could see all database triggers at the same level in the Database Navigator as Tables/Views/etc.
In my SQL Server database, instead of viewing triggers in:
Connection
  Database
    dbo
      Tables
        TableA
          Triggers
            OnTableATrigger
            ...
      Views
      Indexes

I would like to view in Database Navigator (after change of setting) in DBeaver:
Connection
  Database
    dbo
      Tables
      Triggers
        OnTableATrigger
        OnTableBTrigger
        OnTableCTrigger
        ...
      Views
      Indexes

This is already supported for MySQL, Oracle and some other databases.
But not for Generic driver (and SQL Server which uses it).
It is not configurable but works in both ways - you can see triggers under tables AND as global trigger list (in schema).

This feature will be added in the next version.
Note: it'll be a bit slow (as it will read triggers from all underlying tables one by one).


"Free" Lynda course requires a subscription

The README says that Lynda has a free video course, but when I try to watch it, it looks like it needs a credit card for a subscription trial. If there is a way to watch it for free, maybe add specific instructions on how to do that, or indicate that it requires a credit card that will be charged if you don't cancel within 10 days? Even logging in with my LinkedIn account doesn't work.

True (they used to be free, part of a promotion I think) but I've removed the wording anyway.


Make the query engine garbage-collect old values

The query engine versions results, but it does not collect and throw out old, irrelevant values yet. In an incremental context this means infinitely growing memory consumption. We should come up with an API to define a GC strategy.

Strategy: when too big, restart compiler 🤡


DSC should ship Reasons class

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.

Steps to reproduce
PSDSC should ship a Reasons class so each DSC resource module doesn't need to define it. It would also address the issue with Reasons type name conflict issues. Backstory: https://github.com/AnyPackage/AnyPackageDsc/issues/12
Expected behavior
# DSC should ship `Reasons` type.

Actual behavior
# No Reasons type

Error details
No response
Environment data
7.2-preview 2

Version
2.0.6
Visuals
No response

The long-term alternative to this (that I think is more idiomatic, because the implementation of Reasons inherently conflates Get and Test) is to add support for reporting how a DSC Resource is out-of-state via the Test method.
In the short-term, I've been updating the documentation^1 to recommend any module implementing Reasons use the module's name as a prefix in the class name.


directory view filename sorting is not working

fixed by https://github.com/paul-schaaf/vshell/commit/e1ffe905b3922106481ce3cf73e98fb8c9b80134


Bug report: Spinner showing twice on remove commands

Description
When removing something, the spinner shows twice before I even typed the confirm y or n:

This seems to happen with all remove commands.
And it gets even better if you try to resize the terminal a few times:

I'm getting this behavior in both PowerShell and Bash
CLI for Microsoft 365 version
6.3 (next)
nodejs version
16.x
Operating system (environment)
Windows
Shell

PowerShell
Bash on WSL

(In the Windows Terminal)

Great catch @martinlingstuyl! It's even worse for me, I tried to remove a planner plan and I'm not even getting a prompt, the spinner spins forever until I hard kill it.

To me this looks quite problematic for the release tomorrow.

Seems like the confirm is actually prompted, but it's overwritten by the spinner. When I just type 'Y' and hit enter, it works but I never see the prompted message.

At first sight, this can be 'quickly solved' by changing the function prompt in the Cli.ts file to the following:
public static async prompt<T>(options: any): Promise<T> {
    /* c8 ignore next 3 */
    if (Cli.getInstance().spinner.isSpinning) {
      Cli.getInstance().spinner.stop();
    }
    const inquirer: Inquirer = require('inquirer');
    const response = await inquirer.prompt(options) as T;
    const cli = Cli.getInstance();
    // don't show spinner if running tests
    /* c8 ignore next 3 */
    if (typeof global.it === 'undefined') {
      cli.spinner.start();
    }
    return response;
}

I've tested this locally and it seems to be working, however I'm not sure if it's the 'correct way'.

This is how it would look then:

PS: I manually added a delay of 5 seconds to demonstrate.

@MathijsVerbeeck on first sight this seems like a solid fix. Do you want to make a PR of it so we can check it and merge it? Release is tomorrow 😥

Done! 😄

Great catch all!
@martinlingstuyl I don't think there's anything we can do about window resize. Spinners work by writing into the same coordinates and overwriting previous content. When you resize the window, coordinates change and suddenly you're writing elsewhere on the screen.

@MathijsVerbeeck for now this fix will work. For the next release let's update the fix to only start the spinner if it was running before showing the prompt.

@MathijsVerbeeck for now this fix will work. For the next release let's update the fix to only start the spinner if it was running before showing the prompt.

I can include this into the PR immediately if you like.


chore: migrate to @nuxt/kit

Types of changes

[ ] Bug fix (a non-breaking change which fixes an issue)
[ ] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes (if not applicable, please state why)

Hi @benjamincanac, thank you for putting in the work to make the strapi module compatible with nuxt3.
Do you have a rough estimate on when this pr will be ready?

Closing this in favor of #183 merged on dev branch.


Investigate wxWidgets

https://github.com/wxWidgets/wxWidgets
https://github.com/wxFormBuilder/wxFormBuilder

Demo project: https://github.com/wieslawsoltes/BatchEncoderWx

https://github.com/wxWidgets/wxWidgets/blob/master/docs/msw/install.txt