2024-04-15T04:08:04.554200Z DEBUG storage::db::mdbx: Commit total_duration=31.576µs commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 0, audit: 0, write: 0, sync: 0, ending: 0, whole: 1, 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-15T04:08:04.554243Z  INFO reth_node_core::events::node: Preparing stage pipeline_stages=5/12 stage=MerkleUnwind checkpoint=1347968 target=1347968
2024-04-15T04:08:04.554274Z  INFO reth_node_core::events::node: Executing stage pipeline_stages=5/12 stage=MerkleUnwind checkpoint=1347968 target=1347968
2024-04-15T04:08:04.554345Z  INFO sync::stages::merkle::unwind: Stage is always skipped
2024-04-15T04:08:04.554388Z  INFO reth_node_core::events::node: Finished stage pipeline_stages=5/12 stage=MerkleUnwind checkpoint=1347968 target=1347968
2024-04-15T04:08:04.554448Z DEBUG storage::db::mdbx: Commit total_duration=39.72µs commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 0, audit: 0, write: 0, sync: 0, ending: 0, whole: 1, 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-15T04:08:04.554495Z  INFO reth_node_core::events::node: Preparing stage pipeline_stages=6/12 stage=AccountHashing checkpoint=1347944 target=1347968
2024-04-15T04:08:04.554526Z  INFO reth_node_core::events::node: Executing stage pipeline_stages=6/12 stage=AccountHashing checkpoint=1347944 target=1347968
2024-04-15T04:08:04.628341Z  INFO reth_node_core::events::node: Finished stage pipeline_stages=6/12 stage=AccountHashing checkpoint=1347968 target=1347968 stage_progress=100.00%
2024-04-15T04:08:04.738409Z DEBUG storage::db::mdbx: Commit total_duration=110.031148ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 8, audit: 0, write: 0, sync: 6675, ending: 0, whole: 6684, 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-15T04:08:04.738517Z  INFO reth_node_core::events::node: Preparing stage pipeline_stages=7/12 stage=StorageHashing checkpoint=1347944 target=1347968
2024-04-15T04:08:04.738568Z  INFO reth_node_core::events::node: Executing stage pipeline_stages=7/12 stage=StorageHashing checkpoint=1347944 target=1347968
2024-04-15T04:08:04.841253Z  INFO reth_node_core::events::node: Finished stage pipeline_stages=7/12 stage=StorageHashing checkpoint=1347968 target=1347968 stage_progress=100.00%
2024-04-15T04:08:04.990317Z DEBUG storage::db::mdbx: Commit total_duration=149.02702ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 15, audit: 0, write: 0, sync: 9224, ending: 0, whole: 9239, 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-15T04:08:04.990423Z  INFO reth_node_core::events::node: Preparing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=1347944 target=1347968
2024-04-15T04:08:04.990470Z  INFO reth_node_core::events::node: Executing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=1347944 target=1347968
2024-04-15T04:08:04.990534Z DEBUG sync::stages::merkle::exec: Updating trie current=1347944 target=1347968
2024-04-15T04:08:04.990554Z DEBUG trie::loader: incremental state root range=1347945..=1347968
2024-04-15T04:08:05.789365Z  WARN sync::stages::merkle: Failed to verify block state root target_block=1347968 got=0xe87da9fa2117d2479c121daeb04b01c8be5c0f5ec7e9434571a0b156e6a7048d expected=SealedHeader { hash: 0x8d457ec320dd9eb3c7be0ca55b0d227d0680bbe53076e2b7b0a910e3c933a50f, header: Header { parent_hash: 0xf233c10ab77755d9b81a91a38240ce38bdebe19ca12a09d6e5a4f6f7fe4cb52b, ommers_hash: 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, beneficiary: 0x8668b0181b08037079b5c05d53c51361e5b8bd7c, state_root: 0x32b03893c8f80d977556622605c8a5fd4cae36edb98e229dfe4107b4f00b25c0, transactions_root: 0xb3eff2c04b05b07fcf6f89e8ce63a17df9684ff70e37324e07cd3f6c388507d7, receipts_root: 0x4129317a458629f545d09391c07af791a524bfd8bbd8b8248b7e342617e68c1e, withdrawals_root: Some(0x2383c79d88357dcf09c17c7e5f9077c384b697d11b7b98ef1fc6e8b7bc46378a), logs_bloom: 0x0429000008083820000089100005120070410022060ac210048302a4441044080089491510200000944426c804e80200100038259347042860a41104202d1900300843d2802042d40005400bb440802409271822800401206004221b08d12100040e42100a040008200482423018090820805a000a0842300042409020a204c0008062490020400048801841002000cc02c1e4001804400428101211000004200300cc020001040230220801850f0c08a20a10004444402010000026006c828c433820820020150108001020804205001181085a22410008049b14022100e014001040440210041830180510c00841829c058468880023484052000230800500, difficulty: 0x0_U256, number: 1347968, gas_limit: 30000000, gas_used: 16934330, timestamp:<PHONE_NUMBER>, mix_hash: 0x31a95cf04136b4cac1391059b30ef5fadcbcae51a36dbe0765b1bdd7d4be1b93, nonce: 0, base_fee_per_gas: Some(2236729849), blob_gas_used: Some(131072), excess_blob_gas: Some(79560704), parent_beacon_block_root: Some(0xc4de1633830f5c99d232378c8b37b51fe408060b4468fee6484ac8be8c1c950c), extra_data: 0x706170696368756c6f } }
2024-04-15T04:08:05.789443Z ERROR sync::pipeline: Stage encountered a validation error: mismatched block state root: got 0xe87da9fa2117d2479c121daeb04b01c8be5c0f5ec7e9434571a0b156e6a7048d, expected 0x32b03893c8f80d977556622605c8a5fd4cae36edb98e229dfe4107b4f00b25c0 stage=MerkleExecute bad_block=1347968
2024-04-15T04:08:05.789547Z DEBUG storage::db::mdbx: Commit total_duration=17.357µs commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 0, audit: 0, write: 0, sync: 0, ending: 0, whole: 1, 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-15T04:08:05.789601Z DEBUG Unwinding{stage=Finish}: sync::pipeline: Starting unwind from=1347944 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:05.789613Z DEBUG Unwinding{stage=IndexAccountHistory}: sync::pipeline: Starting unwind from=1347944 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:05.789617Z DEBUG Unwinding{stage=IndexStorageHistory}: sync::pipeline: Starting unwind from=1347944 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:05.789621Z DEBUG Unwinding{stage=TransactionLookup}: sync::pipeline: Starting unwind from=1347944 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:05.789624Z DEBUG Unwinding{stage=MerkleExecute}: sync::pipeline: Starting unwind from=1347944 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:05.789628Z DEBUG Unwinding{stage=StorageHashing}: sync::pipeline: Starting unwind from=1347968 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:05.828254Z  INFO Unwinding{stage=StorageHashing}: sync::pipeline: Stage unwound stage=StorageHashing unwind_to=1347944 progress=1347944 done=true
2024-04-15T04:08:06.184898Z DEBUG Unwinding{stage=StorageHashing}: storage::db::mdbx: Commit total_duration=356.610415ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 9, audit: 0, write: 0, sync: 23356, ending: 0, whole: 23366, 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-15T04:08:06.184970Z DEBUG Unwinding{stage=AccountHashing}: sync::pipeline: Starting unwind from=1347968 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:06.208125Z  INFO Unwinding{stage=AccountHashing}: sync::pipeline: Stage unwound stage=AccountHashing unwind_to=1347944 progress=1347944 done=true
2024-04-15T04:08:06.282679Z DEBUG Unwinding{stage=AccountHashing}: storage::db::mdbx: Commit total_duration=74.517682ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 6, audit: 0, write: 0, sync: 4872, ending: 0, whole: 4879, 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-15T04:08:06.282816Z DEBUG Unwinding{stage=MerkleUnwind}: sync::pipeline: Starting unwind from=1347968 to=1347944 bad_block=Some(1347968)
2024-04-15T04:08:06.282833Z DEBUG Unwinding{stage=MerkleUnwind}: trie::loader: incremental state root range=1347945..=1347968
2024-04-15T04:08:06.504810Z  WARN Unwinding{stage=MerkleUnwind}: sync::stages::merkle: Failed to verify block state root target_block=1347944 got=0xd0dd1d687b5905b40e8bdddd6a0c1ecb33de07d74c821d24d61a7ece53e7b5ae expected=SealedHeader { hash: 0x1898bc1d8c13ecd936b0e59257ae849dba9da88acef5b15731ad508733cdc822, header: Header { parent_hash: 0x9378e27ff4b30650e8e561d3a954c8b1afb1720dca999cbf57a0c7d9c1e33a6c, ommers_hash: 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, beneficiary: 0x942a3c0644ed50e3fbc1136f7bffdc505306bde0, state_root: 0xd01ad853ea1a1cc46eaee8d4a72dd46fffc912568dce5a0a9b66eef3af2b4576, transactions_root: 0x5949e0f8a6a9cdb92b863493f423dca1fc5ef8f99c6f8795a0fe3c911ec5c938, receipts_root: 0x92ed0214a8df3cb2070ffe7a231e548cedeedf211e5d96ded41fb0f1b66e5d16, withdrawals_root: Some(0x9bb70698fb705cdb948c74a1a5d5f346f334baeb5b5afb22571be2d78ad7054a), logs_bloom: 0x0002000a48480040208005864000153042a10801040464910e020220007072c36028138040200a00202424a00822408801020001901310068864b58280280f456022820a0065014060000809140000c409088050030401220814301b2489425158160506036010404500008528800c404800c0400818413008492010002040818100000001021810050903418840081a100c221408808210000500850000048193008c080465d02021a8061285830400280a1008c00641049031880680800c80000912c20410005040480000f08485120028001284286a08628ad0040200b81000501048100201102008459240088001b8353000806235081201000211c04534, difficulty: 0x0_U256, number: 1347944, gas_limit: 30000000, gas_used: 10051505, timestamp:<PHONE_NUMBER>, mix_hash: 0xc7f8b6cc90b59bfc9da7d11884a7460495b75546c39032a787a55855ba3681dd, nonce: 0, base_fee_per_gas: Some(2807217650), blob_gas_used: Some(786432), excess_blob_gas: Some(79167488), parent_beacon_block_root: Some(0xc3e6acf8bc5c151afe191348a7ccd8624d433c1e94f8a51a6ad7c64463db7f7a), extra_data: 0x4e65746865726d696e64 } }
2024-04-15T04:08:06.505889Z ERROR reth::cli: shutting down due to error
2024-04-15T04:31:17.867179Z  INFO reth::commands::db::stats: Calculating checksum for table: CanonicalHeaders
2024-04-15T04:31:17.867275Z  INFO reth::commands::db::checksum: Hashed 0 entries.
2024-04-15T04:31:17.867307Z  INFO reth::commands::db::stats: Calculating checksum for table: HeaderTerminalDifficulties
2024-04-15T04:31:17.867331Z  INFO reth::commands::db::checksum: Hashed 0 entries.
2024-04-15T04:31:17.867344Z  INFO reth::commands::db::stats: Calculating checksum for table: HeaderNumbers
2024-04-15T04:31:17.867920Z  INFO reth::commands::db::checksum: Hashed 0 entries.
2024-04-15T04:31:18.265298Z  INFO reth::commands::db::checksum: Hashed 100000 entries.
2024-04-15T04:31:18.654737Z  INFO reth::commands::db::checksum: Hashed 200000 entries.
2024-04-15T04:31:19.042902Z  INFO reth::commands::db::checksum: Hashed 300000 entries.
2024-04-15T04:31:19.421433Z  INFO reth::commands::db::checksum: Hashed 400000 entries.
2024-04-15T04:31:19.799381Z  INFO reth::commands::db::checksum: Hashed 500000 entries.
2024-04-15T04:31:20.176105Z  INFO reth::commands::db::checksum: Hashed 600000 entries.
2024-04-15T04:31:20.571049Z  INFO reth::commands::db::checksum: Hashed 700000 entries.

