OOM during sync

Describe the bug
There is likely a memory leak in the reth syncing pipeline. With 128GB RAM available, the process has failed due to OOM errors.
I did not get the commit hash which produced the OOM, but after pulling main 9e72cbf6b44fd195738c6d85f461304578c8156c, recompiling, and restarting the process has already ballooned to ~90GB.

Steps to reproduce
$ git checkout 9e72cbf6b44fd195738c6d85f461304578c8156c

$ RUSTFLAGS="-C target-cpu=native" cargo build --profile maxperf

$ reth node

Node logs
Here is the latest log with a block referenced in case the sync point helps is useful.

Jun 22 17:47:38 reth[149860]: 2023-06-22T17:47:38.412442Z  INFO try_insert_validated_block{block=(17536667, 0xf73ffd11d424742f9d0b303cc461db8df69c38772e1c43a82feff5b25f0ae691)}:try_append_canonical_chain:try_insert_validated_block{block=(17536688, 0xa67e40d64f49c893bff382d1a4d910c6a9a8c8c0ace13ebea4782e6c05e3efa5)}: blockchain_tree: return=Ok(Valid)

Platform(s)
Linux (x86)
What version/commit are you on?
9e72cbf6b44fd195738c6d85f461304578c8156c
What database version are you on?
Current database version: 1
Local database version: 1
If you've built Reth from source, provide the full command you used
RUSTFLAGS="-C target-cpu=native" cargo build --profile maxperf
Code of Conduct

[X] I agree to follow the Code of Conduct

hmm, could you please run with --metrics enabled and share the simple curl response after it ballooned?

After restart with the metrics flag it was practically already at head and it seems to be stable at around 56GB:

Here is the metrics scrape:
# HELP reth_network_received_headers_requests Number of received headers requests
# TYPE reth_network_received_headers_requests counter
reth_network_received_headers_requests 798

# HELP reth_downloaders_headers_timeout_errors Number of timeout errors while requesting items
# TYPE reth_downloaders_headers_timeout_errors counter
reth_downloaders_headers_timeout_errors 0

# HELP reth_network_ping_timeout Number of peer disconnects due to PingTimeout (0x0b)
# TYPE reth_network_ping_timeout counter
reth_network_ping_timeout 0

# HELP reth_network_messages_with_already_seen_hashes Total number of messages with already seen hashes
# TYPE reth_network_messages_with_already_seen_hashes counter
reth_network_messages_with_already_seen_hashes 406670

# HELP reth_downloaders_headers_unexpected_errors Number of unexpected errors while requesting items
# TYPE reth_downloaders_headers_unexpected_errors counter
reth_downloaders_headers_unexpected_errors 0

# HELP reth_network_invalid_messages_received Number of invalid/malformed messages received from peers
# TYPE reth_network_invalid_messages_received counter
reth_network_invalid_messages_received 0

# HELP reth_transaction_pool_inserted_transactions Number of transactions inserted in the pool
# TYPE reth_transaction_pool_inserted_transactions counter
reth_transaction_pool_inserted_transactions 444931

# HELP reth_transaction_pool_removed_transactions Number of removed transactions from the pool
# TYPE reth_transaction_pool_removed_transactions counter
reth_transaction_pool_removed_transactions 204544

# HELP reth_network_subprotocol_specific Number of peer disconnects due to SubprotocolSpecific (0x10)
# TYPE reth_network_subprotocol_specific counter
reth_network_subprotocol_specific 58

# HELP reth_network_messages_with_already_seen_transactions Total number of messages with already seen full transactions
# TYPE reth_network_messages_with_already_seen_transactions counter
reth_network_messages_with_already_seen_transactions 512728

# HELP reth_network_protocol_breach Number of peer disconnects due to ProtocolBreach (0x02)
# TYPE reth_network_protocol_breach counter
reth_network_protocol_breach 0

# HELP reth_network_closed_sessions Total number of sessions closed
# TYPE reth_network_closed_sessions counter
reth_network_closed_sessions 282853

# HELP reth_consensus_engine_beacon_forkchoice_updated_messages The total count of forkchoice updated messages received.
# TYPE reth_consensus_engine_beacon_forkchoice_updated_messages counter
reth_consensus_engine_beacon_forkchoice_updated_messages 1671

# HELP reth_network_too_many_peers Number of peer disconnects due to TooManyPeers (0x04)
# TYPE reth_network_too_many_peers counter
reth_network_too_many_peers 265027

# HELP reth_downloaders_headers_out_of_order_requests The number of out-of-order requests sent by the downloader. The consumer of the download stream is able to re-request data (headers) in case it encountered a recoverable error (e.g. during insertion). Out-of-order request happen when the headers downloader `SyncTarget::Tip` hash is different from the previous sync target hash.
# TYPE reth_downloaders_headers_out_of_order_requests counter
reth_downloaders_headers_out_of_order_requests 0

# HELP reth_downloaders_bodies_validation_errors Number of validation errors while requesting items
# TYPE reth_downloaders_bodies_validation_errors counter
reth_downloaders_bodies_validation_errors 0

# HELP reth_network_unexpected_identity Number of peer disconnects due to UnexpectedHandshakeIdentity (0x09)
# TYPE reth_network_unexpected_identity counter
reth_network_unexpected_identity 0

# HELP reth_downloaders_bodies_timeout_errors Number of timeout errors while requesting items
# TYPE reth_downloaders_bodies_timeout_errors counter
reth_downloaders_bodies_timeout_errors 0

# HELP reth_downloaders_bodies_out_of_order_requests The number of out-of-order requests sent by the downloader. The consumer of the download stream is able to re-request data (bodies) in case it encountered a recoverable error (e.g. during insertion). Out-of-order request happen when the new download range start for bodies downloader is less than the last block number returned from the stream.
# TYPE reth_downloaders_bodies_out_of_order_requests counter
reth_downloaders_bodies_out_of_order_requests 0

# HELP reth_network_pending_session_failures Cumulative number of failures of pending sessions
# TYPE reth_network_pending_session_failures counter
reth_network_pending_session_failures 282028

# HELP reth_db_table_size The size of a database table (in bytes)
# TYPE reth_db_table_size counter
reth_db_table_size{table="HashedAccount"}<PHONE_NUMBER>0
reth_db_table_size{table="SyncStage"} 4096
reth_db_table_size{table="Bytecodes"}<PHONE_NUMBER>
reth_db_table_size{table="AccountHistory"}<PHONE_NUMBER>8
reth_db_table_size{table="HashedStorage"}<PHONE_NUMBER>6
reth_db_table_size{table="Transactions"}<PHONE_NUMBER>88
reth_db_table_size{table="TxSenders"}<PHONE_NUMBER>8
reth_db_table_size{table="AccountsTrie"}<PHONE_NUMBER>
reth_db_table_size{table="CanonicalHeaders"}<PHONE_NUMBER>
reth_db_table_size{table="AccountChangeSet"}<PHONE_NUMBER>36
reth_db_table_size{table="Headers"}<PHONE_NUMBER>2
reth_db_table_size{table="HeaderTD"} 522248192
reth_db_table_size{table="PlainStorageState"}<PHONE_NUMBER>6
reth_db_table_size{table="SyncStageProgress"} 4096
reth_db_table_size{table="StorageChangeSet"}<PHONE_NUMBER>28
reth_db_table_size{table="StorageHistory"}<PHONE_NUMBER>76
reth_db_table_size{table="TransactionBlock"} 419418112
reth_db_table_size{table="Receipts"}<PHONE_NUMBER>56
reth_db_table_size{table="BlockBodyIndices"} 426475520
reth_db_table_size{table="BlockOmmers"} 776269824
reth_db_table_size{table="PlainAccountState"}<PHONE_NUMBER>4
reth_db_table_size{table="BlockWithdrawals"} 296026112
reth_db_table_size{table="TxHashNumber"}<PHONE_NUMBER>68
reth_db_table_size{table="StoragesTrie"}<PHONE_NUMBER>0
reth_db_table_size{table="HeaderNumbers"}<PHONE_NUMBER>

# HELP reth_network_reported_bad_transactions Total number of reported bad transactions
# TYPE reth_network_reported_bad_transactions counter
reth_network_reported_bad_transactions 407

# HELP reth_network_tcp_subsystem_error Number of peer disconnects due to TcpSubsystemError (0x01)
# TYPE reth_network_tcp_subsystem_error counter
reth_network_tcp_subsystem_error 0

# HELP reth_network_incompatible Number of peer disconnects due to IncompatibleP2PProtocolVersion (0x06)
# TYPE reth_network_incompatible counter
reth_network_incompatible 0

# HELP reth_network_connected_to_self Number of peer disconnects due to ConnectedToSelf (0x0a)
# TYPE reth_network_connected_to_self counter
reth_network_connected_to_self 6

# HELP reth_network_active_session_send_errors Number of failed message deliveries
# TYPE reth_network_active_session_send_errors counter
reth_network_active_session_send_errors 1862