Here are the logs for reth-issue-7430.2024-04-15. Here is a shu256sum of the above tar.gz file.
Finally here is the --checksum:
2024-04-15T04:48:54.037172Z  INFO Calculating checksum for table: TransactionSenders
2024-04-15T04:48:54.037405Z  INFO Hashed 0 entries.
2024-04-15T04:48:54.037857Z  INFO Calculating checksum for table: StageCheckpoints
2024-04-15T04:48:54.037869Z  INFO Hashed 0 entries.
2024-04-15T04:48:54.037875Z  INFO Calculating checksum for table: StageCheckpointProgresses
2024-04-15T04:48:54.037881Z  INFO Hashed 0 entries.
2024-04-15T04:48:54.037885Z  INFO Calculating checksum for table: PruneCheckpoints
2024-04-15T04:48:54.037891Z  INFO Hashed 0 entries.
2024-04-15T04:48:54.037895Z  INFO Calculating checksum for table: VersionHistory
2024-04-15T04:48:54.038096Z  INFO Hashed 0 entries.
| Table                      | Checksum         | Elapsed         |
|----------------------------|------------------|-----------------|
| CanonicalHeaders           | 4c1ea4e80d047850 | 30.706µs        |
| HeaderTerminalDifficulties | 171f11aa213c31c3 | 16.765µs        |
| HeaderNumbers              | 61e192235f44094e | 5.264605596s    |
| Headers                    | 5efd255180ad7cad | 730.562µs       |
| BlockBodyIndices           | b676857529f2cd83 | 1.418812608s    |
| BlockOmmers                | c4a662e6571c2822 | 451ns           |
| BlockWithdrawals           | 4c97271cfac8ca66 | 16.456802256s   |
| Transactions               | 92a3e3481718cd1d | 59.254157ms     |
| TransactionHashNumbers     | 934608dfc9e80989 |<PHONE_NUMBER>61s  |
| TransactionBlocks          | 2e2c08d5d9962419 | 1.359447083s    |
| Receipts                   | a7a2bbfa2b5cab37 | 23.32384986s    |
| Bytecodes                  | dfff3749f17404f1 | 22.408482352s   |
| PlainAccountState          | 9c073f0b730bf9ed |<PHONE_NUMBER>02s  |
| PlainStorageState          | f10f881275082a15 |<PHONE_NUMBER>42s  |
| AccountsHistory            | 2bdd4421e91ae748 | 7.643388769s    |
| StoragesHistory            | 82c8b9494638c109 | 36.425433792s   |
| AccountChangeSets          | b55e2bb63b93fa0e | 2.695699342s    |
| StorageChangeSets          | 48d12da1245e6a47 | 19.5965801s     |
| HashedAccounts             | e00b568c42be9670 |<PHONE_NUMBER>59s  |
| HashedStorages             | c0c04e969197b0f6 |<PHONE_NUMBER>33s  |
| AccountsTrie               | 75acbff021d6c11e | 29.461375055s   |
| StoragesTrie               | 6d1df86833ba2980 | 75.138795734s   |
| TransactionSenders         | a8aa3266a6c1ff34 | 448.132µs       |
| StageCheckpoints           | 59f914f5247732d5 | 4.459µs         |
| StageCheckpointProgresses  | 39cdebf3977ba1de | 3.354µs         |
| PruneCheckpoints           | 9ef893840836d8e6 | 3.461µs         |
| VersionHistory             | ca2d5479de2935d0 | 7.851µs         |
| -------------------------- | ---------------- | --------------  |
| Total elapsed              |                  | 1056.160246942s |

| Segment      | Block Range       | Transaction Range   | Shape (columns x rows) | Data Size | Index Size | Offsets Size | Config Size | Total Size |
|--------------|-------------------|---------------------|------------------------|-----------|------------|--------------|-------------|------------|
| Headers      | 0..=499999        | N/A                 | 3 x 500000             | 163.1 MiB | 0 B        | 11.4 MiB     | 75 B        | 174.6 MiB  |
| Headers      | 500000..=999999   | N/A                 | 3 x 500000             | 220.9 MiB | 0 B        | 11.4 MiB     | 75 B        | 232.3 MiB  |
| Headers      | 1000000..=1347968 | N/A                 | 3 x 347969             | 193.3 MiB | 0 B        | 8 MiB        | 75 B        | 201.2 MiB  |
| Transactions | 0..=499999        | 0..=1903501         | 1 x 1903502            | 664.1 MiB | 0 B        | 14.5 MiB     | 87 B        | 678.7 MiB  |
| Transactions | 500000..=999999   | 1903502..=30681966  | 1 x 28778465           | 10.9 GiB  | 0 B        | 219.6 MiB    | 87 B        | 11.1 GiB   |
| Transactions | 1000000..=1347968 | 30681967..=42680068 | 1 x 11998102           | 17.4 GiB  | 0 B        | 91.5 MiB     | 87 B        | 17.5 GiB   |
| ------------ | ----------------- | ------------------- | ---------------------- | --------- | ---------- | ------------ | ----------- | ---------- |
| Total        |                   |                     |                        | 29.5 GiB  | 0 B        | 356.5 MiB    | 486 B       | 29.9 GiB   |

| Table Name                 | # Entries | Branch Pages | Leaf Pages | Overflow Pages | Total Size |
|----------------------------|-----------|--------------|------------|----------------|------------|
| AccountChangeSets          | 886850    | 3184         | 12276      | 0              | 60.4 MiB   |
| AccountsHistory            | 397982    | 856          | 43755      | 101            | 174.7 MiB  |
| AccountsTrie               | 2315428   | 783          | 174210     | 0              | 683.6 MiB  |
| BlockBodyIndices           | 1347969   | 37           | 7877       | 0              | 30.9 MiB   |
| BlockOmmers                | 0         | 0            | 0          | 0              | 0 B        |
| BlockWithdrawals           | 1338314   | 855          | 191130     | 0              | 749.9 MiB  |
| Bytecodes                  | 60004     | 50           | 3502       | 124344         | 499.6 MiB  |
| CanonicalHeaders           | 67        | 1            | 2          | 0              | 12 KiB     |
| HashedAccounts             | 30640888  | 11694        | 895438     | 0              | 3.5 GiB    |
| HashedStorages             | 55585338  | 23272        | 1243234    | 0              | 4.8 GiB    |
| HeaderNumbers              | 1347969   | 344          | 30542      | 0              | 120.6 MiB  |
| HeaderTerminalDifficulties | 67        | 0            | 1          | 0              | 4 KiB      |
| Headers                    | 67        | 1            | 12         | 0              | 52 KiB     |
| PlainAccountState          | 30641764  | 5684         | 575989     | 0              | 2.2 GiB    |
| PlainStorageState          | 55587736  | 20444        | 1010320    | 0              | 3.9 GiB    |
| PruneCheckpoints           | 5         | 0            | 1          | 0              | 4 KiB      |
| Receipts                   | 2482742   | 470          | 104743     | 42156          | 575.7 MiB  |
| StageCheckpointProgresses  | 1         | 0            | 1          | 0              | 4 KiB      |
| StageCheckpoints           | 12        | 0            | 1          | 0              | 4 KiB      |
| StorageChangeSets          | 7589469   | 12318        | 113319     | 0              | 490.8 MiB  |
| StoragesHistory            | 5626146   | 6076         | 205108     | 437            | 826.6 MiB  |
| StoragesTrie               | 4482341   | 45847        | 408580     | 0              | 1.7 GiB    |
| TransactionBlocks          | 1174910   | 35           | 7532       | 0              | 29.6 MiB   |
| TransactionHashNumbers     | 42678810  | 13007        | 999759     | 0              | 3.9 GiB    |
| TransactionSenders         | 1259      | 1            | 12         | 0              | 52 KiB     |
| Transactions               | 3677      | 3            | 212        | 1153           | 5.3 MiB    |
| VersionHistory             | 1         | 0            | 1          | 0              | 4 KiB      |
| -------------------------- | --------- | ------------ | ---------- | -------------- | ---------- |
| Tables                     |           |              |            |                | 24.2 GiB   |
| Freelist                   | 12378     |              |            |                | 48.4 MiB   |

I will not be restarting the node, so if necessary I can provide the database files.

The "state root" problem occurred again on my holesky node, Ethel. The links are to reth-holesky-state-root-wink-2024-04-26T04-05Z.tar1 and reth-holesky-state-root-wink-2024-04-26T04-05Z.tar.sha256sum2.
In reth.log.1 here is the first ERROR:
2024-04-25T05:31:04.427510Z ERROR sync::pipeline: Stage encountered a validation error: mismatched block state root: got 0x2ee674c65266e5124e85f5a62642e2451d3bdfff629d1f166de531f9fc2a079d, expected 0xfd8a69059b6db1818baf48d8be521c22ec9fb3f687a298094ab2d824929461ec stage=MerkleExecute bad_block=1414478

The first shutdown and reboot:
2024-04-25T05:31:04.427510Z ERROR sync::pipeline: Stage encountered a validation error: mismatched block state root: got 0x2ee674c65266e5124e85f5a62642e2451d3bdfff629d1f166de531f9fc2a079d, expected 0xfd8a69059b6db1818baf48d8be521c22ec9fb3f687a298094ab2d824929461ec stage=MerkleExecute bad_block=1414478
2024-04-25T05:31:04.431634Z DEBUG provider::static_file: Commit segment=Headers path="/home/kendall/eth2-data/reth/holesky/static_files/static_file_headers_1000000_1499999" duration=4.043746ms
2024-04-25T05:31:04.436691Z DEBUG provider::static_file: Commit segment=Transactions path="/home/kendall/eth2-data/reth/holesky/static_files/static_file_transactions_1000000_1499999" duration=4.929643ms
2024-04-25T05:31:04.436849Z DEBUG storage::db::mdbx: Commit total_duration=21.156µs commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 0, audit: 0, write: 0, sync: 0, ending: 0, whole: 1, 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-25T05:31:04.437118Z DEBUG Unwinding{stage=Finish}: sync::pipeline: Starting unwind from=1414469 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.437485Z DEBUG Unwinding{stage=IndexAccountHistory}: sync::pipeline: Starting unwind from=1414469 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.437495Z DEBUG Unwinding{stage=IndexStorageHistory}: sync::pipeline: Starting unwind from=1414469 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.437502Z DEBUG Unwinding{stage=TransactionLookup}: sync::pipeline: Starting unwind from=1414469 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.437508Z DEBUG Unwinding{stage=MerkleExecute}: sync::pipeline: Starting unwind from=1414469 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.437514Z DEBUG Unwinding{stage=StorageHashing}: sync::pipeline: Starting unwind from=1414478 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.456169Z  INFO Unwinding{stage=StorageHashing}: sync::pipeline: Stage unwound stage=StorageHashing unwind_to=1414469 progress=1414469 done=true
2024-04-25T05:31:04.460829Z DEBUG Unwinding{stage=StorageHashing}: provider::static_file: Commit segment=Headers path="/home/kendall/eth2-data/reth/holesky/static_files/static_file_headers_1000000_1499999" duration=4.613428ms
2024-04-25T05:31:04.465924Z DEBUG Unwinding{stage=StorageHashing}: provider::static_file: Commit segment=Transactions path="/home/kendall/eth2-data/reth/holesky/static_files/static_file_transactions_1000000_1499999" duration=4.967019ms
2024-04-25T05:31:04.769180Z DEBUG Unwinding{stage=StorageHashing}: storage::db::mdbx: Commit total_duration=303.114743ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 3, audit: 0, write: 0, sync: 19858, ending: 0, whole: 19862, 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-25T05:31:04.769269Z DEBUG Unwinding{stage=AccountHashing}: sync::pipeline: Starting unwind from=1414478 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.780843Z  INFO Unwinding{stage=AccountHashing}: sync::pipeline: Stage unwound stage=AccountHashing unwind_to=1414469 progress=1414469 done=true
2024-04-25T05:31:04.811143Z DEBUG Unwinding{stage=AccountHashing}: provider::static_file: Commit segment=Headers path="/home/kendall/eth2-data/reth/holesky/static_files/static_file_headers_1000000_1499999" duration=30.259169ms
2024-04-25T05:31:04.842890Z DEBUG Unwinding{stage=AccountHashing}: provider::static_file: Commit segment=Transactions path="/home/kendall/eth2-data/reth/holesky/static_files/static_file_transactions_1000000_1499999" duration=31.560565ms
2024-04-25T05:31:04.912822Z DEBUG Unwinding{stage=AccountHashing}: storage::db::mdbx: Commit total_duration=69.748296ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 5, audit: 0, write: 0, sync: 4563, ending: 0, whole: 4568, 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-25T05:31:04.912969Z DEBUG Unwinding{stage=MerkleUnwind}: sync::pipeline: Starting unwind from=1414478 to=1414469 bad_block=Some(1414478)
2024-04-25T05:31:04.913039Z DEBUG Unwinding{stage=MerkleUnwind}: trie::loader: incremental state root range=1414470..=1414478
2024-04-25T05:31:04.921859Z DEBUG net::session: pending session timed out remote_addr=<IP_ADDRESS>:38000 direction=Outgoing(0xb3f561eefe85ecb05719f26d3b99d3d2ffd66dc0f14c707f1709fc41120e4c73718daf47632e88dacc9e56ecad3fa2a39a33f5a1921e424735564cc4cfba4839)
2024-04-25T05:31:05.113267Z  WARN Unwinding{stage=MerkleUnwind}: sync::stages::merkle: Failed to verify block state root target_block=1414469 got=0x80df9c09300cc33dc101991e841dcae68cba162c36993fc8669c3b31cadfa0a8 expected=SealedHeader { hash: 0xfc685c336c57b5153837f3b2ceb9c39054113c872cfac225c5b1939ce46e1f94, header: Header { parent_hash: 0x82bf41871024274c7c4979754f5368a47bd561f8a597f8d793dd424e6f996e12, ommers_hash: 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, beneficiary: 0x8fc558a2b0352f9e03488986679374c961a599bb, state_root: 0x076a83408d306ff755956318ad51e4ef8785bef7e861f1377194ec862601a6ed, transactions_root: 0x4d3d68fc63c53ffcad86317983f1a2a06d1869f1bc694f49a4dc57790a8b46ed, receipts_root: 0xd7387d72f54b9f3b346903dcbb812d66ae7a43d555157723d43d49fd08b14c57, withdrawals_root: Some(0x4ab3a335bfedf1974ba035e033ac205b96f4ede8c02d13228d920715e479388f), logs_bloom: 0x04080800080000100000800000000002600800040400008004100200000040000000010000000000100520000080040010403001800000000004001001210000000002000000080000240009000000010100000200000000600400090c88104000400810020000a08000010080040800010000000002042000104030182000200000104000200000000000000000000000043000900000000400000030000400030008000004000000100011050008080200000000042010100000060000080402180002000801001000000000000d00000100120000001000089800010020000410080200000408081101008008300008008001602001200000800008002000, difficulty: 0x0_U256, number: 1414469, gas_limit: 30000000, gas_used: 9065197, timestamp:<PHONE_NUMBER>, mix_hash: 0xa563061ebe8fc2671f5f90bd0e39bd39c1c2a368934d195f02a0dbc53d1f1c7c, nonce: 0, base_fee_per_gas: Some(2321611840), blob_gas_used: Some(655360), excess_blob_gas: Some(79036416), parent_beacon_block_root: Some(0x285ce5d058e18329e24b377e88d5946728cf94074b524c892d4e929e6bf42502), extra_data: 0x } }
2024-04-25T05:31:05.126095Z ERROR reth::cli: shutting down due to error
2024-04-25T05:31:10.709226Z  INFO reth::cli: Starting reth version="0.2.0-beta.6-dev (ac29b4b73)"
2024-04-25T05:31:10.709918Z  INFO reth::cli: Opening database path="/home/kendall/eth2-data/reth/holesky/db"
2024-04-25T05:31:10.866993Z  INFO reth::cli: Configuration loaded path="/home/kendall/eth2-data/reth/holesky/reth.toml"
2024-04-25T05:31:10.923565Z  INFO reth::cli: Database opened
2024-04-25T05:31:10.923614Z  INFO reth::cli: Starting metrics endpoint addr=<IP_ADDRESS>:9001
2024-04-25T05:31:10.931620Z DEBUG reth::cli: Initializing genesis chain=holesky genesis=0xb5f7f912443c940f21fd611f12828d75b534364ed9e95ca4e307729a4661bde4
2024-04-25T05:31:10.939542Z DEBUG reth_node_core::init: Genesis already written, skipping.
2024-04-25T05:31:10.939600Z  INFO reth::cli:
Pre-merge hard forks (block based):
- Frontier                         @0
- Homestead                        @0
- Dao                              @0

@winksaville doesn't seem like links are working

@winksaville doesn't seem like links are working

Fixed now

After some discussion on the Reth State Root Debugging Warroom, the feeling is my database might be corrupted because I didn't resync or drop the merkle tree before I started testing beta.6.
I've removed all files using rm -rf ~/eth2-data/reth/holesky/* and in reth.service I've changed Restart to no:
kendall@ethel 24-04-26T19:26:45.289Z:~
$ cat -n /etc/systemd/system/reth.service
     1	# The ethereum service (part of systemd)
     2	# file: /etc/systemd/system/eth1.service
     3
     4	[Unit]
     5	Description     = reth eth2 service
     6	Requires        = network-online.target
     7	After           = network-online.target
     8
     9	[Service]
    10	User            = kendall
    11	ExecStartPre    = /bin/sleep 2
    12	ExecStart       = \
    13	  /home/kendall/bin/reth node \
    14	  --full \
    15	  --chain holesky \
    16	  --instance 1 \
    17	  --max-outbound-peers 16 \
    18	  --max-inbound-peers 16 \
    19	  --http \
    20	  --http.addr <IP_ADDRESS> \
    21	  --ws \
    22	  --http.api admin,eth,web3,net \
    23	  --datadir /home/kendall/eth2-data/reth/holesky \
    24	  --authrpc.addr <IP_ADDRESS> \
    25	  --authrpc.port 8551 \
    26	  --authrpc.jwtsecret /home/kendall/eth2-data/secrets/jwtsecret \
    27	  --log.file.format terminal \
    28	  --log.file.filter debug \
    29	  --log.file.directory /home/kendall/eth2-data/reth \
    30	  --log.file.max-size 200 \
    31	  --log.file.max-files 5 \
    32	  --log.journald \
    33	  --log.journald.filter error \
    34	  --color auto \
    35	  --metrics <IP_ADDRESS>:9001 \
    36
    37	Restart         = no
    38	RestartSec      = 3
    39	TimeoutSec      = 300
    40
    41	[Install]
    42	WantedBy    = multi-user.target
kendall@ethel 24-04-26T19:35:21.813Z:~

I've now restarted the CLs and reth, here is the initial log lines from reth:
Apr 25 19:32:21 ethel systemd[1]: Stopped reth eth2 service.
Apr 26 12:25:39 ethel systemd[1]: Starting reth eth2 service...
Apr 26 12:25:41 ethel systemd[1]: Started reth eth2 service.
Apr 26 12:25:41 ethel reth[526219]: 2024-04-26T19:25:41.588190Z  INFO Starting reth version="0.2.0-beta.6-dev (ac29b4b73)"
Apr 26 12:25:41 ethel reth[526219]: 2024-04-26T19:25:41.588834Z  INFO Opening database path="/home/kendall/eth2-data/reth/holesky/db"
Apr 26 12:25:43 ethel reth[526219]: 2024-04-26T19:25:43.965992Z  INFO Configuration loaded path="/home/kendall/eth2-data/reth/holesky/reth.toml"
Apr 26 12:25:43 ethel reth[526219]: 2024-04-26T19:25:43.967005Z  INFO Database opened
Apr 26 12:25:43 ethel reth[526219]: 2024-04-26T19:25:43.967019Z  INFO Starting metrics endpoint addr=<IP_ADDRESS>:9001
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.020355Z  INFO
Apr 26 12:25:44 ethel reth[526219]: Pre-merge hard forks (block based):
Apr 26 12:25:44 ethel reth[526219]: - Frontier                         @0
Apr 26 12:25:44 ethel reth[526219]: - Homestead                        @0
Apr 26 12:25:44 ethel reth[526219]: - Dao                              @0
Apr 26 12:25:44 ethel reth[526219]: - Tangerine                        @0
Apr 26 12:25:44 ethel reth[526219]: - SpuriousDragon                   @0
Apr 26 12:25:44 ethel reth[526219]: - Byzantium                        @0
Apr 26 12:25:44 ethel reth[526219]: - Constantinople                   @0
Apr 26 12:25:44 ethel reth[526219]: - Petersburg                       @0
Apr 26 12:25:44 ethel reth[526219]: - Istanbul                         @0
Apr 26 12:25:44 ethel reth[526219]: - MuirGlacier                      @0
Apr 26 12:25:44 ethel reth[526219]: - Berlin                           @0
Apr 26 12:25:44 ethel reth[526219]: - London                           @0
Apr 26 12:25:44 ethel reth[526219]: Merge hard forks:
Apr 26 12:25:44 ethel reth[526219]: - Paris                            @0 (network is known to be merged)
Apr 26 12:25:44 ethel reth[526219]: Post-merge hard forks (timestamp based):
Apr 26 12:25:44 ethel reth[526219]: - Shanghai                         @1696000704
Apr 26 12:25:44 ethel reth[526219]: - Cancun                           @1707305664
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.116715Z  INFO Transaction pool initialized
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.116758Z  INFO Connecting to P2P network
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.118847Z  INFO StaticFileProducer initialized
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.118964Z  INFO Pruner initialized prune_config=PruneConfig { block_interval: 5, segments: PruneModes { sender_recovery: Some(Full), transaction_lookup: None, receipts: Some(Before(0)), account_history: Some(Distance(10064)), storage_history: Some(Distance(10064)), receipts_log_filter: ReceiptsLogPruneConfig({0x4242424242424242424242424242424242424242: Before(0)}) } }
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.119085Z  INFO Consensus engine initialized
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.119150Z  INFO Engine API handler initialized
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.120523Z  INFO RPC auth server started url=<IP_ADDRESS>:8551
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.120616Z  INFO RPC IPC server started url=/tmp/reth.ipc
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.120624Z  INFO RPC HTTP server started url=<IP_ADDRESS>:8545
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.120628Z  INFO RPC WS server started url=<IP_ADDRESS>:8546
Apr 26 12:25:44 ethel reth[526219]: 2024-04-26T19:25:44.120636Z  INFO Starting consensus engine
Apr 26 12:25:47 ethel reth[526219]: 2024-04-26T19:25:47.119561Z  INFO Status connected_peers=0 freelist=2 latest_block=0
Apr 26 12:26:12 ethel reth[526219]: 2024-04-26T19:26:12.119659Z  INFO Status connected_peers=0 freelist=2 latest_block=0
Apr 26 12:26:37 ethel reth[526219]: 2024-04-26T19:26:37.120268Z  INFO Status connected_peers=0 freelist=2 latest_block=0
Apr 26 12:27:02 ethel reth[526219]: 2024-04-26T19:27:02.119534Z  INFO Status connected_peers=0 freelist=2 latest_block=0
Apr 26 12:27:27 ethel reth[526219]: 2024-04-26T19:27:27.120355Z  INFO Status connected_peers=3 freelist=2 latest_block=0
Apr 26 12:27:32 ethel reth[526219]: 2024-04-26T19:27:32.586460Z  INFO Live sync in progress, downloading blocks remaining_blocks=1 target_block_hash=0x6ae9a9f176b783a98d766b51f740f05730975099f7908f12c9892d1c04e8a045
Apr 26 12:27:32 ethel reth[526219]: 2024-04-26T19:27:32.586518Z  INFO Received forkchoice updated message when syncing head_block_hash=0x15b77c5741dd1b251745081ad6a98b4b8aca739eb48da9c16ba1952f33ffa52c safe_block_hash=0x6ae9a9f176b783a98d766b51f740f05730975099f7908f12c9892d1c04e8a045 finalized_block_hash=0xa5bf1ecf708fb85c7907e20e0b37a47ff2e78253ce400f2421c3d208bf9248a9
Apr 26 12:27:32 ethel reth[526219]: 2024-04-26T19:27:32.586542Z  INFO Live sync in progress, downloading blocks remaining_blocks=1 target_block_hash=0x15b77c5741dd1b251745081ad6a98b4b8aca739eb48da9c16ba1952f33ffa52c
Apr 26 12:27:33 ethel reth[526219]: 2024-04-26T19:27:33.108582Z  INFO Static File Producer started targets=StaticFileTargets { headers: None, receipts: None, transactions: Some(0..=0) }
Apr 26 12:27:33 ethel reth[526219]: 2024-04-26T19:27:33.137838Z  INFO Static File Producer finished targets=StaticFileTargets { headers: None, receipts: None, transactions: Some(0..=0) } elapsed=29.157575ms
Apr 26 12:27:33 ethel reth[526219]: 2024-04-26T19:27:33.137904Z  INFO Preparing stage pipeline_stages=1/12 stage=Headers checkpoint=0 target=None
Apr 26 12:27:36 ethel reth[526219]: 2024-04-26T19:27:36.016193Z  INFO Received headers total=10000 from_block=1420305 to_block=1410306
Apr 26 12:27:38 ethel reth[526219]: 2024-04-26T19:27:38.520677Z  INFO Received headers total=10000 from_block=1410305 to_block=1400306
Apr 26 12:27:40 ethel reth[526219]: 2024-04-26T19:27:40.837033Z  INFO Received headers total=10000 from_block=1400305 to_block=1390306
Apr 26 12:27:43 ethel reth[526219]: 2024-04-26T19:27:43.196793Z  INFO Received headers total=10000 from_block=1390305 to_block=1380306