# HELP reth_downloaders_headers_total_flushed The number of items that were successfully sent to the poller (stage)
# TYPE reth_downloaders_headers_total_flushed counter
reth_downloaders_headers_total_flushed 0

# HELP reth_network_total_incoming_connections Total Number of incoming connections handled
# TYPE reth_network_total_incoming_connections counter
reth_network_total_incoming_connections 0

# HELP reth_network_total_outgoing_connections Total Number of outgoing connections established
# TYPE reth_network_total_outgoing_connections counter
reth_network_total_outgoing_connections 290438

# HELP reth_network_already_connected Number of peer disconnects due to AlreadyConnected (0x05)
# TYPE reth_network_already_connected counter
reth_network_already_connected 54

# HELP reth_network_disconnect_requested Number of peer disconnects due to DisconnectRequested (0x00)
# TYPE reth_network_disconnect_requested counter
reth_network_disconnect_requested 239

# HELP reth_consensus_engine_beacon_pipeline_runs The number of times the pipeline was run.
# TYPE reth_consensus_engine_beacon_pipeline_runs counter
reth_consensus_engine_beacon_pipeline_runs 0

# HELP reth_downloaders_bodies_total_flushed The number of items that were successfully sent to the poller (stage)
# TYPE reth_downloaders_bodies_total_flushed counter
reth_downloaders_bodies_total_flushed 0

# HELP reth_network_total_dropped_eth_requests_at_full_capacity Number of Eth Requests dropped due to channel being at full capacity
# TYPE reth_network_total_dropped_eth_requests_at_full_capacity counter
reth_network_total_dropped_eth_requests_at_full_capacity 0

# HELP reth_db_table_pages The number of database pages for a table
# TYPE reth_db_table_pages counter
reth_db_table_pages{table="StorageChangeSet",type="overflow"} 0
reth_db_table_pages{table="BlockOmmers",type="overflow"} 0
reth_db_table_pages{table="PlainStorageState",type="branch"} 615313
reth_db_table_pages{table="AccountChangeSet",type="leaf"} 33013712
reth_db_table_pages{table="PlainStorageState",type="overflow"} 0
reth_db_table_pages{table="StorageChangeSet",type="branch"} 3327311
reth_db_table_pages{table="HashedAccount",type="branch"} 66126
reth_db_table_pages{table="TxHashNumber",type="branch"} 590403
reth_db_table_pages{table="HashedStorage",type="branch"} 574776
reth_db_table_pages{table="TransactionBlock",type="leaf"} 101939
reth_db_table_pages{table="AccountsTrie",type="branch"} 5328
reth_db_table_pages{table="BlockBodyIndices",type="leaf"} 103655
reth_db_table_pages{table="HeaderTD",type="branch"} 569
reth_db_table_pages{table="BlockBodyIndices",type="overflow"} 0
reth_db_table_pages{table="AccountHistory",type="overflow"} 461281
reth_db_table_pages{table="CanonicalHeaders",type="overflow"} 0
reth_db_table_pages{table="HashedStorage",type="overflow"} 0
reth_db_table_pages{table="TxSenders",type="overflow"} 0
reth_db_table_pages{table="StoragesTrie",type="overflow"} 0
reth_db_table_pages{table="StorageHistory",type="leaf"} 91550841
reth_db_table_pages{table="HeaderTD",type="leaf"} 126933
reth_db_table_pages{table="BlockWithdrawals",type="branch"} 323
reth_db_table_pages{table="TxHashNumber",type="leaf"} 36056530
reth_db_table_pages{table="SyncStage",type="overflow"} 0
reth_db_table_pages{table="Transactions",type="branch"} 416305
reth_db_table_pages{table="HashedAccount",type="overflow"} 0
reth_db_table_pages{table="StorageChangeSet",type="leaf"} 73632582
reth_db_table_pages{table="BlockBodyIndices",type="branch"} 465
reth_db_table_pages{table="StorageHistory",type="overflow"} 768026
reth_db_table_pages{table="SyncStage",type="leaf"} 1
reth_db_table_pages{table="PlainAccountState",type="branch"} 34080
reth_db_table_pages{table="StoragesTrie",type="leaf"} 4956100
reth_db_table_pages{table="Receipts",type="leaf"} 57891865
reth_db_table_pages{table="HeaderNumbers",type="branch"} 4373
reth_db_table_pages{table="TxSenders",type="branch"} 83801
reth_db_table_pages{table="PlainAccountState",type="leaf"} 3188054
reth_db_table_pages{table="SyncStageProgress",type="branch"} 0
reth_db_table_pages{table="Headers",type="leaf"} 4375736
reth_db_table_pages{table="PlainAccountState",type="overflow"} 0
reth_db_table_pages{table="TxHashNumber",type="overflow"} 0
reth_db_table_pages{table="BlockWithdrawals",type="leaf"} 71949
reth_db_table_pages{table="SyncStageProgress",type="leaf"} 1
reth_db_table_pages{table="CanonicalHeaders",type="branch"} 3529
reth_db_table_pages{table="AccountChangeSet",type="overflow"} 0
reth_db_table_pages{table="Bytecodes",type="overflow"} 2129379
reth_db_table_pages{table="TransactionBlock",type="branch"} 458
reth_db_table_pages{table="AccountChangeSet",type="branch"} 10552679
reth_db_table_pages{table="HeaderNumbers",type="leaf"} 314645
reth_db_table_pages{table="Bytecodes",type="branch"} 1394
reth_db_table_pages{table="SyncStage",type="branch"} 0
reth_db_table_pages{table="Transactions",type="overflow"} 20582814
reth_db_table_pages{table="Headers",type="overflow"} 0
reth_db_table_pages{table="AccountHistory",type="branch"} 182539
reth_db_table_pages{table="AccountsTrie",type="leaf"} 798493
reth_db_table_pages{table="Bytecodes",type="leaf"} 91369
reth_db_table_pages{table="StoragesTrie",type="branch"} 542835
reth_db_table_pages{table="AccountHistory",type="leaf"} 14853983
reth_db_table_pages{table="PlainStorageState",type="leaf"} 21080543
reth_db_table_pages{table="BlockOmmers",type="branch"} 844
reth_db_table_pages{table="BlockWithdrawals",type="overflow"} 0
reth_db_table_pages{table="SyncStageProgress",type="overflow"} 0
reth_db_table_pages{table="Transactions",type="leaf"} 93251509
reth_db_table_pages{table="HashedAccount",type="leaf"} 4103419
reth_db_table_pages{table="HashedStorage",type="leaf"} 18577465
reth_db_table_pages{table="Receipts",type="overflow"} 1447247
reth_db_table_pages{table="StorageHistory",type="branch"} 2551689
reth_db_table_pages{table="HeaderNumbers",type="overflow"} 0
reth_db_table_pages{table="TxSenders",type="leaf"} 18770992
reth_db_table_pages{table="AccountsTrie",type="overflow"} 0
reth_db_table_pages{table="Headers",type="branch"} 38791
reth_db_table_pages{table="HeaderTD",type="overflow"} 0
reth_db_table_pages{table="BlockOmmers",type="leaf"} 188675
reth_db_table_pages{table="Receipts",type="branch"} 258449
reth_db_table_pages{table="CanonicalHeaders",type="leaf"} 425313
reth_db_table_pages{table="TransactionBlock",type="overflow"} 0

# HELP reth_downloaders_headers_total_downloaded Number of items that were successfully downloaded
# TYPE reth_downloaders_headers_total_downloaded counter
reth_downloaders_headers_total_downloaded 0

# HELP reth_network_client_quitting Number of peer disconnects due to ClientQuitting (0x08)
# TYPE reth_network_client_quitting counter
reth_network_client_quitting 81

# HELP reth_consensus_engine_beacon_new_payload_messages The total count of new payload messages received.
# TYPE reth_consensus_engine_beacon_new_payload_messages counter
reth_consensus_engine_beacon_new_payload_messages 1626

# HELP reth_network_received_bodies_requests Number of received bodies requests
# TYPE reth_network_received_bodies_requests counter
reth_network_received_bodies_requests 35

# HELP reth_payloads_failed_jobs Total number of failed jobs
# TYPE reth_payloads_failed_jobs counter
reth_payloads_failed_jobs 0

# HELP reth_network_active_session_messages_sent Number of messages sent
# TYPE reth_network_active_session_messages_sent counter
reth_network_active_session_messages_sent 13145759

# HELP reth_invalid_header_cache_known_ancestor_inserts The number of inserts with a known ancestor.
# TYPE reth_invalid_header_cache_known_ancestor_inserts counter
reth_invalid_header_cache_known_ancestor_inserts 0

# HELP reth_downloaders_bodies_total_downloaded Number of items that were successfully downloaded
# TYPE reth_downloaders_bodies_total_downloaded counter
reth_downloaders_bodies_total_downloaded 0

# HELP reth_network_null_node_identity Number of peer disconnects due to NullNodeIdentity (0x07)
# TYPE reth_network_null_node_identity counter
reth_network_null_node_identity 0

# HELP reth_downloaders_headers_validation_errors Number of validation errors while requesting items
# TYPE reth_downloaders_headers_validation_errors counter
reth_downloaders_headers_validation_errors 0

# HELP reth_payloads_initiated_jobs Total number of initiated jobs
# TYPE reth_payloads_initiated_jobs counter
reth_payloads_initiated_jobs 0

# HELP reth_transaction_pool_invalid_transactions Number of invalid transactions
# TYPE reth_transaction_pool_invalid_transactions counter
reth_transaction_pool_invalid_transactions 200028

# HELP reth_downloaders_bodies_unexpected_errors Number of unexpected errors while requesting items
# TYPE reth_downloaders_bodies_unexpected_errors counter
reth_downloaders_bodies_unexpected_errors 0

# HELP reth_network_useless_peer Number of peer disconnects due to UselessPeer (0x03)
# TYPE reth_network_useless_peer counter
reth_network_useless_peer 6

# HELP reth_network_propagated_transactions Total number of propagated transactions
# TYPE reth_network_propagated_transactions counter
reth_network_propagated_transactions 196299

# TYPE reth_p2pstream_disconnected_errors counter
reth_p2pstream_disconnected_errors 248131

# HELP reth_invalid_header_cache_unique_inserts The number of unique invalid header inserts (i.e. without a known ancestor).
# TYPE reth_invalid_header_cache_unique_inserts counter
reth_invalid_header_cache_unique_inserts 0

# HELP reth_invalid_header_cache_invalid_headers The total number of invalid headers in the cache.
# TYPE reth_invalid_header_cache_invalid_headers gauge
reth_invalid_header_cache_invalid_headers 0

# HELP reth_blockchain_tree_sidechains Total number of sidechains (not including the canonical chain)
# TYPE reth_blockchain_tree_sidechains gauge
reth_blockchain_tree_sidechains 12

# HELP reth_consensus_engine_beacon_active_block_downloads How many blocks are currently being downloaded.
# TYPE reth_consensus_engine_beacon_active_block_downloads gauge
reth_consensus_engine_beacon_active_block_downloads 0

# HELP reth_payloads_active_jobs Number of active jobs
# TYPE reth_payloads_active_jobs gauge
reth_payloads_active_jobs 0

# HELP reth_downloaders_headers_buffered_blocks The number of blocks the internal buffer of the downloader. These are bodies that have been received, but not cannot be committed yet because they're not contiguous
# TYPE reth_downloaders_headers_buffered_blocks gauge
reth_downloaders_headers_buffered_blocks 0

# HELP reth_network_outgoing_connections Number of active outgoing connections
# TYPE reth_network_outgoing_connections gauge
reth_network_outgoing_connections 100

# HELP reth_downloaders_bodies_buffered_blocks_size_bytes Total amount of memory used by the buffered blocks in bytes
# TYPE reth_downloaders_bodies_buffered_blocks_size_bytes gauge
reth_downloaders_bodies_buffered_blocks_size_bytes 0

# HELP reth_downloaders_headers_queued_blocks The number blocks that are contiguous and are queued for insertion into the db.
# TYPE reth_downloaders_headers_queued_blocks gauge
reth_downloaders_headers_queued_blocks 0

# HELP reth_transaction_pool_pending_pool_transactions Number of transactions in the pending sub-pool
# TYPE reth_transaction_pool_pending_pool_transactions gauge
reth_transaction_pool_pending_pool_transactions 737

# HELP reth_transaction_pool_pending_pool_size_bytes Total amount of memory used by the transactions in the pending sub-pool in bytes
# TYPE reth_transaction_pool_pending_pool_size_bytes gauge
reth_transaction_pool_pending_pool_size_bytes 157405

# HELP reth_downloaders_bodies_queued_blocks The number blocks that are contiguous and are queued for insertion into the db.
# TYPE reth_downloaders_bodies_queued_blocks gauge
reth_downloaders_bodies_queued_blocks 0

# HELP reth_downloaders_bodies_buffered_responses The number of responses (can contain more than 1 item) in the internal buffer of the downloader.
# TYPE reth_downloaders_bodies_buffered_responses gauge
reth_downloaders_bodies_buffered_responses 0

# HELP reth_transaction_pool_basefee_pool_size_bytes Total amount of memory used by the transactions in the basefee sub-pool in bytes
# TYPE reth_transaction_pool_basefee_pool_size_bytes gauge
reth_transaction_pool_basefee_pool_size_bytes 1609029

# HELP reth_downloaders_bodies_buffered_blocks The number of blocks the internal buffer of the downloader. These are bodies that have been received, but not cannot be committed yet because they're not contiguous
# TYPE reth_downloaders_bodies_buffered_blocks gauge
reth_downloaders_bodies_buffered_blocks 0

# HELP reth_transaction_pool_queued_pool_transactions Number of transactions in the queued sub-pool
# TYPE reth_transaction_pool_queued_pool_transactions gauge
reth_transaction_pool_queued_pool_transactions 9997

# HELP reth_blockchain_tree_canonical_chain_height The highest block number in the canonical chain
# TYPE reth_blockchain_tree_canonical_chain_height gauge
reth_blockchain_tree_canonical_chain_height 17538537

# HELP reth_downloaders_bodies_in_flight_requests The number of requests (can contain more than 1 item) currently in-flight.
# TYPE reth_downloaders_bodies_in_flight_requests gauge
reth_downloaders_bodies_in_flight_requests 0

# HELP reth_network_connected_peers Number of currently connected peers
# TYPE reth_network_connected_peers gauge
reth_network_connected_peers 94

# HELP reth_downloaders_headers_buffered_responses The number of responses (can contain more than 1 item) in the internal buffer of the downloader.
# TYPE reth_downloaders_headers_buffered_responses gauge
reth_downloaders_headers_buffered_responses 0

# HELP reth_transaction_pool_basefee_pool_transactions Number of transactions in the basefee sub-pool
# TYPE reth_transaction_pool_basefee_pool_transactions gauge
reth_transaction_pool_basefee_pool_transactions 9940

# HELP reth_transaction_pool_queued_pool_size_bytes Total amount of memory used by the transactions in the queued sub-pool in bytes
# TYPE reth_transaction_pool_queued_pool_size_bytes gauge
reth_transaction_pool_queued_pool_size_bytes 3627447

# HELP reth_network_incoming_connections Number of active incoming connections
# TYPE reth_network_incoming_connections gauge
reth_network_incoming_connections 0

# HELP reth_sync_execution_mgas_processed_total The total amount of gas processed (in millions)
# TYPE reth_sync_execution_mgas_processed_total gauge
reth_sync_execution_mgas_processed_total 0

# HELP reth_network_tracked_peers Number of peers known to the node
# TYPE reth_network_tracked_peers gauge
reth_network_tracked_peers 3659

# HELP reth_downloaders_headers_buffered_blocks_size_bytes Total amount of memory used by the buffered blocks in bytes
# TYPE reth_downloaders_headers_buffered_blocks_size_bytes gauge
reth_downloaders_headers_buffered_blocks_size_bytes 0

# HELP reth_blockchain_tree_block_buffer_blocks Total blocks in the block buffer
# TYPE reth_blockchain_tree_block_buffer_blocks gauge
reth_blockchain_tree_block_buffer_blocks 0

# HELP reth_downloaders_headers_in_flight_requests The number of requests (can contain more than 1 item) currently in-flight.
# TYPE reth_downloaders_headers_in_flight_requests gauge
reth_downloaders_headers_in_flight_requests 0

# HELP reth_network_backed_off_peers Number of currently backed off peers
# TYPE reth_network_backed_off_peers gauge
reth_network_backed_off_peers 364

# TYPE reth_tx_commit summary
reth_tx_commit{quantile="0"} 0.000002891
reth_tx_commit{quantile="0.5"} 0.03293234358689049
reth_tx_commit{quantile="0.9"} 0.037019887305705906
reth_tx_commit{quantile="0.95"} 0.037019887305705906
reth_tx_commit{quantile="0.99"} 0.037019887305705906
reth_tx_commit{quantile="0.999"} 0.037019887305705906
reth_tx_commit{quantile="1"} 0.077292855
reth_tx_commit_sum<PHONE_NUMBER>8500025
reth_tx_commit_count 1629

thanks for this we're adding a few more metrics to track down where we grow unbounded memory
I assume this is transaction propagation related

reth_network_active_session_messages_sent 13145759

These are messages received over the wire, I suspect we have an issue with how we apply backpressure here
cc @Rjected

Okay, I'll monitor this issue for updates. As a note, the memory had not stabilized, it is now sitting at 84.3GB.
Let me know if you would me to run any other diagnostics.

@mattsse Sure, it's running. I'll update you in a few hours.

Already at 25GB and growing.
Is reth interested in targeting a specific memory footprint?