Attestations started about 7hrs later:
Apr 26 19:20:29 ethel lighthouse[526220]: Apr 27 02:20:29.161 ERRO Error updating deposit contract cache   error: Failed to get remote head and new block ranges: EndpointError(FarBehind), retry_millis: 60000, service: deposit_contract_rpc
Apr 26 19:21:29 ethel lighthouse[526220]: Apr 27 02:21:29.161 ERRO Error updating deposit contract cache   error: Failed to get remote head and new block ranges: EndpointError(FarBehind), retry_millis: 60000, service: deposit_contract_rpc
Apr 26 19:22:29 ethel lighthouse[526220]: Apr 27 02:22:29.169 ERRO Error updating deposit contract cache   error: Failed to get remote head and new block ranges: EndpointError(FarBehind), retry_millis: 60000, service: deposit_contract_rpc
Apr 26 19:23:29 ethel lighthouse[526220]: Apr 27 02:23:29.161 ERRO Error updating deposit contract cache   error: Failed to get remote head and new block ranges: EndpointError(FarBehind), retry_millis: 60000, service: deposit_contract_rpc
Apr 26 19:23:57 ethel lighthouse[526220]: Apr 27 02:23:57.470 INFO Previous epoch attestation(s) missing   validators: ["1624364", "1624363"], epoch: 47608, service: val_mon, service: beacon
Apr 26 19:30:21 ethel lighthouse[526220]: Apr 27 02:30:21.462 INFO Previous epoch attestation(s) missing   validators: ["1624364", "1624363"], epoch: 47609, service: val_mon, service: beacon
Apr 26 19:36:45 ethel lighthouse[526220]: Apr 27 02:36:45.469 INFO Previous epoch attestation(s) success   validators: ["1624364", "1624363"], epoch: 47610, service: val_mon, service: beacon
Apr 26 19:43:09 ethel lighthouse[526220]: Apr 27 02:43:09.516 INFO Previous epoch attestation(s) success   validators: ["1624364", "1624363"], epoch: 47611, service: val_mon, service: beacon

beta.6 failed with "mismatched block state root".
Here is the directory with db and logs...:
https://drive.google.com/file/d/1HGYmHoI2ImPKIsJQuZoFAwTSfVzOILtM/view?usp=drive_link
Here is the sha256sum of the above file:
https://drive.google.com/file/d/1yDpqeBgtseSsaBoN-m4q03fLiL041Rxd/view?usp=drive_link
Here is reth.log:
https://drive.google.com/file/d/1lIl7g_9RAwezi_Vi2FPUe_LRcIiQafOp/view?usp=drive_link
And it's sha256sum:
https://drive.google.com/file/d/1QP9riJj3MlpNmVn0ZEGOSxY_CVGCGnXG/view?usp=drive_link
Here is the log lines around the first error:
2024-05-02T09:41:01.558729Z DEBUG blockchain_tree: Appending block to canonical chain head=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50 parent=(1462114, 0x71cd9cd46ea0ecc762e6ae227c533d6e2ce1c3c47a1246f729d9e352adcca472)
2024-05-02T09:41:01.643935Z DEBUG evm: Execution time evm_transact=81.072169ms apply_state=509.229µs apply_post_state=5.15µs merge_transitions=548.025µs receipt_root=2.363484ms
2024-05-02T09:41:01.645314Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=394
2024-05-02T09:41:02.064694Z  WARN consensus::engine: Error while processing payload error=Failed to insert block (hash=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50, number=1462115, parent_hash=0x71cd9cd46ea0ecc762e6ae227c533d6e2ce1c3c47a1246f729d9e352adcca472): mismatched block state root: got 0x9dc21474467a4fa1cc82968e91f9ec5b0a69f0921e36f59a71d506fae9aa2a0f, expected 0xb1fc80619f2159d3e11361ac3c6083c12b1628f0906810853eb565496ff8689d
2024-05-02T09:41:02.065046Z  WARN consensus::engine: Invalid block error on new payload invalid_hash=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50 invalid_number=1462115 error=mismatched block state root: got 0x9dc21474467a4fa1cc82968e91f9ec5b0a69f0921e36f59a71d506fae9aa2a0f, expected 0xb1fc80619f2159d3e11361ac3c6083c12b1628f0906810853eb565496ff8689d
2024-05-02T09:41:02.067004Z  WARN consensus::engine: Bad block with hash hash=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50 header=Header { parent_hash: 0x71cd9cd46ea0ecc762e6ae227c533d6e2ce1c3c47a1246f729d9e352adcca472, ommers_hash: 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, beneficiary: 0x148914866080716b10d686f5570631fbb2207002, state_root: 0xb1fc80619f2159d3e11361ac3c6083c12b1628f0906810853eb565496ff8689d, transactions_root: 0xf7c7fc5e532b4a0f3f7a0c24c22482c3dca46684f30c7f4e4a39caf9b27ca8d7, receipts_root: 0xfefcdeaa2d7ec432bd6f00a29f6128ec0bee3f6685cfd47037b70de85dddab8e, withdrawals_root: Some(0x2ee06f790cde99c3ca70a7d70b1f02c209bea9cc1aadc18ff3d0e9704316eaff), logs_bloom: 0x44cc39b308080b4110833df1f9d580896f1d0941946cb0d01d34f7d0d4f646715580898628374868472627fda9d02d2f522c2b15ba380e8d85bc162793b1c3ef1034020591886358560fc81918a9728f010fcc63743aaa5b6c143d898988d14584063d5026461104a9f26d1614115855293d1b02641fe263273d69fc14638cd03a46dbda098dfc0e2b1df47d3f7c0434183cb68a1702301a0146dde37fa6266ad745fc41327659c06a4f3475a5234c294be2770aa516fc6d33b8580e21889e1d01df862feb0cc9085d28b15693c47da5883d9416f17600b5892a3f26573c75ea145b8ad3caa055d951fab119f90a2a454e5697f8e81917c5c9134af65f0f3223, difficulty: 0x0_U256, number: 1462115, gas_limit: 30000000, gas_used: 28957346, timestamp:<PHONE_NUMBER>, mix_hash: 0x5c25f38d1a7310dfbfcfc491ec9803d2765b4af57adce1e09d382c506c736c76, nonce: 0, base_fee_per_gas: Some(3718827006), blob_gas_used: Some(655360), excess_blob_gas: Some(80216064), parent_beacon_block_root: Some(0xc0bf037f523033779dda6e075cdb1597cd03971402234667ecddb2fd05fdcafb), extra_data: 0x546974616e2028746974616e6275696c6465722e78797a29 }
2024-05-02T09:41:02.067382Z DEBUG consensus::engine::hooks: Next hook is not ready hook="Prune"
2024-05-02T09:41:10.150915Z DEBUG jsonrpsee-server: Accepting new connection 1/500
2024-05-02T09:41:19.391768Z DEBUG jsonrpsee-server: Accepting new connection 1/500
2024-05-02T09:41:19.394391Z DEBUG blockchain_tree: Appending block to canonical chain head=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50 parent=(1462114, 0x71cd9cd46ea0ecc762e6ae227c533d6e2ce1c3c47a1246f729d9e352adcca472)
2024-05-02T09:41:19.418196Z DEBUG evm: Execution time evm_transact=20.236627ms apply_state=456.03µs apply_post_state=4.423µs merge_transitions=748.571µs receipt_root=2.180102ms
2024-05-02T09:41:19.419683Z DEBUG trie::parallel_state_root: pre-calculating storage roots len=394
2024-05-02T09:41:19.498095Z  WARN consensus::engine: Error while processing payload error=Failed to insert block (hash=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50, number=1462115, parent_hash=0x71cd9cd46ea0ecc762e6ae227c533d6e2ce1c3c47a1246f729d9e352adcca472): mismatched block state root: got 0x9dc21474467a4fa1cc82968e91f9ec5b0a69f0921e36f59a71d506fae9aa2a0f, expected 0xb1fc80619f2159d3e11361ac3c6083c12b1628f0906810853eb565496ff8689d
2024-05-02T09:41:19.498155Z  WARN consensus::engine: Invalid block error on new payload invalid_hash=0xd80097d3e5b3ef413c0ce3bd8dcd24941c849c3397ffc5c61739baf4c7293c50 invalid_number=1462115 error=mismatched block state root: got 0x9dc21474467a4fa1cc82968e91f9ec5b0a69f0921e36f59a71d506fae9aa2a0f, expected 0xb1fc80619f2159d3e11361ac3c6083c12b1628f0906810853eb565496ff8689d
2024-05-02T09:41:19.498414Z DEBUG consensus::engine::hooks: Next hook is not ready hook="StaticFile"

Here is the vitals of the node:
kendall@ethel 24-05-03T04:30:40.076Z:~
$ print-info.sh

~/bin/reth --version:
reth Version: 0.2.0-beta.6-dev
Commit SHA: ac29b4b73
Build Timestamp: 2024-04-24T00:06:44.055414554Z
Build Features: jemalloc
Build Profile: release

~/bin/lighthouse --version:
Lighthouse v5.1.3-3058b96
BLS library: blst-modern
SHA256 hardware acceleration: false
Allocator: jemalloc
Profile: maxperf
Specs: mainnet (true), minimal (false), gnosis (true)

inxi:
CPU: quad core Intel Core i5-8259U (-MT MCP-)
speed/min/max: 1249/400/3800 MHz Kernel: 6.5.0-27-generic x86_64
Up: 15d 10h 16m Mem: 1214.6/31953.5 MiB (3.8%) Storage: 2.73 TiB (21.1% used)
Procs: 255 Shell: Bash inxi: 3.3.13

lsb_release -a:
No LSB modules are available.
 What I'm hoping is that when the state root error occurs we'll be able find the SealedHeader for both the block we failed on as well as the expected block and maybe that will provide useful information.
Of course, if there is a solution or additional debug! I'll stop this and test whatever the experts want.

@Rjected, has asked me to remove the panic!, before I do I'd like to see if there are any other debug! log statements people would like to be added?
Also, when I restarted the first time with my initial changes the first wink output was state_root::calculate just before the first run of the MerkleExecute stage finished:
2024-05-04T18:29:46.996165Z  INFO reth::cli: Starting reth version="0.2.0-beta.6-dev (6adb54c90)"
...
2024-05-04T18:45:27.973719Z DEBUG reth_trie::trie: wink: trie::state_root::calculate: 0xc3812b2303d2b564f03b17284d9fb284309585cf65f6cbb228d9932c9a8c5a7c
2024-05-04T18:45:27.990954Z  INFO reth_node_events::node: Finished stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=1462136 target=1462136 stage_progress=100.00% stage_eta=unknown