Have been running the commit you mentioned and the memory has grown to 32GB on this go round.

Okay, I've restarted it with peers.connection_info.max_outbound = 3. The commit = 54f4f39389f83437142e2dd236bed165c2bad837.
FYI, before restarting, the memory had grown to 56GB.

Please note the memory in that column is not accurate. It is not actually how much memory it uses, since it also counts mmap'd files (which is just an extension of the address space).

Please note the memory in that column is not accurate. It is not actually how much memory it uses, since it also counts mmap'd files (which is just an extension of the address space).

The process was killed because of OOM though. I assume you are referencing the VIRTUAL column, but the RESIDENT column is still growing too high.

Yep, not saying it wasn't killed, just noting for ppl who follow along :) Res does include mmap'd pages though, so it is still not accurate.
See https://github.com/ledgerwatch/erigon#htop-shows-incorrect-memory-usage

Is the memory reported by RES the memory measurement which directly affects the OOM, i.e. if reth was the only process on the computer does RETH_RES_MEM ~= TOTAL_SYSTEM_MEM mean the process will be killed?
If not, which measurement is the one which should be observed to address the OOM issue?

I see. I don't have the OS depth to to understand the mechanism your mentioning, but in my case the OOM error was surfaced in the journalctl for the systemd service unit which runs reth.
Using your command, I was also able to get this log:


⚠ Bofrost.lu has degraded performance

In 0acf4cf, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1701 ms

Resolved: Bofrost.lu performance has improved in 4d1b34c after 44 minutes.


⚠ Bofrost.be has degraded performance

In dd731f7, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 841 ms

Resolved: Bofrost.be performance has improved in 8d0cea7 after 6 minutes.


XDM implementation for ElementNodeConstructor

My comments are most about code location and decreasing object creations.

I did not pull the count change into master. Please include that commit in a later patch so it can be reviewed.


ChatZhipuAI module httpx.HTTPStatusError

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
from langchain_community.chat_models import ChatZhipuAI
llm = ChatZhipuAI(
model="glm-4",
api_key=os.getenv("ZHIPUAI_API_KEY"),
temperature=temperature,
max_tokens=1024,
)
messages = [
AIMessage(content="Hi."),
SystemMessage(content="Your role is a poet."),
HumanMessage(content="Write a short poem about AI in four lines."),
]
response = chat.invoke(messages)
Error Message and Stack Trace (if applicable)
When code runs to the invoke function, an error occurs:
httpx.HTTPStatusError: Client error '400 Bad Request' for url 'https://open.bigmodel.cn/api/paas/v4/chat/completions'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
Description
When code runs to the invoke function, an error occurs:
httpx.HTTPStatusError: Client error '400 Bad Request' for url 'https://open.bigmodel.cn/api/paas/v4/chat/completions'
For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400
System Info
langchain==0.1.14
langchain-community==0.0.33
langchain-core==0.1.44
zhipuai==<IP_ADDRESS>40429
platform: linux
python: 3.8

Let me see.

I'm sorry. I found the reason for the mistake. Because I set the temperature to 0.
I saw a hint in The source code: “What sampling temperature to use. The value ranges from 0.0 to 1.0 and cannot be equal to 0.”


FFM-7316: stages ff relnote for 789xx

Preview environment: https://hdh.pr.harness.io/pr-1116

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Closing PR as this never got to prod or pre-QA per @knagurski


Cannot build Jupyter plugin on Arch

cmake --build jupyter/build
cmake --install jupyter/build

[2/144] Building CXX object CMakeFiles/codon_jupyter.dir/jupyter.cpp.o
FAILED: CMakeFiles/codon_jupyter.dir/jupyter.cpp.o
/usr/bin/clang++ -DGUID_LIBUUID -DXEUS_STATIC_LIB -DXEUS_ZMQ_STATIC_LIB -DZMQ_STATIC -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Dcodon_jupyter_EXPORTS -I/home/john/Documents/codon/jupyter/. -I/home/john/Documents/codon/jupyter/install/include -I/home/john/Documents/llvm-project/install/include -I/home/john/Documents/codon/jupyter/build/_deps/xeus-src/include -I/home/john/Documents/codon/jupyter/build/_deps/json-src/include -I/home/john/Documents/codon/jupyter/build/_deps/xtl-src/include -I/home/john/Documents/codon/jupyter/build/_deps/xeus-zmq-src/include -I/home/john/Documents/codon/jupyter/build/_deps/cppzmq-src -I/home/john/Documents/codon/jupyter/build/_deps/libzmq-src/include -I/home/john/Documents/codon/jupyter/build/_deps/libzmq-build -pedantic -fvisibility-inlines-hidden -Wno-return-type-c-linkage -Wno-gnu-zero-variadic-macro-arguments -Wno-deprecated-declarations -O3 -std=gnu++17 -fPIC -Wunused-parameter -Wextra -Wreorder -MD -MT CMakeFiles/codon_jupyter.dir/jupyter.cpp.o -MF CMakeFiles/codon_jupyter.dir/jupyter.cpp.o.d -o CMakeFiles/codon_jupyter.dir/jupyter.cpp.o -c /home/john/Documents/codon/jupyter/jupyter.cpp
In file included from /home/john/Documents/codon/jupyter/jupyter.cpp:3:
/home/john/Documents/codon/jupyter/./jupyter.h:4:10: fatal error: 'codon/compiler/jit.h' file not found
#include <codon/compiler/jit.h>
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
[7/144] Building CXX object _deps/xeus-build/CMakeFiles/xeus-static.dir/src/xcomm.cpp.o
ninja: build stopped: subcommand failed.
-- Install configuration: "Release"
CMake Error at jupyter/build/cmake_install.cmake:57 (file):
file INSTALL cannot find
"/home/john/Documents/codon/jupyter/build/libcodon_jupyter.so": No such
file or directory.

Can you please provide more details: how are you compiling Codon, did you install it with cmake --install etc?

Duplicate of #152.


dart2js bug in classMirror.metadata: metadata should not be inherited

Dart2js and the Dartvm seem inconsistent in the implementation of ClassMirror.metadata. Looking at the api, it seems that the vm behavior matches what's documented.
Here is a test case that can be used to repro this:
  import 'dart:mirrors';
  const meta = "annotation";
  @meta
  class A {}
  class B extends A {}
  main() {
    print('A: ${reflectClass(A).metadata.length}');
    print('B: ${reflectClass(B).metadata.length}');
  }
The dartvm will print:
  A: 1
  B: 0
dart2js will print:
  A: 1
  B: 1

Mirrors is no longer supported in Dart2JS.


Reduce execution time for the "when exporting JDL to entity json for an existing entity it exports it with same changeLogDate" test

It takes one second to run.

@deepu105 Why does it take this long?

Oh. I've found out why...  Currently, we have something like<PHONE_NUMBER>1210, and I'd want it to be<PHONE_NUMBER>1210XXX where XXX would be the millis. Seconds are not precise enough, even though generating a JSON file (and the rest for an entity) may take more than one second now, it would be a good bet to say that it will take less in the future.

@MathieuAA that's because I never thought we would generate all the entities automatically :-)
I also copied this on Rails migrations, which I believe have this format by default. So we are being more precise than Rails!!
I'm not sure of what will happen if you have a mix of second/millisecond precision files -> we don't really order them by name, in the end the order used is the one in the master.xml file. So I think you won't have issues, but this needs to be tested.

I have manually added a wait time of 1 second to check the case of
generating the same changelog again. If this bothers you remove the test
case newly added. I personally dont mind an extra second spend for better
coverage. Note that its only for the tests.
Thanks & regards,
Deepu
On 4 Oct 2016 02:37, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>wrote:

@deepu105 https://github.com/deepu105 Why does it take this long?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/68#issuecomment-251227469,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF3Hn6T2NsIGog7XymJziKoiBvlkqks5qwW6jgaJpZM4KNCsx
.

It shouldn't matter much even if we add the millis I guess.
Thanks & regards,
Deepu
On 4 Oct 2016 03:49, "Julien Dubois"<EMAIL_ADDRESS>wrote:

@MathieuAA https://github.com/MathieuAA that's because I never thought
we would generate all the entities automatically :-)
I also copied this on Rails migrations, which I believe have this format
by default. So we are being more precise than Rails!!
I'm not sure of what will happen if you have a mix of second/millisecond
precision files -> we don't really order them by name, in the end the order
used is the one in the master.xml file. So I think you won't have issues,
but this needs to be tested.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/68#issuecomment-251244037,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF_TFaXIzUk-fcWgZGlLD1nPyfWiRks5qwX9hgaJpZM4KNCsx
.

Only issue I see is backward compatibility. May be lets do it for the next major version if needed as its not a big issue currently

@jdubois Shame on them!
@jdubois, @deepu105: there may be an easy, and retro-compatible way to do that. I'll try to get a PR by tonight if I get back home early tonight (work, always work...).

OK but still I don't think there is an issue. The files are listed in the
master.xml.
Work, work, work, work, work...
Le 4 oct. 2016 8:49 AM, "Mathieu ABOU-AICHI"<EMAIL_ADDRESS>a
écrit :

@jdubois https://github.com/jdubois Shame on them!
@jdubois https://github.com/jdubois, @deepu105
https://github.com/deepu105: there may be an easy, and retro-compatible
way to do that. I'll try to get a PR by tonight if I get back home early
tonight (work, always work...).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/jhipster-core/issues/68#issuecomment-251307509,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATVo6rOElBpCAfbbI7TgoC8WnQah9SRks5qwfcNgaJpZM4KNCsx
.


LDAP Support

In GitLab by @luotian-github on Sep 28, 2017, 10:24
change to green

In GitLab by @yhua123 on Nov 8, 2019, 07:38
#619 #627

In GitLab by @yhua123 on Nov 8, 2019, 07:38
need api check Auth mode

In GitLab by @yhua123 on Nov 8, 2019, 07:38
LGTM

In GitLab by @sokril on Nov 8, 2019, 08:12
closed

In GitLab by @sokril on Nov 8, 2019, 08:12
assigned to @wknet123


Test validating solid border on class before class is put on img tag

Challenge http://www.freecodecamp.org/challenges/waypoint-add-borders-around-your-elements has an issue. Please describe how to reproduce it, and include links to screen shots if possible.
I think the test for this is wrong, but I didn't spend much time than looking at it except to note it was doing a global & ignore case search. Which should probably be swapped to checking the img's style I'd assume.

Duplicate of #1090


s3api: Fix signature v4 with reverse proxy at sub-path

What problem are we solving?
This PR closes #6086
How are we solving the problem?
Server checks if X-Forwarded-Prefix header was passed, in this case add additional URL signature check.
Additionally, X-Forwarded-Host is handled in same way as in f747767aa10da345c19a61a63687d52876efe6a5.
How is the PR tested?
Tried to use s3cmd, aws-cli and rclone, everything worked fine.
Checks

[x] I will add related wiki document changes and link to this PR after merging.

For s3cmd it's required to set X-Forwarded-Host header because it can't properly subdivide host and I can't detect if it was used. Luckily, aws-cli and rclone works as intended.


PEP 8

Needed an excuse to test out protected branch settings in this repo so I just ran cumulusci/core through autopep8.

Pushed another commit to test out automatic dismissal of stale reviews.


Add Colégio Maanaim

@Descafeiinado I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host aluno.colegiomaanaim.net not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


Use publishing-api instead of content-register

Currently this app is the "source of truth" for the organisations links hash. It saves which organisations it belongs to in it's own database (also for people and working_groups). This means that if the content-tagger modifies the organisations links hash, this application would not be updated and overwrite the new links on save.
To prevent that we will be migrating this app to the new tagging architecture, so that it doesn't use it's own database for the links hash.
Full story: https://trello.com/c/BQDQ824W
This PR is the first step in changing this. It changes the source of the select boxes to be publishing-api instead of content-register. publishing-api contains the same information as content-register, but is directly populated. The data in content-register is updated via the message queue, and may therefore not be up to date.
Previous: https://github.com/alphagov/policy-publisher/pull/115

:+1: to intent.

LGTM.

me too.


add_vertices deprecated in favour of bounds

add_vertices is deprecated in favour of bounds keyword in cx.cordex_domain. For regular grids, we use cf-xarray to add latitude and longitude bounds.

Codecov Report

Merging #101 (a5a44b7) into master (d444a09) will decrease coverage by 2.85%.
The diff coverage is 66.66%.

:exclamation: Current head a5a44b7 differs from pull request most recent head c629834. Consider uploading reports for the commit c629834 to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files

@@            Coverage Diff             @@
##           master     #101      +/-   ##
==========================================
- Coverage   77.14%   74.29%   -2.85%
==========================================
  Files          22       22
  Lines        1098     1097       -1
==========================================
- Hits          847      815      -32
- Misses        251      282      +31

Flag
Coverage Δ

unittests
74.29% <66.66%> (-2.85%)
:arrow_down:

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

Impacted Files
Coverage Δ

cordex/domain.py
75.00% <66.66%> (+1.99%)
:arrow_up:

cordex/preprocessing/preprocessing.py
63.03% <0.00%> (-17.07%)
:arrow_down:

cordex/cmor/cmor.py
64.68% <0.00%> (+0.23%)
:arrow_up:

cordex/cmor/utils.py
92.07% <0.00%> (+0.90%)
:arrow_up:


chore: Update stash to newest version

Update stash to the newest versionf

I think a new PR would make sense.


CLDC-1895 pluralise various copy when joint purchase

https://digital.dclg.gov.uk/jira/browse/CLDC-1895

@arfacamble Shall we discuss this one? I think we can improve how it reads.


Postman version 1.3 Parcelers disappear

I upgraded to version 1.3 and the parcelers disappear. When I downgrade to 1.2 they reappear. Makes me believe the processor isn't running in 1.3, or something changed that is causing the processor to not run on my particular build.

Indeed. Version 1.3 split postman out into two artifacts, one of which is the processor. Check the readme for how to uptake the new artifact scheme.


LMDB optimized with verification of 100GB dataset

This PR reduces memory utilization of LMDB RDD. It has been verified with 100GB+ datasets.

+1


add: repo_host to proxy settings

Added 'repo_host' to use proxy settings only for certain Debian repos
Removed FTP Test - Travis-CI does not support for this because of security reasons
Changed other tests with hkp to hkps due to test fails -> Travis-CI Security
Fixed bundle error  (maybe somebody has a better solution?)

Hey @zlanyi , thank you for the work you've put into this PR! I'm keen to get it merged as I'm working on adding Debian 9 support, but I've an outstanding question about one of the changes that you can help me with - The addition of 'rvm @global do gem install bundler' to the .travis file.
We don't like to make manual changes to the .travis file due to it now being managed by the pdk - Can you explain the need for it? There was a bundle issue that raised it's head in a recent release which has been fixed since, was this possibly the issue your comment refers to? If so the removal of this line would be necessary before we merge.

Thanks @zlanyi for the changes. We have worked on improving the tests, so they are less flakey. Could you have a look at the conflicts, and see if you can answer @HelenCampbell question.

Hi @HelenCampbell,
i don't remember anymore if there was a bug with rvm and ruby or not, this PR is too old :)
I'll rebase my branch and i try to see exactly the problem.

@zlanyi Try taking the .travis.yml change out, and re-pushing. It should run green.

@tphoney Which changes should I take over?
I rebased the changes from upstream branch and still red: I tested without my rvm change on my forked project on 'zlanyi-proxy-repo_host_test' branch. Any idea?

it's green again, yeah :)

any news here?

There seems to be 2 significant changes here, changing the default keyserver and adding the parameter. Ideally these would be separate.  what do you think @HelenCampbell @zlanyi  ?

good idea.
2018-06-26 13:19 GMT+02:00 TP Honey<EMAIL_ADDRESS>
There seems to be 2 significant changes here, changing the default
keyserver and adding the parameter. Ideally these would be separate. what
do you think @HelenCampbell https://github.com/HelenCampbell @zlanyi
https://github.com/zlanyi ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/puppetlabs/puppetlabs-apt/pull/756#issuecomment-400271945,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APPXGVDqqTeD5pL1sLWkXx6T2M5BK2kWks5uAhjIgaJpZM4UC_1d
.

@zlanyi Have you made any further work in regard to finishing this pr?

@zlanyi Apologies but due the amount of time that this pr has been left to lie fallow and your lack of response when pinged I am now closing it. If at a later time you are able to return to it we will be more than happy to continue to review it.
Best Wishes
Modules Team

Hello,
sorry, unfortunately I did not have time to adjust everything.
I will open a new PullReqest if have a little bit time again.
Cheers,
Zoltan


Refactor test_ops to get ready for test_ops in all dtypes

test_ops focuses on float32, with some exceptions.
The idea behind this refactor is to create a base TestOps and extend it based on dtypes to TestFloatOps, TestIntOps, etc, where we reuse the same torch and tiyngrad fxns but just change the data (we might also need to change atol and rtol depending on the dtype).
This diff doesn't change anything about how TestOps works just moves things around:
helper_test_op to the TestOps class: because it can get self.DTYPE from it and generate the correct data https://github.com/tinygrad/tinygrad/commit/3ad02f545c6b75203b72d14e1a65b085e360be71 https://github.com/tinygrad/tinygrad/commit/82c55e6eb63caf693c1a88614a5dea25f76afd34
TestFloatOps runs everything that was already in TestOps https://github.com/tinygrad/tinygrad/commit/5bcf9ae14a2bb86452202a73c7c2575da290a7ea (This needs to change when we add more dtypes, some fns like torch.cumsum only work on float32)
Handling test_div_int https://github.com/tinygrad/tinygrad/commit/7dc938c4992b4d9bee0c2fbdef9abf1449f2a2c2 (the only modified test)