I decided to search the logs and I found that state root 0xc3812b23..8c5a7c corresponds to the expected state root in the last mismatched block state root when v0.2.0-beta.6 (ac29b4b73) failed:
2024-04-26T19:25:41.588216Z  INFO reth::cli: Starting reth version="0.2.0-beta.6-dev (ac29b4b73)"
...
2024-05-02T10:00:54.178146Z ERROR sync::pipeline: Stage encountered a validation error: mismatched block state root: got 0xb51453298d8df1e83d55f8f658f4a925f005dc0a5c5edd6ae5714cd05169b1a8, expected 0xc3812b2303d2b564f03b17284d9fb284309585cf65f6cbb228d9932c9a8c5a7c stage=MerkleExecute bad_block=1462136

I thought that was interesting, so would anyone like to add more debug! log statements before I rebuild and restart my node?

As @Rjected asked I've removed the panic! but left the 3 debug! statements. I stopped EL and CL and dropped the Merkle stage recompiled resulting in reth version="0.2.0-beta.6-dev (4f6be12e5)".
I then restarted EL and CL and reth when though the stages once and shortly after that the bn was reporting successful attestations.
Now we just need to wait a week or so and see what happens, LoL.
Here are reth logs showing startup through the first set of stages:
May 08 12:01:14 ethel reth[647583]: 2024-05-08T19:01:14.289539Z  INFO Pruner finished tip_block_number=1504649 elapsed=310.521878ms stats={AccountHistory: (Finished, 621)}
May 08 12:01:16 ethel systemd[1]: Stopping reth eth2 service...
May 08 12:01:16 ethel reth[647583]: 2024-05-08T19:01:16.341372Z  INFO Wrote network peers to file peers_file="/home/kendall/eth2-data/reth/holesky/known-peers.json"
May 08 12:01:16 ethel systemd[1]: reth.service: Deactivated successfully.
May 08 12:01:16 ethel systemd[1]: Stopped reth eth2 service.
May 08 12:01:16 ethel systemd[1]: reth.service: Consumed 6h 16min 28.560s CPU time.
May 08 12:40:22 ethel systemd[1]: Starting reth eth2 service...
May 08 12:40:24 ethel systemd[1]: Started reth eth2 service.
May 08 12:40:24 ethel reth[700461]: 2024-05-08T19:40:24.516383Z  INFO Starting reth version="0.2.0-beta.6-dev (4f6be12e5)"
...
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.818053Z  INFO Preparing stage pipeline_stages=1/12 stage=Headers checkpoint=1504649 target=None
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.818068Z  INFO Target block already reached checkpoint=1504649 target=Hash(0x03bd2f085839b479bf2e64775e6cb9400d085c9b06085f14aa3c8f973b36dbea)
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.818107Z  INFO Executing stage pipeline_stages=1/12 stage=Headers checkpoint=1504649 target=None
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.818204Z  INFO Finished stage pipeline_stages=1/12 stage=Headers checkpoint=1504649 target=None
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.831464Z  INFO Preparing stage pipeline_stages=2/12 stage=Bodies checkpoint=1504649 target=1504649
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.831486Z  INFO Executing stage pipeline_stages=2/12 stage=Bodies checkpoint=1504649 target=1504649
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.831497Z  INFO Finished stage pipeline_stages=2/12 stage=Bodies checkpoint=1504649 target=1504649
...
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.888691Z  INFO Preparing stage pipeline_stages=7/12 stage=StorageHashing checkpoint=1504649 target=1504649
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.888741Z  INFO Executing stage pipeline_stages=7/12 stage=StorageHashing checkpoint=1504649 target=1504649
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.888762Z  INFO Finished stage pipeline_stages=7/12 stage=StorageHashing checkpoint=1504649 target=1504649
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.898846Z  INFO Preparing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=0 target=1504649
May 08 12:41:10 ethel reth[700461]: 2024-05-08T19:41:10.898865Z  INFO Executing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=0 target=1504649
May 08 12:41:11 ethel reth[700461]: 2024-05-08T19:41:11.835594Z  INFO Committed stage progress pipeline_stages=8/12 stage=MerkleExecute checkpoint=0 target=1504649 stage_progress=0.12%
May 08 12:41:11 ethel reth[700461]: 2024-05-08T19:41:11.866590Z  INFO Preparing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=0 target=1504649
May 08 12:41:11 ethel reth[700461]: 2024-05-08T19:41:11.866614Z  INFO Executing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=0 target=1504649
May 08 12:41:12 ethel reth[700461]: 2024-05-08T19:41:12.649713Z  INFO Committed stage progress pipeline_stages=8/12 stage=MerkleExecute checkpoint=0 target=1504649 stage_progress=0.22% stage_eta=13m 56s
...
May 08 12:54:25 ethel reth[700461]: 2024-05-08T19:54:25.212144Z  INFO Preparing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=1504649 target=1504833
May 08 12:54:25 ethel reth[700461]: 2024-05-08T19:54:25.212214Z  INFO Executing stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=1504649 target=1504833
May 08 12:54:39 ethel reth[700461]: 2024-05-08T19:54:39.114246Z  INFO Status connected_peers=6 freelist=203451 stage=MerkleExecute checkpoint=1504649 target=1504833
May 08 12:55:02 ethel reth[700461]: 2024-05-08T19:55:02.709632Z  INFO Finished stage pipeline_stages=8/12 stage=MerkleExecute checkpoint=1504833 target=1504833 stage_progress=100.00%
May 08 12:55:04 ethel reth[700461]: 2024-05-08T19:55:04.113732Z  INFO Status connected_peers=8 freelist=203451 latest_block=1504649
May 08 12:55:04 ethel reth[700461]: 2024-05-08T19:55:04.818513Z  INFO Updating transaction lookup tx_range=1504649..=1504833
May 08 12:55:04 ethel reth[700461]: 2024-05-08T19:55:04.818515Z  INFO Preparing stage pipeline_stages=9/12 stage=TransactionLookup checkpoint=1504649 target=1504833
...
May 08 12:55:19 ethel reth[700461]: 2024-05-08T19:55:19.032953Z  INFO Writing indices progress=98.89%
May 08 12:55:19 ethel reth[700461]: 2024-05-08T19:55:19.083176Z  INFO Writing indices progress=99.89%
May 08 12:55:19 ethel reth[700461]: 2024-05-08T19:55:19.088559Z  INFO Finished stage pipeline_stages=11/12 stage=IndexAccountHistory checkpoint=1504833 target=1504833
May 08 12:55:19 ethel reth[700461]: 2024-05-08T19:55:19.706231Z  INFO Preparing stage pipeline_stages=12/12 stage=Finish checkpoint=1504649 target=1504833
May 08 12:55:19 ethel reth[700461]: 2024-05-08T19:55:19.706336Z  INFO Executing stage pipeline_stages=12/12 stage=Finish checkpoint=1504649 target=1504833
May 08 12:55:19 ethel reth[700461]: 2024-05-08T19:55:19.706441Z  INFO Finished stage pipeline_stages=12/12 stage=Finish checkpoint=1504833 target=1504833

And here are some bn logs from it starting to the EL is online and shortly after we see a successful attestation of both vc's:
May 08 12:01:23 ethel systemd[1]: beacon-chain.service: Deactivated successfully.
May 08 12:01:23 ethel systemd[1]: Stopped eth2 beacon chain service.
May 08 12:01:23 ethel systemd[1]: beacon-chain.service: Consumed 6d 2h 24min 39.531s CPU time.
May 08 12:40:22 ethel systemd[1]: Starting eth2 beacon chain service...
May 08 12:40:24 ethel systemd[1]: Started eth2 beacon chain service.
May 08 12:40:24 ethel lighthouse[700462]: May 08 19:40:24.533 INFO Logging to file                         path: "/home/kendall/eth2-data/lighthouse/holesky/beacon/logs/beacon.log"
May 08 12:40:24 ethel lighthouse[700462]: May 08 19:40:24.542 INFO Lighthouse started                      version: Lighthouse/v5.1.3-3058b96
May 08 12:40:24 ethel lighthouse[700462]: May 08 19:40:24.542 INFO Configured for network                  name: holesky
May 08 12:40:24 ethel lighthouse[700462]: May 08 19:40:24.542 INFO Data directory initialised              datadir: /home/kendall/eth2-data/lighthouse/holesky
...
May 08 12:55:17 ethel lighthouse[700462]: May 08 19:55:17.507 WARN Execution endpoint is not synced        last_seen_block_unix_timestamp:<PHONE_NUMBER>, endpoint: http://<IP_ADDRESS>:8551/, auth=true, service: deposit_contract_rpc
May 08 12:55:17 ethel lighthouse[700462]: May 08 19:55:17.508 ERRO Error updating deposit contract cache   error: Failed to get remote head and new block ranges: EndpointError(FarBehind), retry_millis: 60000, service: deposit_contract_rpc
May 08 12:55:18 ethel lighthouse[700462]: May 08 19:55:18.001 WARN Head is optimistic                      execution_block_hash: 0xeb1649632e1446cd18f083242a845c9ad54cab7c0b90a60c8cbe16b19cc56464, info: chain not fully verified, block and attestation production disabled until execution engine syncs, service: slot_notifier
May 08 12:55:18 ethel lighthouse[700462]: May 08 19:55:18.001 INFO Synced                                  slot: 1607976, block: 0xeaf4…4acb, epoch: 50249, finalized_epoch: 50247, finalized_root: 0x4187…5532, exec_hash: 0xeb16…6464 (unverified), peers: 100, service: slot_notifier
May 08 12:55:25 ethel lighthouse[700462]: May 08 19:55:25.309 INFO New block received                      root: 0xf0d9b65c5d4add6d18bcfd1393f1c3f52d09dbcee8eb835ccffea20855634565, slot: 1607977
May 08 12:55:25 ethel lighthouse[700462]: May 08 19:55:25.669 INFO Execution engine online                 service: exec
May 08 12:55:25 ethel lighthouse[700462]: May 08 19:55:25.669 INFO Issuing forkchoiceUpdated               forkchoice_state: ForkchoiceState { head_block_hash: 0xeb1649632e1446cd18f083242a845c9ad54cab7c0b90a60c8cbe16b19cc56464, safe_block_hash: 0x2d469d9db7c75199c468457da36e77f1c2c88b503902ca355fc8fc7f57a96cbd, finalized_block_hash: 0x3953c2106e5af4ca1a4af9c3ea0fc7fd61c6050432e5de35f0ba83d0203bd8e6 }, service: exec
...
May 08 13:12:45 ethel lighthouse[700462]: May 08 20:12:45.473 INFO Previous epoch attestation(s) success   validators: ["1624363", "1624364"], epoch: 50250, service: val_mon, service: beacon


Sometimes distanceFromObject return incorrect -1

TypeAnalysis uses distanceFromObject to determine which type can be the root.
However, for some distances which are inherited from object, distanceFromObject still return -1.
The reason is that

even though left and right are resolved, the type of them are not fully resolved. It means that their supertype, supertype ref(typedecl).... are still not resolved. When distanceFromObject reaches null ref, it returns -1.

It seems that Object sometimes does not have a ref. When we create a new BaseType, we set its superType to Object but never set the reference.