Two issues with the dtypes PR.

model benchmark failed on NVIDIA, I just disabled it for now. https://github.com/tinygrad/tinygrad/actions/runs/7079546079/job/19266304610
while HALF=1 HIP=1 WINO=1 STEPS=10 python3 examples/hlb_cifar10.py compiles now, it produces NaNs

Why do you need self for helper_test_ops?

That could work too,
I'm exploring this first because there are some tests like all convs that are only supported in fp32 for torch's CPU backend, so my idea was to have a base TestOps for the default ALU ops tests and then a TestsFloatOps for everything torch CPU can't run for non-fp32


Unable to download : Error http 429

I just want to test youtube-dl, but it's not possible.
youtube-dl -v 'https://www.youtube.com/watch?t=4&v=BaW_jenozKc' [debug] System config: [] [debug] User config: [] [debug] Command-line args: [u'-v', u'https://www.youtube.com/watch?t=4&v=BaW_jenozKc'] [debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8 [debug] youtube-dl version 2016.02.13 [debug] Python version 2.7.3 - Linux-3.14.32-xxxx-grs-ipv6-64-x86_64-with-Debian-7 [debug] exe versions: avconv 0.8.17-6, avprobe 0.8.17-6, ffmpeg 0.8.17-6, ffprobe 0.8.17-6 [debug] Proxy map: {} [youtube] BaW_jenozKc: Downloading webpage ERROR: Unable to download webpage: HTTP Error 429: Too Many Requests (caused by HTTPError()); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.   File "/usr/local/lib/python2.7/dist-packages/youtube_dl/extractor/common.py", line 354, in _request_webpage     return self._downloader.urlopen(url_or_request)   File "/usr/local/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py", line 1905, in urlopen     return self._opener.open(req, timeout=self._socket_timeout)   File "/usr/lib/python2.7/urllib2.py", line 407, in open     response = meth(req, response)   File "/usr/lib/python2.7/urllib2.py", line 520, in http_response     'http', request, response, code, msg, hdrs)   File "/usr/lib/python2.7/urllib2.py", line 445, in error     return self._call_chain(*args)   File "/usr/lib/python2.7/urllib2.py", line 379, in _call_chain     result = func(*args)   File "/usr/lib/python2.7/urllib2.py", line 528, in http_error_default     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)

Duplicate of #5138. See discussion there and this FAQ entry for more information.


Misc fixes to get travis CI builds succeeding

Self explanatory

busted, fixing

winning, @vkhatri ready for review/merge :)

@CpuID Closing it, rubocop checks were fixed by #13
Thanks for the PR though!


qtwayland: workaround upstream bug: install missing headers manually

Have tried to keep this as less invasive as possible
To be honest: Have tested this with thud only - reading QTBUG-71340 tells me the bug is still there

Merged in thud:
201fcf27..fb4ef4dd  thud -> thud


Web UI should not show an error for the attempt to load catalogs from the 'giantswarm' namespace

Towards https://github.com/giantswarm/roadmap/issues/551
Currently we show this error when the user has no permission to access catalogs in the giantswarm namespace. (Seen on the page /organizations/marian/clusters/:cluster/apps).

In the test scenario there is a cluster with only one app installed, the NGINX ingress controller. This app is from the giantswarm catalog which is in the default namespace.
I wonder whether we can avoid making the request, and if not, avoid showing the error in this situation.

Thank you @kuosandys !


Add media queries for smaller screens and adjust HTML

Modifies the CSS so that the game still functions on smaller screens (though not too small). Unfortunately the canvas is a fixed width so the game can't played below a certain screen size. I also had to rearrange the HTML so the menu and prompts were in the same column as the canvas.

Per Jordan, merging in this styling change.


Error running a mainnet fork in docker

📎 Log Output
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ParseError(Error("unknown variant `Version20`, expected one of `Version0`, `Version1`, `Version2`, `Version3`, `Version4`, `Version5`, `Version6`, `Version7`, `Version8`, `Version9`, `Version10`, `Version11`, `Version12`, `Version13`, `Version14`, `Version15`, `Version16`, `Version17`, `Version18`, `Version19`", line: 1, column: 643))', src/fork.rs:359:14

Here is the dockerfile

It was working before

FROM debian:latest

WORKDIR /app

USER root

RUN apt update
RUN apt install libssl-dev -y
RUN apt install ca-certificates -y

COPY . .

RUN tar xz -f /app/era_test_node.tar.gz -C /usr/local/bin

EXPOSE 8011

CMD era_test_node fork mainnet

same here

I am running this locally and also have problems with running era_test_node fork mainnet while regular run works.
Same error happens:
era_test_node fork mainnet
thread 'main' panicked at src/fork.rs:360:14:
called `Result::unwrap()` on an `Err` value: ParseError(Error("unknown variant `Version22`, expected one of `Version0`, `Version1`, `Version2`, `Version3`, `Version4`, `Version5`, `Version6`, `Version7`, `Version8`, `Version9`, `Version10`, `Version11`, `Version12`, `Version13`, `Version14`, `Version15`, `Version16`, `Version17`, `Version18`, `Version19`, `Version20`, `Version21`", line: 1, column: 642))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@stevyhacker yes right now due to an upgrade upstream era-test-node fork is broken. You can still fork but starting at a past block number prior to the upgrade. For example, era_test_node fork --fork-at 20760265 mainnet.
We are fixing it and should be addressed soon. Follow #266.


Create mkcert.json

Add mkcert from https://github.com/FiloSottile/mkcert
It's already on chocolatey but I'd like to get it through scoop
See #1154

Nice 👍
By adding #/mkcert.exe to end of the URL and autoupdate URL the file will get renamed automatically.
The pre_install script can be removed. :smile:

Good to know! I'm updating the descriptor

@r15ch13 Richard do you think it is acceptable?


Quickfix for overloading server with FSharpSignatureData requests

👋 I noticed there's been an issue with larger files getting bombarded with FSharpSignatureData.  Since this was firing a lot of promises at the same time, this was causing VSCode to slow down to a crawl.
While it would be better to only send up ranges you're currently viewing, this is a quick fix to try to stop the bleeding.

This is a good quick fix. Longer term I'd like to make the LSP endpoint for signature data take a range to compute the lenses for (as you know, I'm just repeating it here for the record).


add energy storage technologies #1572

Summary of the discussion
To introduce the energy storage technology hierarchy, in https://github.com/OpenEnergyPlatform/ontology/issues/1572#issuecomment-1767977144 it was decided to extend the energy storage objects in parallel to the energy storage functio hierarchy and add the energy storage technology hierarchy on top.
Type of change (CHANGELOG.md)
Added

electrical energy storage object, thermal energy storage object, kinetic energy storage object, chemical energy storage object

All classes are defined with the same structure, e.g. A thermal energy storage object is an energy storage object that has the function to store thermal energy.
I added a comment to each class to underline the specific funtion, e.g.: The thermal energy storage object is being charged with thermal energy and releases thermal energy during the decharging process. The stored energy within the object may appear in a different form of energy, though.

energy storage technology: An energy storage technology is an energy technology that describes how to combine energy storage objects and energy carriers in charging and decharging processes for the purpose of temporarily storing energy.

and subclasses electrical energy storage technology, thermal energy storage technology, kinetic energy storage technology, chemical energy storage technology

Workflow checklist
Automation
Closes #
PR-Assignee

[ ] 🐙 Follow the Pull Request Workflow
[ ] 📝 Update the CHANGELOG.md
[ ] 📙 Add #'s to term tracker item

Reviewer

[ ] 🐙 Follow the Reviewer Guide
[ ] 🐙 Provided feedback and show sufficient appreciation for the work done

Is there an example for an energy storage object with the potential energy storage function, i.e. have potential energy as input/output? An elevator? I left that out for once.

Examples for object with an potential energy storage function are hydraulic accumulators used to store energy in hydraulic systems.
I would add potential energy storage functions for two reasons:
a) have consistent hierarchies
b) to check whether classes are classified correctly.
We might however discuss whether potential energy storage object might be excluded from the fact sheets for now. We once talked about a a special annotation property for that, see #1529.

I still doubt that the potential energy storage function makes sense the way we defined it. But if you want to keep it, I'll introduce the respective hierarcy anyway.
Regarding the consitency of the hierarcy: we don't have a radiative energy storage function either (probably because it doesn't make sense...).

I still doubt that the potential energy storage function makes sense the way we defined it. But if you want to keep it, I'll introduce the respective hierarcy anyway.

What exactly do you think is wrong with the definition of potential energy storage function? It is defined in the same way as other energy storage functions. Are your doubts really about the definition of potential energy storage function or rather the definition of potential energy itself?
If we decide to leave out potential energy storage object then we should delete potential energy storage function, because else we would have a useless function in the OEO.

Regarding the consitency of the hierarcy: we don't have a radiative energy storage function either (probably because it doesn't make sense...).

Radiative energy is different than the other energies as it can only be stored in photons (or waves) and not in artificial objects. Photons cannot stay at a place (c.f. speed of light) like other energy storage objects.

What exactly do you think is wrong with the definition of potential energy storage function? It is defined in the same way as other energy storage functions. Are your doubts really about the definition of potential energy storage function or rather the definition of potential energy itself?

An electrical energy storage has input and output electrical energy, but while the energy is stored, it has another form. Same with kinetic or thermal energy. While the energy is stored it can have the form of potential energy, but once released, the potential energy is converted again.
I don't see, how potential energy can be an input or output.
But what about discussing this in a developer meeting, and leave it as is for now?

From bilateral discussion with @l-emele:
We add both potential energy storage function, ... object and ... technology. We further discuss, if we see use cases. And we add an editor note, saying that we don't have a use case but for completness reasons introduce it.


PACKAGES: Dependency update bot

Installed : https://renovate.whitesourcesoftware.com/
Its pares the dart and golang code and updates dependencies as a PR.
Lets see if its helpful and picks up things in CI

done and running on github


4.0 does not reconnect to logstash

After we upgraded from 3.x to 4.0 we noticed that logstash started logging significantly less than it used to. After some preliminary investigation it looks like logstash appender now has troubles reconnecting to the logstash.
I cannot reproduce it with a local test (when I kill the server socket, it causes appender to reconnect in 30 sec) but in AWS environment where ELBs are used to load-balance connections to multiple logstash servers - it happens all the time.
Important observation is that there are sockets stuck in CLOSE_WAIT state on the client machine - that is socket that OS believes is already closed by server but client application (logstash appender) has not called close() on that socket yet.
$ sudo netstat -npt | grep 4560
tcp6       0      0 <IP_ADDRESS>:38380       <IP_ADDRESS>:4560       ESTABLISHED 1056/java
tcp6       1      0 <IP_ADDRESS>:33733       <IP_ADDRESS>:4560       CLOSE_WAIT  1086/java
tcp6       0      0 <IP_ADDRESS>:33735       <IP_ADDRESS>:4560       ESTABLISHED 1019/java
tcp6       1      0 <IP_ADDRESS>:55303       <IP_ADDRESS>:4560       CLOSE_WAIT  1027/java
tcp6       1      0 <IP_ADDRESS>:38382       <IP_ADDRESS>:4560       CLOSE_WAIT  1039/java
tcp6       1      0 <IP_ADDRESS>:55306       <IP_ADDRESS>:4560       CLOSE_WAIT  1124/java
tcp6       1      0 <IP_ADDRESS>:38386       <IP_ADDRESS>:4560       CLOSE_WAIT  1099/java

We have 7 separate Java processes on that box and as you can see, 2 of them managed to connect (ESTABLISHED) while other 5 - failed (CLOSE_WAIT).
Problem is that these will never try to reconnect because (my assumption), the appender code did not detect the problem.

Okay, I just confirmed I can reproduce it easily by just restarting logstash server (which is behind ELB but I am not sure it plays any role in the experiment). So all the ESTABLISHED sockets turn to CLOSE_WAIT and hang in that state forever - it never reconnects.
Just looking at AbstractLogstashTcpSocketAppender.java openSocket() I think there are a couple of a logic errors in there.

It catches IOException only but it should close already opened socket in case of any exception.
one of the condition for the while loop is socket being null. But what happens if socket is assigned but then connect() fails with something like NPE? or InvalidArgumentException? it will abort the method but this.socket is already assigned so even if this method will ever be invoked again - it will just return immediatelly because this.socket != null