IS this really an error though?
If I recall correctly (and I'm pretty sure I do as I originally wrote typeAnalysis), distanceFromObject returning -1 (or findCommonRoot returning null) is not an error but rather an indication that we EITHER don't have enough info to make a call or, if we do, we have an error.
It is the caller's responsibility to make sure everything is resolved if he wishes to be sure there is no common root.
This is probably not true on most call sites, which must be causing unnecessary wholeAgain's and perhaps even LOOP's, significantly hurting compile times.
This is a common thread in multiple places in rock (mainly thinking about the scoring system and most other typesystem related activities).
It would probably be better design to return some kind of result cover that holds an error flag and the final result (same with scores/matches, -1 doesn't really give us true information).
As for the Object BaseTypes assigned directly directly, they should be resolved at some point, giving us their ref.
If they are never resolved and are actually needed in the middle end (as opposed to some Int creations in anonymous struct literals and things of that nature that are "just" used by the backend), this is indeed a bug.


Issue with USB 3.0 drives?

Describe the bug
I have a problem with some USB devices. Normally I get the UsbDriveMounted and UsbDeviceAdded messages within seconds. However, for 2 devices, minutes pass between messages, plus the mounted directory path parameter is then empty.
The problematic devices are USB 3.0 devices, the others are older. The devices otherwise work flawlessly and immediately (Explorer)
Normal:
03.02.2021 12:36:14 UsbDriveMounted on: F:
03.02.2021 12:36:15 UsbDeviceAdded :
Device Name: F:
Device System Path: USB\VID_090C&PID_1000\16092007001318
Mounted Directory Path: F:
Product:
Product Description:
Product ID: 1000
Serial Number:<PHONE_NUMBER>1318
Vendor:
Vendor Description:
Vendor ID: 090C
Issue:
03.02.2021 12:36:25 UsbDriveMounted on: F:
03.02.2021 12:37:44 UsbDeviceAdded :
Device Name: USB-Massenspeichergerät
Device System Path: USB\VID_0781&PID_5591\0501DEDE8246E24347D1649F1F10436EBCAE8C977488E0B66FCFF5118298B533E94800000000000000000000CCFA9DFCFF0C041091558107A4A81936
Mounted Directory Path:
Product: USB-Massenspeichergerät
Product Description: USB-Massenspeichergerät
Product ID: 5591
Serial Number: 0501DEDE8246E24347D1649F1F10436EBCAE8C977488E0B66FCFF5118298B533E94800000000000000000000CCFA9DFCFF0C041091558107A4A81936
Vendor: Kompatibles USB-Speichergerät
Vendor Description: Kompatibles USB-Speichergerät
Vendor ID: 0781

This will be difficult to fix for two reasons:

I don't own any USB 3.0 mass storage device to reproduce the problem
If the library doesn't crash or throw an exception, then the problem probably has something to do with the OS or with the SDK

Which OS exactly are you using?
Sind Sie aus Deutschland oder aus Österreich?

Thanks for the quick reply.
I use Windows and the problem occurs with all systems available here. As I found out in the meantime, it does not only affect USD 3.0 devices. I also have a high CPU load while waiting.
I am from Germany :-)

Windows means WMI and WMI can be very problematic. Do you use Windows 7, 8, 10?
This will be very hard to debug for me, because all my USB devices work OK. Can you please list all the USB devices are you using?
In the past I have already changed the WMI code a few times. It would be very helpful if you could try all versions of Usb.Events - perhaps one of the older versions with different WMI code works - then I could at least see where the problem might be.
I visited Berlin in January 2020 :) Great city! :)

found it...
using ManagementObjectSearcher Win32_DiskDrive = new ManagementObjectSearcher( $"SELECT DeviceID FROM Win32_DiskDrive WHERE PNPDeviceID LIKE '%{serial}%'");
SerialNumber in Win32_DiskDrive  holds only the first 20 chars. My USB 3.0 Sticks on error have much longer serials. So GetDevicePath returns every time null and we run all the loops in calling function.
->
Serial: 0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9
Device System Path: USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9
In Win32_DiskDrive we have only:  Name: SerialNumber      Value: 0501f3e04b26dcbd25fc
I have another faulty stick with a interesting serial 5&1E7D8DB7&0&3. This one appears in Win32_DiskDrive only as null

Do you use Windows 7, 8 or 10? This is really important, because I have personal experience with WMI behaving differently in different Win versions.
Can you please list all the USB devices are you using? Vendor and model? It would really help me a lot, so I can ask my friends if I can borrow something similar, so I can debug and reproduce the problem. I can't find a solution without that.

Windows 10, SanDisk Ultra Flair USB 3.0 Flash Drive 32 GB, 150MB/s (long Serial). The other is a KiWiBiRD SD Micro SD Adapter for USB 2.0.

Thanks for the info, I will try to borrow something similar! :)
The biggest problem with WMI is that each USB device is registered in several different WMI classes and that these classes don't always share the same unique identifier, so it is difficult to match a device in two different WMI classes, but you have to, because different classes hold different useful information.
In the past I have tried a ManagementEventWatcher for Win32_PnPEntity and Win32_USBHub but now I am using Win32_USBControllerDevice
GetDevicePath is exactly the code that I have changed a few times in the past. Perhaps an older version of the library really would work without problems, because it is using Win32_PnPEntity or Win32_USBHub instead of Win32_USBControllerDevice.

I think I am getting closer to the solution.
Can you please copy/paste the debug output of the DebugOutput() method when you insert the USB?
There should be two, I need both:
First:
AccessState =
Antecedent = \\URBAN-PC\root\cimv2:Win32_USBController.DeviceID="PCI\\VEN_8086&DEV_1C2D&SUBSYS_1C2D1849&REV_05\\3&11583659&0&D0"
Dependent = \\URBAN-PC\root\cimv2:Win32_PnPEntity.DeviceID="USB\\VID_0951&PID_1625\\0019E06B9C85F9A0F7550C20"
NegotiatedDataWidth =
NegotiatedSpeed =
NumberOfHardResets =
NumberOfSoftResets =

Second:
AccessState =
Antecedent = \\URBAN-PC\root\cimv2:Win32_USBController.DeviceID="PCI\\VEN_8086&DEV_1C2D&SUBSYS_1C2D1849&REV_05\\3&11583659&0&D0"
Dependent = \\URBAN-PC\root\cimv2:Win32_PnPEntity.DeviceID="USBSTOR\\DISK&VEN_KINGSTON&PROD_DT_101_II&REV_1.00\\0019E06B9C85F9A0F7550C20&0"
NegotiatedDataWidth =
NegotiatedSpeed =
NumberOfHardResets =
NumberOfSoftResets =

AccessState =
Antecedent = \DESKTOP-P0MP18K\root\cimv2:Win32_USBController.DeviceID="PCI\VEN_8086&DEV_A2AF&SUBSYS_86941043&REV_00\3&11583659&0&A0"
Dependent = \DESKTOP-P0MP18K\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9"
NegotiatedDataWidth =
NegotiatedSpeed =
NumberOfHardResets =
NumberOfSoftResets =
Availability =
Caption = USB-Massenspeichergerät
ClassGuid = {36fc9e60-c465-11cf-8056-444553540000}
CompatibleID = System.String[]
ConfigManagerErrorCode = 0
ConfigManagerUserConfig = False
CreationClassName = Win32_PnPEntity
Description = USB-Massenspeichergerät
DeviceID = USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9
ErrorCleared =
ErrorDescription =
HardwareID = System.String[]
InstallDate =
LastErrorCode =
Manufacturer = Kompatibles USB-Speichergerät
Name = USB-Massenspeichergerät
PNPClass = USB
PNPDeviceID = USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9
PowerManagementCapabilities =
PowerManagementSupported =
Present = True
Service = USBSTOR
Status = OK
StatusInfo =
SystemCreationClassName = Win32_ComputerSystem
AccessState =
Antecedent = \DESKTOP-P0MP18K\root\cimv2:Win32_USBController.DeviceID="PCI\VEN_8086&DEV_A2AF&SUBSYS_86941043&REV_00\3&11583659&0&A0"
Dependent = \DESKTOP-P0MP18K\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_1908&PID_0226\5&1E7D8DB7&0&3"
NegotiatedDataWidth =
NegotiatedSpeed =
NumberOfHardResets =
NumberOfSoftResets =
Availability =
Caption = USB-Massenspeichergerät
ClassGuid = {36fc9e60-c465-11cf-8056-444553540000}
CompatibleID = System.String[]
ConfigManagerErrorCode = 0
ConfigManagerUserConfig = False
CreationClassName = Win32_PnPEntity
Description = USB-Massenspeichergerät
DeviceID = USB\VID_1908&PID_0226\5&1E7D8DB7&0&3
ErrorCleared =
ErrorDescription =
HardwareID = System.String[]
InstallDate =
LastErrorCode =
Manufacturer = Kompatibles USB-Speichergerät
Name = USB-Massenspeichergerät
PNPClass = USB
PNPDeviceID = USB\VID_1908&PID_0226\5&1E7D8DB7&0&3
PowerManagementCapabilities =
PowerManagementSupported =
Present = True
Service = USBSTOR
Status = OK
StatusInfo =
SystemCreationClassName = Win32_ComputerSystem

I committed some changes. Can you pull and check if it is working?
If it is not working, please copy paste the debug output for only one device: SanDisk Ultra Flair USB 3.0 Flash Drive
These are the important lines:
Dependent = \\URBAN-PC\root\cimv2:Win32_PnPEntity.DeviceID="USB\\VID_0951&PID_1625\\0019E06B9C85F9A0F7550C20"

Dependent = \\URBAN-PC\root\cimv2:Win32_PnPEntity.DeviceID="USBSTOR\\DISK&VEN_KINGSTON&PROD_DT_101_II&REV_1.00\\0019E06B9C85F9A0F7550C20&0"

So, for SanDisk I need one line that has USB\\ in the middle and another line that has USBSTOR\\ in the middle.

thanks for the effort. Unfortunately, I don't think much has changed in terms of behavior.
best regards,
Carsten
AccessState =
Antecedent = \DESKTOP-P0MP18K\root\cimv2:Win32_USBController.DeviceID="PCI\VEN_8086&DEV_A2AF&SUBSYS_86941043&REV_00\3&11583659&0&A0"
Dependent = \DESKTOP-P0MP18K\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9"
NegotiatedDataWidth =
NegotiatedSpeed =
NumberOfHardResets =
NumberOfSoftResets =
Availability =
Caption = USB-Massenspeichergerät
ClassGuid = {36fc9e60-c465-11cf-8056-444553540000}
CompatibleID = System.String[]
ConfigManagerErrorCode = 0
ConfigManagerUserConfig = False
CreationClassName = Win32_PnPEntity
Description = USB-Massenspeichergerät
DeviceID = USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9
ErrorCleared =
ErrorDescription =
HardwareID = System.String[]
InstallDate =
LastErrorCode =
Manufacturer = Kompatibles USB-Speichergerät
Name = USB-Massenspeichergerät
PNPClass = USB
PNPDeviceID = USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9
PowerManagementCapabilities =
PowerManagementSupported =
Present = True
Service = USBSTOR
Status = OK
StatusInfo =
SystemCreationClassName = Win32_ComputerSystem
SystemName = DESKTOP-P0MP18K
"Usb.Events.Test.exe" (CoreCLR: clrhost): "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.11\System.ComponentModel.dll" geladen. Das Laden von Symbolen wurde übersprungen. Das Modul ist optimiert, und die Debugoption "Nur eigenen Code" ist aktiviert.
AccessState =
Antecedent = \DESKTOP-P0MP18K\root\cimv2:Win32_USBController.DeviceID="PCI\VEN_8086&DEV_A2AF&SUBSYS_86941043&REV_00\3&11583659&0&A0"
Dependent = \DESKTOP-P0MP18K\root\cimv2:Win32_PnPEntity.DeviceID="USBSTOR\DISK&VEN__USB&PROD__SANDISK_3.2GEN1&REV_1.00\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407"
NegotiatedDataWidth =
NegotiatedSpeed =
NumberOfHardResets =
NumberOfSoftResets =

Thank you for the USBSTOR\ - now I know what the problem is! :)
USB\ has longer serial:
DeviceID="USB\VID_0781&PID_5591\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407094C4000000000000000000001C68EEC2FF1B021091558107A4281CC9"
and USBSTOR\ has shorter serial:
DeviceID="USBSTOR\DISK&VEN__USB&PROD__SANDISK_3.2GEN1&REV_1.00\0501F3E04B26DCBD25FCCD682AEB3CEE13B090D4CC0EEECAA0CEDA20E82E407"
and it is not the same as the serial in Win32_DiskDrive: 0501f3e04b26dcbd25fc
The USBSTOR\ is like a foreign key that connects Win32_USBController and Win32_DiskDrive, but my code is using the serial from USB\ and not from USBSTOR\ because for every device that I have, they are the same.
I hope that now I can fix this! :)

@cksoft0807 It should work now! :) Can you check?

Hi Jinjinov. Works perfectly now with all my devices. Great work!
Thanks and greetings,

I am glad it works! :) Thank you for all your help and valuable feedback!


Add GitHub action to automatically update renovate config

Description
Currently we have to manually edit the renovate config file to always point to the last 3 releases.
This PR automates the process and creates a github action that creates a PR that updates the file.
The implementation uses node as the official reference library for JSON5 parsing was implemented in node.
How can this be tested?
Create a release branch and check if the PR for .github/renovate.json5 was created.
Checklist

[x] Unit tests have been updated/added
[x] PR is labeled accordingly with a single label
[x] I have read and understood the contribution guidelines

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

Project coverage is 66.82%. Comparing base (34a8044) to head (fa63337).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2871   +/-   ##
=======================================
  Coverage   66.82%   66.82%
=======================================
  Files         253      253
  Lines       13787    13787
=======================================
  Hits         9213     9213
  Misses       3767     3767
  Partials      807      807

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


Custom metrics provider notebooks

Updated custom metrics providers notebook. For more info look at https://github.ibm.com/aiopenscale/tracker/issues/23914#issuecomment-39205309

@arsuryan - Please review

Approved - but I do not see any Approval option here.


Version Packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
<EMAIL_ADDRESS>Patch Changes

#304 9c5df06 Thanks @jevakallio! - Update create and init templates to use Class API

<EMAIL_ADDRESS>Patch Changes

#304 9c5df06 Thanks @jevakallio! - Update create and init templates to use Class API

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


imp(contracts): store consensus hash instead of consensus state

closes: #31

Before merging this, make sure it runs e2e, I don't have enough gas to test it at the moment. Also, update the Solidity state variable name to consensusStateHashes and update its NatSpec docs


insert() or splice() method

One thing that seems to be missing is an insert() or splice() method. Is this something that would make sense to add to Clusterize, or is there some optimizations that prevent inserting at a specific row index? Also, what's the significance between camelCase and under_score notation in the API?
Btws, I would like to highlight Clusterize is fantastic. I've been rewriting my apps to use for grid-views, lists, and excited to plugin to Infinite Tree soon too. It's perfect in its simplicity and usefulness.

Hi.
Well, at the moment insert and splice may be emulated by:
// pseudocode

var rows = ['<td/>', '<td/>', '<td/>']
var clusterize = new Clusterize({
  rows: rows,
  ...
})

rows.splice(some, magic, here)

clusterize.update(rows)

significance between camelCase and under_score notation in the API

my bad. totally missed that part during development, and then later after publishing I didn't want to break version releasing api changes :\

It's perfect in its simplicity and usefulness.

Thank you :)

Thank you for your thoughtful response. The solution you provide works well for me. I took a look through the code, and see this is basically the same as it would be implemented internally. I don't believe it's a necessary addition to the API, so am closing this issue.


feedback: merge conflicts

For a future class, you might want to start with a standard merge conflict resolution using Atom. That way, students can familiarize themselves with the syntax. It was also slightly difficult to scan the conflict difference between blank space and a normal line of code (e.g., since many blank spaces already exist in both files); Lines like cout << "This code was written by Sarah.\n"; vs cout << "Chris wrote this.\n"; might work better.

I second this, it would also help to have a set of commands to run in case there are set-up issues (which would keep others from keeping pace with the rest of the class).
Additionally it would be great to send out a pre-class poll to see which type of conflict may benefit the audience in case they want to see particular patterns of conflicts resolved versus others.

Appreciate this feedback, @glennon and @dcam2015. Can only give quick answers to a few concerns, but here goes:

We don't start with Atom, since so many attendees have very strong editor preferences and would feel like we're shilling (even though it's FOSS).
The hardest part of any class is adapting to a heterogeneous audience, and I completely understand the frustration -- sorry for that.

@patrickmckenna
I thought this webinar was very informative and useful. The pace was a little fast - but that is good. Reviewing the recording and keep experimenting with the repo can help clarify what was shown.
I would be interested in a more advanced follow up class. Especially focusing on using the reflog and more info on rebasing to master.

@alezandro Thanks for the feedback. You may be interested in this blog post, which was written by a fellow trainer.


Add rest server support for wasm module, to query and create tx

Summary
We only have CLI, and we will want to add support for a rest server. This would go into x/wasmd/client/rest and be exposed with the standard wasmcli rest server.
Problem Definition

We want to allow webapps to do everything we can do in the CLI. I have no clear design for the urls, so the first part is maybe to propose a set of endpoints. I want queries and ability to submit the 3 tx defined in this module. This will be the basis for a js api.
This will also probably involve refactoring the Querier a bit to allow better reuse between cli and rest.
Proposal

To be filled in (add your proposal of endpoints in the comments, please)

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

I feel endpoints should be grouped separately for code and contract. Here is the list of endpoints I think should be good. I wanted to make sure they don't deviate much from client.
Transactions:
POST /code/store
POST /contract/Instantiate
POST /contract/Execute
Query:
GET /code/list
GET /code/query
GET /contract/list
GET /contract/info
GET /contract/state

@sahith-narahari can you elaborate on the reason for the code - contract separation please?
IMHO their lifecycles are related. There can not be any contract instance without the code. Neither should we delete a code entry and keep an instance running for example.
I would propose the following endpoints with json body.
Create Contract
POST /wasm/contract
Requires:

Sender
WASMByteCode

Returns:

Code: 201 - Created
Body: codeID - unique identifier
Header: Location: /wasm/contract/<codeID>

Create Instance
POST /wasm/contract/<codeID>
Requires:

Sender
InitMsg (or should be optional?)
InitFunds (or should be optional?)

Returns:

Code: 201 - Created
Body: ContractAddr - unique sdk address
Header: Location: /wasm/contract/<ContractAddr>

Execute contract
POST /wasm/contract/<ContractAddr>
Requires:

Sender
Msg
SentFunds (or should be optional?)

Returns

Status: 200 - OK
Body:

Data:    contract result data
Log:     contract result log
GasUsed

Future endpoints ?
DELETE /wasm/contract/<ContractAddr>
Requires:

Sender

Returns:

Code 200

Thank you both for your comments.
In general, the list looks correct for scope @sahith-narahari  And I do agree (to 95%) with the detailed version from @alpe , thanks for spec'ing this more. It does look more RESTful,
The one issue with the second part is the confusion between /wasm/contract/<codeID> and /wasm/contract/<ContractAddr>. We cannot have two identical endpoints with different functions. I would make it:

POST /wasm/code -> create code
POST /wasm/code/<codeID> -> instantiate code (from one instance, returns contract instance)
POST wasm/contract/<contractAddr> -> execute one contract

The DELETE is interesting, but very unlikely ever to be used (immutible contracts and all), however, there is a request for upgradable contracts, so we'll see...

Sticking with that pattern, I would make the queries more "RESTFUL":

GET /code/ -> list all code IDs
GET /code/<codeID> -> details of one code ID
GET /contract/ -> list all contracts addresses
GET /contract/<contractAddr> -> info on one contract
GET /contract/<contractAddr>/state -> internal state of one contract

I am unsure about code/contract vs codes/contracts, maybe the plural is more common in rest? But I do like consistency, not /contracts to list and /contract/<addr> for details.
And all cli flags we want to support should be turned into query args ?foo=bar style.
What do you think here?

Thanks for the detailed explanation @alpe @ethanfrey. My main motto behind the separation was ListCode and ListContract will create an ambiguity with same endpoints.
I agree the better solution would be to separate only the query list APIs and maintain all the other endpoints as /wasm/contract consistently.

Regarding contract/contracts I'm also in favor of using singulars to maintain consistency across various requests

Sorry about the ambiguity in the path of my proposal. I was doing some edits before submitting. It was like this before:

Instance
POST /wasm/code/<codeID>/instance
Execute
POST /wasm/code/<codeID>/instance/<ContractAddr>

This reflects the dependency between code and contract in a REST-ish style but for execution the caller would need to know or resolve codeID and contractAddr. That may not be very convenient.
@ethanfrey your proposal is a good compromise.

Please note that #12 changes the contract state querier, so don't implement that part until #12 is merged and rebase on the new master

Thanks @ethanfrey for the heads up, will ensure that.

Is there an official doc for the rest paths? It's not clear which style got accepted

The REST integration was deprecated and is removed now. Instead there is a grpc-rest gateway endpoint. You can see the path defined in in the query proto file


Toggle Directive

Solves https://github.com/ngOfficeUIFabric/ng-officeuifabric/issues/38

Clean PR: https://github.com/ngOfficeUIFabric/ng-officeuifabric/pull/65


Link-dropdown breaks in TinyMCE when other EditorConfig is used on one of the Elements

Affected Version
This bug exists in ^4 and ^5 release lines.
I've tested it against 5.1.0 and 4.11.0
Description
When using multiple TinyMCEConfig-configurations, for example to have a small editor and a full editor, the sslink dropdown stops working. This occurs when you have 2 (or more) different elements on one page, where one of them is using an own TinyMCEConfig-configuration. The link-functionality stops working. Only the first Element that was opened, will have a working link in the editor.
https://github.com/silverstripe/silverstripe-elemental/assets/795238/985bdf7b-d29b-4217-8d3c-5dec6bd82292
Steps to Reproduce

Install elemental in SS5 or SS4 (via composer.json)

        "silverstripe/recipe-cms": "^4",
        "dnadesign/silverstripe-elemental": "*"

or
        "silverstripe/recipe-cms": "^5",
        "dnadesign/silverstripe-elemental": "*"

Add Elemental-area to alle pages (via elemental.yml)

Page:
  extensions:
    - DNADesign\Elemental\Extensions\ElementalPageExtension

Create a new TinyMCE editor config (via _config.php)

    $oSmallEditor = clone TinyMCEConfig::get('cms');
    $oSmallEditor->setButtonsForLine(1, []);  // not  neccecary, but makes easier to see the diffrence between editors
    HTMLEditorConfig::set_config('cms_small', $oSmallEditor);

Create a new Element with a diffrent tinymce-config

class TextImageElement extends BaseElement
    {
        private static $table_name = 'Elemental_TextImage';
        private static $singular_name = 'Text Alternate';
        private static $icon = 'font-icon-block-promo-3';

        private static $db = [
            'ContentFirst'  => 'HTMLText',
        ];

        public function getCMSFields()
        {
            $oFields = parent::getCMSFields();

            $oFields->addFieldsToTab('Root.Main', [
                    HTMLEditorField::create('ContentFirst', 'Area with cms_small-config')->setEditorConfig('cms_small'),
                ]
            );

            return $oFields;
        }
    }

Add two diffrent elements to a page
Observe the link-dropdown is broken on the second element you open

I've done some initial investigation in to this, I can replicate this in CMS 4.13 and 5.1 though it looks very hard to fix this.

HtmlEditorField.js (react component, not entwine) will load a script tag with a src pointing to a generated tinymce file in public/assets/_tinymce when you open an element
Different files are created for different configs e.g. tinymce-cms-07deb9ef54.js for default config or tinymce-cms_small-6d3061b8d8.js for custom config
These files are generated by TinyMCECombinedGenerator.php
The generated files define window.tinymce (and window.tinyMCE)
There is logic in HtmlEditorField.js to only create a script tag if window.tinymce is undefined
This means that whatever element you open first will have its tinymce script loaded and the 'link' dropdown will work for that element, but not the other element that uses a different config
If you modify the javascript so that you loaded the script regardless if window.tinymce is defined or not, and you comment out the if (window.tinymce) { return } js statement in TinyMCECombinedGenerator.php, things won't magically work as window.tinymce will just get defined again.

Seems like the existing system simply isn't designed to have multiple tinymce configs loaded at the same time.

Thanks for looking into it @emteknetnz !
The conclusion is fine, apparently this combination is not working for Elemental. Although limiting the buttons on the editor is user-friendly, it is not a major issue.
Because it is such a strange behavior, it took us a while to find the cause. So hopefully this issue will at least help future visitors identify and solve this problem (tldr: don't use multiple tinymce configs in combination with elemental).
It's probably wiser to spend time on more common issues. Should we close this issue, or dou you want to leave it open?

Just leave it open for now

For others hitting this issue, I've found 2 slightly hacky work-arounds. Either:

Set the elemental block to private static $inline_editable = false; so that it has to edit on it's own screen, or
On the relevant Page class, add a hidden HTMLEditorField with the same config that you want your block(s) to use - this will create the required config file which inline-editable blocks can then use without having to generate their own.

I'm also experiencing this issue when the page has HTMLEditor fields that use a different config (eg for an intro field).
This bug seems quite similar to this one:
https://github.com/silverstripe/silverstripe-admin/issues/1512
Perhaps the PR for that has some hints for how to fix this.

@GuySartorelli I've added some AC's re merge-ups and contraints to follow - just update the constraints in the manual merge-up and ping me so I can double check them as a form of peer review

cross-major mergeup commits to validate added to description looks good


Retrieve avatar fix

fixes https://sqbu-github.cisco.com/WebExSquared/web-client/issues/4406
queries the _values.id in the case that there is a user._values and no user.id

Is this to deal with the web client's use of ampersand state? We should fix that in the web client by passing user.serialize()

Ok, yea. The fact that it has an _values.id but no id implies that an ampersand object got copied instead of serialized. When the copied happened, all of its getters and setters were lost, thus the resultant object only has a _values. This should be fixed in the web client. There's a (rather forgiving) set of requirements for parameters passed to retrieveAvatarUrl; it's up to the consuming code to meet those requirements, not the other way around.
-Ian
On Nov 1, 2016, 3:42 PM -0700, nickclar<EMAIL_ADDRESS>wrote:

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/ciscospark/spark-js-sdk/pull/306#issuecomment-257721239), or mute the thread (https://github.com/notifications/unsubscribe-auth/ABIKmW0v2j4maIZvRLV6-clmxSn6KVwiks5q58BvgaJpZM4Kmm3p).

ok, thanks for the more information. I was going with my first idea and backed by Matt's comment. I'll look into the web client to see how this can be correctly fixed.


add longzhu

add longzhu

Closing this PR for now, feel free to open it again once you've done the changes.


[ISSUE] /.dropbox file not ignored

For years I have used Dropbox in Windows and Linux (Fedora) with Dropbox folder on a shared (between Windows and Linux) NTFS partition mounted in both Windows and Linux. After the Dropbox company decided to do not support non native filesystems (like NTFS in Linux) any more I have used https://github.com/dark/dropbox-filesystem-fix but recently it has stopped working reliably. So I turned to Maestral. It works great with a minor glitch in my use case. During the each sync, Maestral is trying to sync (upload) /.dropbox file and /.dropbox.cache folder created by Dropbox while running under Windows. Dropbox servers are then refusing to sync these system files when Maestral runs and Maestral notifies me about the sync issues, which is very annoing.
As written here (https://help.dropbox.com/installs-integrations/sync-uploads/files-not-syncing), .dropbox file should be ignored but it's not, because is not included in EXCLUDED_FILE_NAMES in constants.py:
EXCLUDED_FILE_NAMES = (
'desktop.ini', 'thumbs.db', '.ds_store', 'icon\r', '.dropbox.attr',
'.com.apple.timemachine.supported', OLD_REV_FILE
)
I solved the problem temporarily by creating /.mignore file with following content:
.dropbox
.dropbox.cache
Is this the proper way how to handle my problem?
Wouldn't be better to include those two files in EXCLUDED_FILE_NAMES?

Is this the proper way how to handle my problem?

For now, this is the only way...

Wouldn't be better to include those two files in EXCLUDED_FILE_NAMES?

I think this would make sense. Thanks for the report!


Build failure on swift 3.2

Trying to build an app(swift 3.2) from command line and getting a build failure.
Xcode 8.3.3
Kingfisher 4.1.0
Command: set -o pipefail && xcodebuild clean build test -workspace Susi.xcworkspace -scheme Susi -sdk iphonesimulator -destination 'platform=iOS Simulator,name=iPhone 7,OS=10.3.1' | xcpretty --test --color
O/P:
❌  /Users/exxon/Projects/susi_iOS/Pods/Kingfisher/Sources/ImageView+Kingfisher.swift:256:2: @objc cannot be applied to this declaration

@objc extension ImageView {
~^~~~~

** BUILD FAILED **

The following build commands failed:
	CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
	CompileSwift normal x86_64 /Users/exxon/Projects/susi_iOS/Pods/Kingfisher/Sources/ImageView+Kingfisher.swift
(2 failures)
2017-10-05 02:34:13.064 xcodebuild[26708:1000654]  IDETestOperationsObserverDebug: Writing diagnostic log for test session to:
/Users/exxon/Library/Developer/Xcode/DerivedData/Susi-diaqqbbkootsgpcfnbeooroyfjde/Logs/Test/F2853A93-33B3-46E1-936E-2EAD9FFD951E/Session-SusiUITests-2017-10-05_023413-fioC6s.log
2017-10-05 02:34:13.064 xcodebuild[26708:1000627] [MT] IDETestOperationsObserverDebug: (9E439796-AB0C-456E-BA44-E6E67796A2D1) Beginning test session SusiUITests-9E439796-AB0C-456E-BA44-E6E67796A2D1 at 2017-10-05 02:34:13.064 with Xcode 8E3004b on target <DVTiPhoneSimulator: 0x7ff672ec70e0> {
		SimDevice: SimDevice : iPhone 7 (EFFE0BEA-8B1C-4DE7-94E5-1CE1190903BA) : state={ Shutdown } deviceType={ SimDeviceType : com.apple.CoreSimulator.SimDeviceType.iPhone-7 } runtime={ SimRuntime : 10.3.1 (14E8301) - com.apple.CoreSimulator.SimRuntime.iOS-10-3 }
} (10.3.1 (14E8301))

how did u solve this?

I used v3 of the pod.

@ivanbruel Kingfisher 4 is for Swift 4 and 3.2. If you are still using Swift 3.1 or earlier (Xcode 8), you have to use Kingfisher 3.x instead.


Error running large amount of tests

Testing #21306
Running this tests

First run the test with 100, and everything seems to work, then update the range to 100000. The tests start to run, the wheel appears in the previous 100, when the test ends I see that the previous 100 appear as complete, but the new ones appear as if they were never run.

Hi! When you switched to 10,000 did you reload the test UI?

No, i only run the tests again

I am still not able to repro this, these are the steps I followed. Could you provide steps or a video?

Open inc_dec_example_repo
discover tests with pytest
change from @pytest.mark.parametrize("num", range(1, 10)) to @pytest.mark.parametrize("num", range(1, 100))
do not click save instead just click the "run" button in the test explorer UI (double arrow at the top to run all tests)
I see all the 100 tests with the green checkmark

@paulacamargo25 to follow up, do you still experience this issue?

What i did extra is that i run the first tests. yes sure, im going to try again

so like:

Open inc_dec_example_repo
discover tests with pytest
run pytest
change from @pytest.mark.parametrize("num", range(1, 10)) to @pytest.mark.parametrize("num", range(1, 100))
do not click save instead just click the "run" button in the test explorer UI (double arrow at the top to run all tests)
I also tried using the gutter with the parameterize test to run it which also did not work in repro the bug
I see all the 100 tests with the green checkmark

I was able to reproduce the issue, the problem occurs when you save the file and immediately run the tests afterwards.
https://github.com/microsoft/vscode-python/assets/17892325/b374af74-fc83-42fb-88b4-0d781fddd268

this seems to be the fix so we can test when this is merged to make sure. Thanks!

verification steps:

Open a repo with pytest parameterized tests
discover tests with pytest
run pytest
change from @pytest.mark.parametrize("num", range(1, 10)) to @pytest.mark.parametrize("num", range(1, 100))
save file
click the "run" button in the test explorer UI (double arrow at the top to run all tests)

Sorry to add the verification-steps-needed label, I know you have steps, but I am still stuck.

No worries!! I was rushing a bit when I wrote the steps so missed some important parts:

In your settings file set "python.experiments.optInto": ["pythonTestAdapter"],
Open a repo with pytest parameterized tests or create a new blank repo
create a file that starts with test_ or end with _test and add the code @alexr00 included above
discover tests with pytest
run pytest
change from @pytest.mark.parametrize("num", range(1, 10)) to @pytest.mark.parametrize("num", range(1, 100))
save file
click the "run" button in the test explorer UI (double arrow at the top to run all tests)

In Paula's demo, there is no step 7. Clicking the run button seems to save the file for me, and I still see a bug that way:
The green checkmarks seem to be updated more consistently after I change it from range(1, 10) to range(1, 1000), but the counter at the top still says 29/37 tests passed.

delaying to next iteration as I have to make some design decisions around how to best render with dirty changes vs cache for pytest.


not work on https clickhouse

Describe the bug
Steps to reproduce

this.client = createClient(options);
its work on http client, but not work in https client

Expected behaviour
Code example
Error log
Configuration
Environment

Client version:   "@clickhouse/client": "^0.0.12",
Language version: node js 16.16
OS: windows/linux

ClickHouse server

ClickHouse Server version:  23.1.3
ClickHouse Server non-default settings, if any:
CREATE TABLE statements for tables involved: can't do anything recieve not expected error can't parse data from JSONEACHROW, but problem is in connection
Sample data for all these tables, use clickhouse-obfuscator if necessary

How do you create a client? Usually, it should work as

const client = createClient({
  host: 'https://<hostname>:<port>',
  username: '<username>',
  password: '<password>',
})

Does your server require TLS? If so, please check out the certificates usage docs, and sample code)


Uninitialized Pointers not null by default?

The document says that uninitialized pointers are set to a random value, but when I test it out, they are assigned null when not explicitly initialized.
Perhaps the document is describing the standard and not the practice of the Microsoft compilers?

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

ID: 2284bc5b-569d-81ee-0b8d-38c711c92656
Version Independent ID: d448ee76-816d-67a9-6c1d-19da30933822
Content: Raw pointers (C++)
Content Source: docs/cpp/raw-pointers.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

@DavidBChristensen
The docs are describing the C++ standard behavior. What you actually get, depends. The compiler, at least in release builds, doesn't do any initialization of raw pointers unless you specify it. The value you're likely to see when you examine the contents of an uninitialized variable depends on several things. In debug builds, memory blocks are often initialized with sentinel values upon allocation. You can read about those in CRT Debug Heap Details. There are also flags that will cause the heap blocks handed out by Windows to get initialized. If you create a pointer on the stack somewhere and the stack hasn't advanced that far before, you might get zero-initialized memory. If the stack recedes and then advances again, you'll likely get whatever value was there before.
The lesson remains, always initialize before you access something.


enable download models from url in merged_models.json

Types of changes

[ ] 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)
[ ] I have read the CONTRIBUTING document.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Hi @willwade , please check this PR for downloading new models using merged_models.json

Question

DO you think we should create a dev function. It would a) get huggingface JSON b) generate JSON using createindex.py - c) merge both JSON and save to the repo. Remove any other json in this repo

sherpa-onnx then would getVoices with no token or model path - with ALL data in the local JSON. Actually speeding things up as the end user doesnt download this file..

rename local download path to not ~/mms but ~/sherpaonnx or something more relevant

I think a user should be able to provide their own onnx path - and then settings for this generation too..
I have a feeling it may not work great. In part because my createindex.py was broken. It was calculating the language codes correctly of each model etc.

You'll hate this.. i do to but its worth it!
install ruff
pip install ruff
then
ruff check --select=ALL --fix --unsafe-fixes  tts_wrapper/engines/sherpaonnx/client.py
run through it and see if you can fix it - ignore line length issues.
I'll do this on ALL the code at some stage but for now we might as well start with this engine which is definitely one of the most complex

Ok Will, I'll check this out

Hi @willwade , updated with changes from ruff.
I'll create a new PR for the auto generation of model list json

Great. Let me merge this so we don't lose track of things too much. I'm still fiddling with the other big pr on formatting & tests (I merged it into it). I'll try and get that as far as I can today and merge that too.