I would rather made socket a local variable and only assign this.socket before returning successfully. (Still need to make sure that if we are leaving method in case of any exception, that locally created socket is released.
I am not sure yet if it is what causes the issue - just observations from the code...

Than what are the IOExceptions that onEvent() catches but does not reconnect? I cannot think of anything of any conditions where client gets IOException and it does not mean at the same time that connection went wrong and must be killed...

In addition to two logic errors above - what if socket is constructed successfully but then outputStream construction fails or even more realistically, encoder.init(outputStream) throws something?
The appender will be left in half-initialised state when some of the code believes it is all good (socket != null etc) but at the same time any attempt to use it will throw something.

Hi @dimas,
I'll take a look at this later tonight.  I'm running pretty much the exact same setup.
I agree that all exceptions should be caught and handled (not just IOExceptions).  Can you confirm that this is what is actually happening in your case?  What RuntimeException is being thrown? It would give me much more confidence that it will fix your problem if you can confirm it.
Note that the socket reference is set back to null in the closeSocket method.  So, if an IOException was thrown, the loop would continue rather than exiting.  However, obviously this is only true for IOExceptions.
I didn't handle RuntimeExceptions because those are generally from programmer error, rather than environmental problems, and likely won't be resolved by just re-iterating.  However, I'll still make the change so that the logic is extra-safe.
Phil

To be honest, I do not know how to get that internal logging from Logback (the stuff that is sent via addWarn for example). I tried adding debug="true" to the logback.xml configuration XML but it did not help. Because of that I do not know what the actual exception is.

Hmm,  can you try adding a OnConsoleStatusListener and looking at the stdout of your process?
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />

Does not display any exceptions at all.
Right now I killed the last logstash instance behind ELB and the way it is now is that ELB accepts the connection but immediatelly closes it.
$ nc -v mylogstashserver 4560
Connection to mylogstashserver 4560 port [tcp/*] succeeded!
$

so nc instantly returns to command line (while normally it should hang waiting for the input). And in that state my cosole says
18:26:08,817 |-INFO in net.logstash.logback.appender.LogstashTcpSocketAppender[logstash] - Log destination mylogstashserver:4560: connection established.

but it never says it lost the connection.
I am not sure at the moment how to reproduce this behaviour with some (other than ELB itself) tools but it should be possible with nc as well. So I will experiment with it more tomorrow but for now it looks like logback appender does not detect connection closure when it happens immediately.

(I mean it should be possible to simulate server-side that accepts and drops connections with just NC or something similar)

To attempt to reproduce this, I have a load balancer with no handlers behind it.  I believe the load balancer has the same behavior as yours, in that it initially accepts the connection, but then immediately closes it.  I have verified this through wireshare.  When connecting, I see:
-> SYN
<- SYN, ACK
-> ACK
<- FIN, ACK
-> ACK

Then, when attempting to write the first event to the socket outputstream, I see the following:
-> PSH, ACK
<- RST

To my surprise, no exception is thrown by java's socket output stream here.  So, the appender thinks the event was written successfully.  I'm guessing the output stream write returns before the RST reply is received.
However, when writing the NEXT event, the following exception is thrown:
12:18:54,798 |-WARN in net.logstash.logback.appender.LogstashTcpSocketAppender[centralized] - Log destination xxx:yyyy: unable to send event: Software caused connection abort: socket write error java.net.SocketException: Software caused connection abort: socket write error
        at java.net.SocketException: Software caused connection abort: socket write error
        at      at java.net.SocketOutputStream.socketWrite0(Native Method)
        at      at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
        at      at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
        at      at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at      at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at      at net.logstash.logback.appender.AbstractLogstashTcpSocketAppender$TcpSendingEventHandler.onEvent(AbstractLogstashTcpSocketAppender.java:200)
        at      at net.logstash.logback.appender.AbstractLogstashTcpSocketAppender$TcpSendingEventHandler.onEvent(AbstractLogstashTcpSocketAppender.java:163)
        at      at net.logstash.logback.encoder.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
        at      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at      at java.lang.Thread.run(Thread.java:745)

Since this is a SocketException, the connection is reestablished (and reclosed by the LB), and the cycle repeats itself.
Note that I have immediateFlush turned off on my encoder, so the outputstream is only flushed by the appender at the end of the batch.
I'm not sure why you do not see this same SocketException when attempting to write the event after the connection has been closed by the server.  I'm not sure how much I'm going to be able to debug this further, but I'll still keep investigating.

Maybe I rushed a bit with my report. We saw the issue in live system so as soon as I saw the same symptoms in my test environment, I filled in details. But the test environment may have zero logging activities so after ELB killed the connections (for being idle for more than 1 minute), your client never restored that connection because there is no events to log and connection is only restored when these events arrive.
So experiment was not ideal to say the least. However it started because, as I said, we had the issue with live system. So now I need to figure out how to reproduce it.
However, you can see yourself that there is an issue with ELB and applications that only occasionally log something. The default AWS ELB timeout is 1 minute which you can only extend to 10 minutes. After that time, Amazon kills the connection but client won't detect it until it tries to write something into that socket. And  as you saw yourself, the first write will be lost anyway. Which means if application logs single message every 20 seconds - it is doomed to not log anything at all.
We know about that case and even wanted to add a patch that makes appender to write a single newline character into the socket every 30 seconds (configurable). However after the switch to LMAX disruptor - I have no idea how to handle it now. My idea for the patch only valid for blocking queue approach.
Again, while the problem above is very real, it is not what happened to our live system. Logging traffic there was quite substantional and yet, a socket was stuck in close_wait state forever.

Gotcha.  I'll treat these as two separate issues then.

Infrequent logging - Add keep alive functionality.  This should be simple to do regardless of queuing mechanism.  With the current implementation, the TcpSendingEventHandler can be modified to start up a keep alive thread in the onStartup method.  This thread would send newlines every X seconds to the socket if no events have been processed in the past X seconds.

Frequent logging, but sockets are stuck in CLOSE_WAIT state.  I haven't been able to reproduce this.  I'll keep digging, but I'll probably need your help to further diagnose this issue.

Sure, these are two separate issues.
#1 - I doubt it will be that easy as you think. I am not sure if OutputStreams are thread safe and I doubt it. And both, disruptor onEvent thread as well as your connection keepalive thread will have to deal with socket opening/closing and writing to it... Can turn into a nightmare.
With the blocking queue it was much easier - just do time-restricted take() and if it returned because of the timeout - send a newline. Everything is within the same thread. Anyways, if you know how to fix it - it would be great.
#2 - I reproduced it and took packet dumps. Apparently it is an Amazon issue so I raised case with them. I doubt they can fix it though.
If you are curious and want to see the same issue - there is a small window between the moment you killed your server process and the moment ELB will start dropping incoming connections. If during that window you connect to it - ELB will be happily consuming all your data even there is no way to forward it to the backend server which is down. (So in tcpdump you will see it ACKs all the chunks of data you are sending)
According to Amazon support, they are buffering all the data and will send it to the backend when new connection is established. Unfortunately there will be no new connection as client does not know something is wrong with the existing one.

For #1, I was thinking the keep alive thread would post an event onto the RingBuffer, and therefore the event handler would send the keep alive.  There are some details to work out, but it should work.
For #2, I don't think there's anything elegant that the tcp appender can do about this case.  Periodic reconnects? Do you have any other ideas?

Well, you will need to somehow understand that it is a special kind of event that does not need to be pushed through encoder. But if you can do it, then yes - this approach is probably right.
I assume I do not need to create another issue for that, right?

No, I cannot think of anything. It is definitely not logstash-logback-encoder's fault but Amazon's. I will keep talking to them re that case and will let you know if there are any updates.

Having said that, I think that there is a still room for improvement in TCP appender connection handling logic :)
Namely the issues I outlined in the very beginning. Even though these did not play any role in this particular problem, it still feels like it makes sense to close them just to be safe. I will summarise them here:
A) this.socket + this.outputStream are assigned before their initialisation has finished successfully so they can be used later in half-baked state.
B) openSocket() only closes opened socket in case of IOException while it should close it when leaving method because of any reason except for success.
C) I am not sure why you treating IOException differently from SockerException in onEvent - what kind of IOException may occur that does not require reconnection?
So if you agree with these, I would suggest keeping this issue open. If not - feel free to close it.
Personally I would probably do something along the lines of good old C-like stuff:
Socket socket = null;
OutputStream outputStream = null;
try {
  // create socket, create stream, init encoder
  succsss = true;
} finally {
  if (!success) {
    // close everything
  }

  this.socket = socket;
  this.outputStream = outputStream;
}

Ya, I'll make all the improvements you suggest.
For #C, IOExceptions can be thrown at layers higher than the socket.  For example, if your encoder had an OutputStream that threw an IOException before even writing to the socket.
Reconnecting the socket will not help in this case.  When there is a problem with the socket, a SocketException will be thrown.
Having said that, I'll change it to reconnect on any IOException, just to be safe.  Worst case, it reattempt's connection when it's not necessary.  But that shouldn't cause too much harm.

Well, the problem is that if SocketOutputStream throws an exception - you do not really know if it happened before touching the socket or during it. So you do now know if it can recover from it.
Anyway, thanks a lot for your work.

All changes suggested here have been committed to master for version 4.2.
I've done some testing here, but if you get a chance, I'd appreciate if you could let me know if they work for you.

This has been causing us issues too and am glad to have found this issue. We'd be happy to try this out - is there a snapshots repo or version available that we can try?
When are you likely to push 4.2?

@philsttr - I manually verified that it sends keepalive newline and it seem to make ELB happy so it does not kill the connection. I cannot really verify other changes properly.
We will push it to live as soon as you release 4.2
Re the original issue, there are no updates from Amazon support except that they managed to reproduce the problem and relayed it to their development team.

4.2 has been released.
Thanks for verifying the changes.  And good to know that Amazon is looking into the problem that you discovered.


USHIFT-816: rebase.py - personal tokens

Allow for using Personal Access Token (PAT) to test against a developer's fork (TOKEN env var)
Add information about rebase.sh execution time
Allow to override base_branch so the PR can be created against main when script is executed from other branch, not yet existing on the remote (BASE_BRANCH env var)
Don't crash on "review request" failures
Use more precise prefix to pick branches for deletion (rebase-4)
Delete temporary remote at the end of script, so next time it's executed on dev machine git doesn't have old remote refs.

Usage:
TOKEN=ghp_...


DOCS-8072-4.3-tuning-backend-server-kt

tuning-backend-server.adoc

Closing as content was applied and merged in https://github.com/mulesoft/docs-mule-runtime/pull/1475


@rollup/plugin-multi-entry for lib mode and multiple formats

Is your feature request related to a problem? Please describe.
@rollup/plugin-multi-entry could be useful for lib mode. It allows the definition of input as an array of multiple files (with glob support) and automatically mixes all the named exports in a single output.
It is currently working when using a single lib format but fails when there are several formats. Here is a repro:
https://github.com/matias-capeletto/vite-rollup-plugin-multi-entry
It is failing because this plugin assumes there will be a single output file, there is an option entryFileName to modify it (defaults to multi-entry.js). So every lib output format ends up with the same name.
Describe the solution you'd like
In case this plugin is incompatible, maybe it could be used internally.
Describe alternatives you've considered
I do not know if this feature justifies more complexity in Vite. Personally, I would prefer to define a single entry file and if globs are needed, use Glob import in it. I am opening the issue mainly for completeness, so all official rollup plugins are checked. With the introduction of glob imports, a big part of what makes this plugin useful could be considered covered.
Additional context
vite version: 2.0.0-beta.24
Operating System: Windows 10 Home, 10.0.18363 N/A Build 18363
Node version: v15.5.0
Package manager and version: yarn v1.22.10

Yeah, I don't know about this one. I personally perfer having an explicit facade module to import necessary sub modules.

Yeah, I don't know about this one. I personally perfer having an explicit facade module to import necessary sub modules.

I agree. I added a new category n/a (not applicable) for this one to https://vite-rollup-plugins.patak.dev.
Note: @rollup/plugin-run is also listed as n/a now

I agree. I added a new category n/a (not applicable) for this one to https://vite-rollup-plugins.patak.dev.
Note: @rollup/plugin-run is also listed as n/a now


Code import from molecule

It looks like this was stalled—currently the version of this module on pypi has no functionality. Even with failing tests, is it possible to get this merged so the driver can exist?

@geerlingguy Thanks for reminding me about it. It makes sense.


Get TDC1 lenses

For Run 2 (?) we'll need AGN variability parameters, but for Run 1, we just need the OM10 IDs. Im on the case.

Alright @jbkalmbach I've got almost what we need, and certainly enough for Rung 1. The TDC1 lenses, and their TDC1 i-band light curves, can now be downloaded from the TDC website. Let's focus on Rung 4, since that's the one that matches LSST the best. If you unpack the truth.zip file, you'll see truth4.txt: this contains the OM10 ID of each of the 1000 lenses used in the challenge, and also their variability parameters. For Rung 1, let's just take the first 200 systems from this file. If you can use the variability parameters (they are DRW params, as in the Liao et al paper linked from the TDC website) that would be great; if not, don't worry about it!


ValueError: invalid destination language

when i run print(translator.translate('good morning',dest="zh-CN")),give an error:
ValueError: invalid destination language I want to know how to replace dest if I want to translate english to chinese?

I already know,it's 'zh-cn'

I already know,it's 'zh-cn'

We have updated our package to new version 2.0.3 which accept language as case insensitive.

We have updated our package to new version 2.0.3 which accept language as case insensitive.

We have updated our package to new version 2.0.3 which accept language as case insensitive.

thank you for your reply.


Update Code component Style

Styling update to Code Component

Removed fade variant (breaking change)
Update default style

Inline with Badge and Button

@vladmoroz Im down with your suggestions. Will let @colmtuite sign it off

@peduarte what's the reasoning behind no more background color? I find it looks very similar to a badge or button now. I quite liked how it looked with a slight background.

@benoitgrelard simpler design, works better in articles 👍

@vladmoroz Tracking your comment here https://github.com/modulz/radix/issues/261


CI failing after merge

I think this isn't Scholar specific, but maybe ci.yml needs to be updated.

I re-run the workflows, and now all is passing :))