Http/3 Example - KeyUnavailableError

When I was trying to transfer files between an http/3 client and an http/3 server (using the scirpts provided as the example), I found that the KeyUnavailableError("Decryption key is not available") was raised every once in a while, and when that happened, the data transfer rate would usually drop down significantly (say, by up to about 90%). Could you please explain what this error means and what might be the potential causes? I appreciate it a lot.

I'm intrigued by this, would you have any traces for this? Are you on a network with packet loss?

Thanks for your reply. Yes exactly, I was testing it over an intercontinental network and there could be potential packet loss. May I know what kind of traces you were referring to? Below I just attached the verbose output from both client and server side for your reference, and please let me know if you're interested in other kind of trace.
http3 server output during a file transfer with reduced speed of unknown reason:
2021-03-19 22:06:11,911 DEBUG quic [34ffef4cef0dff44] Network path ('::ffff:[dest ip addr here]', 36359, 0, 0) discovered
2021-03-19 22:06:11,912 DEBUG quic [34ffef4cef0dff44] QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED
2021-03-19 22:06:11,918 DEBUG quic [34ffef4cef0dff44] TLS State.SERVER_EXPECT_CLIENT_HELLO -> State.SERVER_EXPECT_FINISHED
2021-03-19 22:06:12,119 DEBUG quic [34ffef4cef0dff44] Loss detection triggered
2021-03-19 22:06:12,119 DEBUG quic [34ffef4cef0dff44] Discarding epoch Epoch.INITIAL
2021-03-19 22:06:12,120 DEBUG quic [34ffef4cef0dff44] Network path ('::ffff:[dest ip addr here]', 36359, 0, 0) validated by handshake
2021-03-19 22:06:12,131 DEBUG quic [34ffef4cef0dff44] TLS State.SERVER_EXPECT_FINISHED -> State.SERVER_POST_HANDSHAKE
2021-03-19 22:06:12,131 DEBUG quic [34ffef4cef0dff44] Discarding epoch Epoch.HANDSHAKE
2021-03-19 22:06:12,131 INFO quic [34ffef4cef0dff44] ALPN negotiated protocol h3-32
2021-03-19 22:06:12,131 DEBUG quic [34ffef4cef0dff44] Stream 2 created by peer
2021-03-19 22:06:12,131 DEBUG quic [34ffef4cef0dff44] Stream 6 created by peer
2021-03-19 22:06:12,131 DEBUG quic [34ffef4cef0dff44] Stream 10 created by peer
2021-03-19 22:06:12,132 DEBUG quic [34ffef4cef0dff44] Stream 0 created by peer
2021-03-19 22:06:12,132 INFO quic [34ffef4cef0dff44] HTTP request GET /8m_file
2021-03-19 22:06:12,318 DEBUG quic [34ffef4cef0dff44] Decryption key is not available
2021-03-19 22:06:12,319 DEBUG quic [34ffef4cef0dff44] Decryption key is not available
2021-03-19 22:06:17,335 DEBUG quic [34ffef4cef0dff44] Remote max_data raised to 2097152
2021-03-19 22:06:17,335 DEBUG quic [34ffef4cef0dff44] Stream 0 remote max_stream_data raised to 2097152
2021-03-19 22:06:19,760 DEBUG quic [34ffef4cef0dff44] Remote max_data raised to 4194304
2021-03-19 22:06:19,761 DEBUG quic [34ffef4cef0dff44] Stream 0 remote max_stream_data raised to 4194304
2021-03-19 22:06:23,186 DEBUG quic [34ffef4cef0dff44] Remote max_data raised to 8388608
2021-03-19 22:06:23,187 DEBUG quic [34ffef4cef0dff44] Stream 0 remote max_stream_data raised to 8388608
2021-03-19 22:06:28,044 DEBUG quic [34ffef4cef0dff44] Remote max_data raised to 16777216
2021-03-19 22:06:28,044 DEBUG quic [34ffef4cef0dff44] Stream 0 remote max_stream_data raised to 16777216
2021-03-19 22:06:34,873 DEBUG quic [34ffef4cef0dff44] Remote max_data raised to 33554432
2021-03-19 22:06:34,874 DEBUG quic [34ffef4cef0dff44] Stream 0 remote max_stream_data raised to 33554432
2021-03-19 22:06:34,891 INFO quic [34ffef4cef0dff44] Connection close code 0x0, reason
2021-03-19 22:06:34,891 DEBUG quic [34ffef4cef0dff44] QuicConnectionState.CONNECTED -> QuicConnectionState.DRAINING
2021-03-19 22:06:35,571 DEBUG quic [34ffef4cef0dff44] Discarding epoch Epoch.ONE_RTT
2021-03-19 22:06:35,571 DEBUG quic [34ffef4cef0dff44] QuicConnectionState.DRAINING -> QuicConnectionState.TERMINATED

As you may notice here, after receiving the HTTP request there is this error - "Decryption key is not available".
The corresponding http3 client output:
2021-03-19 22:06:11,603 DEBUG asyncio Using selector: EpollSelector
2021-03-19 22:06:11,609 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2021-03-19 22:06:11,810 INFO quic [34ffef4cef0dff44] Retrying with QuicProtocolVersion.DRAFT_32
2021-03-19 22:06:11,812 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2021-03-19 22:06:12,012 DEBUG quic [34ffef4cef0dff44] Loss detection triggered
2021-03-19 22:06:12,018 DEBUG quic [34ffef4cef0dff44] QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED
2021-03-19 22:06:12,019 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_EXPECT_SERVER_HELLO -> State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS
2021-03-19 22:06:12,019 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS -> State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE
2021-03-19 22:06:12,020 DEBUG quic [34ffef4cef0dff44] Discarding epoch Epoch.INITIAL
2021-03-19 22:06:12,020 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE -> State.CLIENT_EXPECT_CERTIFICATE_VERIFY
2021-03-19 22:06:12,029 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_EXPECT_CERTIFICATE_VERIFY -> State.CLIENT_EXPECT_FINISHED
2021-03-19 22:06:12,030 DEBUG quic [34ffef4cef0dff44] TLS State.CLIENT_EXPECT_FINISHED -> State.CLIENT_POST_HANDSHAKE
2021-03-19 22:06:12,030 INFO quic [34ffef4cef0dff44] ALPN negotiated protocol h3-32
2021-03-19 22:06:12,030 INFO client New session ticket received
2021-03-19 22:06:12,030 DEBUG quic [34ffef4cef0dff44] Stream 3 created by peer
2021-03-19 22:06:12,031 DEBUG quic [34ffef4cef0dff44] Stream 7 created by peer
2021-03-19 22:06:12,031 DEBUG quic [34ffef4cef0dff44] Stream 11 created by peer
2021-03-19 22:06:12,212 DEBUG quic [34ffef4cef0dff44] Decryption key is not available
2021-03-19 22:06:12,219 DEBUG quic [34ffef4cef0dff44] Decryption key is not available
2021-03-19 22:06:12,219 DEBUG quic [34ffef4cef0dff44] Sending PING (ACK-of-ACK trigger) in packet 8
2021-03-19 22:06:12,231 DEBUG quic [34ffef4cef0dff44] Discarding epoch Epoch.HANDSHAKE
2021-03-19 22:06:17,235 DEBUG quic [34ffef4cef0dff44] Local max_data raised to 2097152
2021-03-19 22:06:17,235 DEBUG quic [34ffef4cef0dff44] Stream 0 local max_stream_data raised to 2097152
2021-03-19 22:06:19,661 DEBUG quic [34ffef4cef0dff44] Local max_data raised to 4194304
2021-03-19 22:06:19,661 DEBUG quic [34ffef4cef0dff44] Stream 0 local max_stream_data raised to 4194304
2021-03-19 22:06:23,087 DEBUG quic [34ffef4cef0dff44] Local max_data raised to 8388608
2021-03-19 22:06:23,087 DEBUG quic [34ffef4cef0dff44] Stream 0 local max_stream_data raised to 8388608
2021-03-19 22:06:27,944 DEBUG quic [34ffef4cef0dff44] Local max_data raised to 16777216
2021-03-19 22:06:27,945 DEBUG quic [34ffef4cef0dff44] Stream 0 local max_stream_data raised to 16777216
2021-03-19 22:06:34,774 DEBUG quic [34ffef4cef0dff44] Local max_data raised to 33554432
2021-03-19 22:06:34,774 DEBUG quic [34ffef4cef0dff44] Stream 0 local max_stream_data raised to 33554432
2021-03-19 22:06:34,789 INFO client Response received for GET /8m_file : 8388608 bytes in 22.8 s (2.949 Mbps)
2021-03-19 22:06:34,791 DEBUG quic [34ffef4cef0dff44] QuicConnectionState.CONNECTED -> QuicConnectionState.CLOSING
2021-03-19 22:06:35,755 DEBUG quic [34ffef4cef0dff44] Discarding epoch Epoch.ONE_RTT
2021-03-19 22:06:35,756 DEBUG quic [34ffef4cef0dff44] QuicConnectionState.CLOSING -> QuicConnectionState.TERMINATED

As you could see from above, the speed of this transaction is 2.949 Mbps, which is significantly slower then usual, and it happens once in about every 3 tests. Otherwise the usual speed can reach about 20~30Mbps over the same network. Please see the output of a 'usual-speed' file transfer below.
http3 server output:
2021-03-19 22:14:49,736 DEBUG asyncio Using selector: EpollSelector
2021-03-19 22:14:52,819 DEBUG quic [b93fa38de016aed8] Network path ('::ffff:[dest ip here]', 55609, 0, 0) discovered
2021-03-19 22:14:52,821 DEBUG quic [b93fa38de016aed8] QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED
2021-03-19 22:14:52,828 DEBUG quic [b93fa38de016aed8] TLS State.SERVER_EXPECT_CLIENT_HELLO -> State.SERVER_EXPECT_FINISHED
2021-03-19 22:14:53,029 DEBUG quic [b93fa38de016aed8] Discarding epoch Epoch.INITIAL
2021-03-19 22:14:53,029 DEBUG quic [b93fa38de016aed8] Network path ('::ffff:[dest ip here]', 55609, 0, 0) validated by handshake
2021-03-19 22:14:53,039 DEBUG quic [b93fa38de016aed8] TLS State.SERVER_EXPECT_FINISHED -> State.SERVER_POST_HANDSHAKE
2021-03-19 22:14:53,039 DEBUG quic [b93fa38de016aed8] Discarding epoch Epoch.HANDSHAKE
2021-03-19 22:14:53,040 INFO quic [b93fa38de016aed8] ALPN negotiated protocol h3-32
2021-03-19 22:14:53,040 DEBUG quic [b93fa38de016aed8] Stream 2 created by peer
2021-03-19 22:14:53,040 DEBUG quic [b93fa38de016aed8] Stream 6 created by peer
2021-03-19 22:14:53,040 DEBUG quic [b93fa38de016aed8] Stream 10 created by peer
2021-03-19 22:14:53,041 DEBUG quic [b93fa38de016aed8] Stream 0 created by peer
2021-03-19 22:14:53,041 INFO quic [b93fa38de016aed8] HTTP request GET /8m_file
2021-03-19 22:14:54,261 DEBUG quic [b93fa38de016aed8] Remote max_data raised to 2097152
2021-03-19 22:14:54,261 DEBUG quic [b93fa38de016aed8] Stream 0 remote max_stream_data raised to 2097152
2021-03-19 22:14:54,468 DEBUG quic [b93fa38de016aed8] Remote max_data raised to 4194304
2021-03-19 22:14:54,468 DEBUG quic [b93fa38de016aed8] Stream 0 remote max_stream_data raised to 4194304
2021-03-19 22:14:54,682 DEBUG quic [b93fa38de016aed8] Remote max_data raised to 8388608
2021-03-19 22:14:54,683 DEBUG quic [b93fa38de016aed8] Stream 0 remote max_stream_data raised to 8388608
2021-03-19 22:14:54,896 DEBUG quic [b93fa38de016aed8] Remote max_data raised to 16777216
2021-03-19 22:14:54,897 DEBUG quic [b93fa38de016aed8] Stream 0 remote max_stream_data raised to 16777216
2021-03-19 22:14:55,144 DEBUG quic [b93fa38de016aed8] Loss detection triggered
2021-03-19 22:14:55,339 DEBUG quic [b93fa38de016aed8] Remote max_data raised to 33554432
2021-03-19 22:14:55,340 DEBUG quic [b93fa38de016aed8] Stream 0 remote max_stream_data raised to 33554432
2021-03-19 22:14:55,554 INFO quic [b93fa38de016aed8] Connection close code 0x0, reason
2021-03-19 22:14:55,555 DEBUG quic [b93fa38de016aed8] QuicConnectionState.CONNECTED -> QuicConnectionState.DRAINING
2021-03-19 22:14:56,232 DEBUG quic [b93fa38de016aed8] Discarding epoch Epoch.ONE_RTT
2021-03-19 22:14:56,232 DEBUG quic [b93fa38de016aed8] QuicConnectionState.DRAINING -> QuicConnectionState.TERMINATED

http3 client output:
2021-03-19 22:14:52,514 DEBUG asyncio Using selector: EpollSelector
2021-03-19 22:14:52,519 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2021-03-19 22:14:52,719 INFO quic [b93fa38de016aed8] Retrying with QuicProtocolVersion.DRAFT_32
2021-03-19 22:14:52,721 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_HANDSHAKE_START -> State.CLIENT_EXPECT_SERVER_HELLO
2021-03-19 22:14:52,922 DEBUG quic [b93fa38de016aed8] Loss detection triggered
2021-03-19 22:14:52,929 DEBUG quic [b93fa38de016aed8] QuicConnectionState.FIRSTFLIGHT -> QuicConnectionState.CONNECTED
2021-03-19 22:14:52,930 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_EXPECT_SERVER_HELLO -> State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS
2021-03-19 22:14:52,930 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_EXPECT_ENCRYPTED_EXTENSIONS -> State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE
2021-03-19 22:14:52,931 DEBUG quic [b93fa38de016aed8] Discarding epoch Epoch.INITIAL
2021-03-19 22:14:52,931 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_EXPECT_CERTIFICATE_REQUEST_OR_CERTIFICATE -> State.CLIENT_EXPECT_CERTIFICATE_VERIFY
2021-03-19 22:14:52,939 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_EXPECT_CERTIFICATE_VERIFY -> State.CLIENT_EXPECT_FINISHED
2021-03-19 22:14:52,940 DEBUG quic [b93fa38de016aed8] TLS State.CLIENT_EXPECT_FINISHED -> State.CLIENT_POST_HANDSHAKE
2021-03-19 22:14:52,940 INFO quic [b93fa38de016aed8] ALPN negotiated protocol h3-32
2021-03-19 22:14:52,940 INFO client New session ticket received
2021-03-19 22:14:52,940 DEBUG quic [b93fa38de016aed8] Stream 3 created by peer
2021-03-19 22:14:52,941 DEBUG quic [b93fa38de016aed8] Stream 7 created by peer
2021-03-19 22:14:52,941 DEBUG quic [b93fa38de016aed8] Stream 11 created by peer
2021-03-19 22:14:53,120 DEBUG quic [b93fa38de016aed8] Decryption key is not available
2021-03-19 22:14:53,141 DEBUG quic [b93fa38de016aed8] Discarding epoch Epoch.HANDSHAKE
2021-03-19 22:14:54,163 DEBUG quic [b93fa38de016aed8] Local max_data raised to 2097152
2021-03-19 22:14:54,163 DEBUG quic [b93fa38de016aed8] Stream 0 local max_stream_data raised to 2097152
2021-03-19 22:14:54,370 DEBUG quic [b93fa38de016aed8] Local max_data raised to 4194304
2021-03-19 22:14:54,370 DEBUG quic [b93fa38de016aed8] Stream 0 local max_stream_data raised to 4194304
2021-03-19 22:14:54,584 DEBUG quic [b93fa38de016aed8] Local max_data raised to 8388608
2021-03-19 22:14:54,585 DEBUG quic [b93fa38de016aed8] Stream 0 local max_stream_data raised to 8388608
2021-03-19 22:14:54,790 DEBUG quic [b93fa38de016aed8] Local max_data raised to 16777216
2021-03-19 22:14:54,790 DEBUG quic [b93fa38de016aed8] Stream 0 local max_stream_data raised to 16777216
2021-03-19 22:14:54,809 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 640
2021-03-19 22:14:54,818 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 648
2021-03-19 22:14:54,828 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 656
2021-03-19 22:14:54,837 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 664
2021-03-19 22:14:54,847 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 672
2021-03-19 22:14:54,857 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 680
2021-03-19 22:14:54,866 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 688
2021-03-19 22:14:54,876 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 696
2021-03-19 22:14:54,885 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 704
2021-03-19 22:14:54,895 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 712
2021-03-19 22:14:54,905 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 720
2021-03-19 22:14:54,914 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 728
2021-03-19 22:14:54,924 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 736
2021-03-19 22:14:54,934 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 744
2021-03-19 22:14:54,943 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 752
2021-03-19 22:14:54,954 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 760
2021-03-19 22:14:54,963 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 768
2021-03-19 22:14:54,985 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 776
2021-03-19 22:14:55,003 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 784
2021-03-19 22:14:55,013 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 792
2021-03-19 22:14:55,018 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,019 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,027 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,037 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,047 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,056 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,066 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,076 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,084 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 800
2021-03-19 22:14:55,090 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,095 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 808
2021-03-19 22:14:55,105 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 816
2021-03-19 22:14:55,109 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,109 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,115 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 824
2021-03-19 22:14:55,117 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,125 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 832
2021-03-19 22:14:55,127 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,135 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 840
2021-03-19 22:14:55,136 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,144 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 848
2021-03-19 22:14:55,146 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,154 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 856
2021-03-19 22:14:55,157 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,165 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 864
2021-03-19 22:14:55,167 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,175 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 872
2021-03-19 22:14:55,184 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 880
2021-03-19 22:14:55,188 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,194 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 888
2021-03-19 22:14:55,204 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 896
2021-03-19 22:14:55,206 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,213 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 904
2021-03-19 22:14:55,216 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,227 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 912
2021-03-19 22:14:55,237 DEBUG quic [b93fa38de016aed8] Local max_data raised to 33554432
2021-03-19 22:14:55,241 DEBUG quic [b93fa38de016aed8] Stream 0 local max_stream_data raised to 33554432
2021-03-19 22:14:55,242 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 920
2021-03-19 22:14:55,284 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,295 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,305 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,315 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,325 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,334 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,344 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,354 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 928
2021-03-19 22:14:55,355 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,363 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 936
2021-03-19 22:14:55,366 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,374 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,381 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 944
2021-03-19 22:14:55,384 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,393 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,403 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,413 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,427 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,437 DEBUG quic [b93fa38de016aed8] Sending PING (ACK-of-ACK trigger) in packet 952
2021-03-19 22:14:55,442 DEBUG quic [b93fa38de016aed8] Received PING (probe) response
2021-03-19 22:14:55,455 INFO client Response received for GET /8m_file : 8388608 bytes in 2.5 s (26.718 Mbps)
2021-03-19 22:14:55,456 DEBUG quic [b93fa38de016aed8] QuicConnectionState.CONNECTED -> QuicConnectionState.CLOSING
2021-03-19 22:14:56,135 DEBUG quic [b93fa38de016aed8] Discarding epoch Epoch.ONE_RTT
2021-03-19 22:14:56,136 DEBUG quic [b93fa38de016aed8] QuicConnectionState.CLOSING -> QuicConnectionState.TERMINATED

The difference of output I could see between the above two cases is that, during an "reduced-speed" file transfer, on the server side there's a KeyUnavailableError("Decryption key is not available"). Also, it appears that the client side doesn't send PING (probe) or PING (ACK-of-ACK trigger) in this case, which it always does in a "usual-speed" file transfer. But I haven't figured out if these behaviours are related to each other. Thanks for reading, I appreciate it. Any advises or explanation will be appreciated. Also pls let me know if you need more logs.

This may be related to #129, there seem to be conditions where aioquic's retransmission is suboptimal. I'd like to get to the bottom of this!
In terms of trace a Wireshark capture (ideally on both client & server sides for the same test), but you'll also need to capture the encryption keys used with the --secrets-log somefile.log option.

Another thing which probably doesn't help is that you seem to be having to negotiate the protocol version of each of your tests (so additional RTTs): are you running the same version of aioquic on client and server? I suspect the server is using an older version.

Thank you so much for the reply! Sorry that I didn't update earlier. You're right - I was using an old version in my previous test. I switched to the lastest version and did four tests (normal vs keyUnavailableError; trasferring a 2MB and a 512kB file), please refer to the trace below.
trace.zip
I just realized after finishing the tests that the --secrets-log option appends lines to the file instead of overwriting it, so the keys I logged don't only include keys from that corresponding test, but also previous (possibly irrelavant) tests. So please refer to the keys in reverse order (since there're no timestamps to refer to), and please let me know if you do need a "clean" version of keys logs. So many thanks again!

Hi @maruibin this should be fixed by #265 which triggers more agressive retransmission of CRYPTO data during the handshake. If you can still reproduce the issue with the latest code, could you please open a new issue with your new traces?

Hai ,
It is not an issue.
one small quick query
@maruibin
I am trying to upload file using aioquic(using below command) and not able to get how to do
and instead getting file with data as "Method Not Allowed" while using below command
I didnt made any changes to http3_client.py or http3_server.py
(python3 /root/aioquic/examples/http3_client.py --ca-certs /root/aioquic/tests/pycacert.pem -v https://<IP_ADDRESS>:4433/new.pdf --output-dir /tmp/ --data new.pdf)
any idea Do i need to place the file which i wanted to upload under any speific folder like /aioquic/examples/
(all my files are under /var/www/html/ directory)
Could you please help me to send file using aioquic http3_client.py "--data" argument.
Could you please help me to transfer files between an http/3 client and an http/3 server.
Could you please confirm were you able to create multiple streams in a single connection using the AIOQUIC code .
Looking forward for your reply
Thank you.


OCPP support

Integrate OCPP 1.6 into the SmartEVSE firmware.
Current TODO list:

[x] Add MicroOcpp dependencies
[x] Run MicroOcpp on the same task as Mongoose (--> moved to the main task)
[x] Monitor control pilot status
[x] Create list of possible error states / monitor error states in MicroOcpp
[x] Monitor energy meter and further available sensors
[x] Set Access_bit via OCPP
[x] RFID-based authorization
[x] Add OCPP settings to HTTP API
[x] Add menu item for OCPP settings
[x] Smart Charging
[x] Firmware download and hardware diagnostics upload
[x] Modify connector lock behavior via OCPP (advanced)

O boy, this might be a major one, I never noticed that part of the docs.
Thanks for pointing this out, I'm going to look into it tomorrow; I'd like to take these kinds of non-OCPP related stuff separate and commit them as atomic as possible, if thats ok with you.
Thanks!
Matthias Akstaller @.***> schreef op 1 juni 2024 11:07:53 CEST:

@matth-x commented on this pull request.

@@ -2999,15 +3021,6 @@ void Timer1S(void * parameter) {
} // while(1)
}

-void Mongoose_Poll(void * parameter) {

while (true) {

   if (WiFi.isConnected())

       mg_mgr_poll(&mgr, 1000);

Each call into the mongoose module needs to happen on the same RTOS thread, as the documentation says: https://mongoose.ws/documentation/tutorials/core/multi-threaded/#overview
I believe that the root cause of the crash you mention is somewhere else and unfortunately, such callback-driven frameworks are notoriously hard to debug. If I find possible causes, I will look for alternative solutions.
In general, preemptive multitasking like FreeRTOS threading is dangerous if the software components are not explicitly protected against it (and most high-level libraries on microcontrollers aren't). I would suggest moving all networking-related stuff on the main task as well as non-time-critical code, i.e. mongoose (including MQTT and the web server), OCPP and Wi-Fi management. Otherwise you always need to bear in mind which task is executing what which makes the code more complex to follow + adds the need for extra synchronization mechanisms.
--
Reply to this email directly or view it on GitHub:
https://github.com/dingo35/SmartEVSE-3.5/pull/82#discussion_r1623185455
You are receiving this because you commented.
Message ID: @.***>

Hi @dingo35,
No problem to move the tasks change to another PR. In the end, I could imagine to take all OCPP-related code changes of this PR and apply them in a clean way on a fresh new branch from master. Then it makes no difference if we take out the non-OCPP changes from here.
Anyway, the most recent updates contain:

RFID authorization: as a first step, I think OCPP should monopolize the RFID reader. If OCPP is enabled and RFID is in EnableOne or EnableAll mode, then the UUID is forwarded to the OCPP lib
The HTTP API allows to set the server URL, enable / disable OCPP and view the connection status
Two MQTT topics
LittleFS enabled

For the next steps I have two questions:

What is "announce" in the MQTT area? Do you think it's necessary for OCPP?
How to develop the web dashboard? Do you use a WYSIWYG editor or do you develop the code in a text editor?

Hi Matthias,
Great work! I added some comments, stopped adding the "missing the ENABLE_OCPP here" at some time, you probably get the message :-) .
About  the mgr_init, mgr_poll and mgr_free:
For us, mgr_init should be in the wifi event "connected" since we need it to stop/start when the captive portal is started.... Same for mgr_free in wifi event "disconnect" . I don't think this is any problem for you?
I will move mgr_poll to loop(), how about I do that in a separate commit in my master, and insulate it from OCPP ?
As to MQTT announce, every topic that MQTT publishes needs to be announce so MQTT clients (like HomeAssistant) can auto-discover it.
In your case, the topics do not have a unit of measurement, so place them both after:
announce("RFIDLastRead", "sensor");
... and your topics will appear automagically in HomeAssistant...
As for the web dashboard, we have primitively used a normal text editor but I would love to have a great WYSIWYG editor to maintain it. Of course it should be open source so the community can use it freely. Perhaps we can get rid of that awfull .css too , I don't dare to touch it....
Best regards, Hans.
"Matthias Akstaller" @.***> schreef op 4 juni 2024 om 22:34:

Hi @dingo35 https://github.com/dingo35 ,
No problem to move the tasks change to another PR. In the end, I could imagine to take all OCPP-related code changes of this PR and apply them in a clean way on a fresh new branch from master. Then it makes no difference if we take out the non-OCPP changes from here.
Anyway, the most recent updates contain:

RFID authorization: as a first step, I think OCPP should monopolize the RFID reader. If OCPP is enabled and RFID is in EnableOne or EnableAll mode, then the UUID is forwarded to the OCPP lib

The HTTP API allows to set the server URL, enable / disable OCPP and view the connection status

Two MQTT topics

LittleFS enabled

For the next steps I have two questions:

What is "announce" in the MQTT area? Do you think it's necessary for OCPP?

How to develop the web dashboard? Do you use a WYSIWYG editor or do you develop the code in a text editor?

—
Reply to this email directly, view it on GitHub https://github.com/dingo35/SmartEVSE-3.5/pull/82#issuecomment-2148371317 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOSIX7QJNR3RBGTFLOW22DZFYQF3AVCNFSM6AAAAABITFPLJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGM3TCMZRG4 .
You are receiving this because you were mentioned.

Hi Hans,
Thanks for the code review! I changed the menu position as suggested and added the missing ENABLE_OCPP statements (it compiles now when ENABLE_OCPP=0).
The Mongoose lifecycle is actually a critical topic, because my WebSocket wrapper depends on it and so does MicroOcpp, transitively. In the Mongoose docs and examples I never found that initializing the manager in the very beginning of the boot procedure would be a somehow discouraged practice. In fact, I haven't seen any problems if Mongoose is initialized before the Wi-Fi connection succeeds and remains alive throughout network reconfigurations.
OCPP is also active without network connection. If the charger boots into an offline state, most operators want that it still authorizes RFID cards according to local whitelists and captures charging sessions for a later transmission to the server. So it would be important to be able to have OCPP always on.
How hard would it be extend the lifecycle of Mongoose with the current captive portal implementation?
Okay, I will implement the MQTT announce routine by duplicating the RFID code then.
For the web dashboard, it's no problem to work with a text editor to add the few OCPP settings.

In the current master branch mgr_init is called at WifiSetup, and mgr_free is never caĺled in the normal lifecycle.
Only when the portal is called, mgr_free is called, and at the end, mgr_init again.
So usually the portal is only called on first time installation, and perhaps a few other times during the lifetime of the SmartEVSE, when wifi credentials change.
Would that be a problem for OCPP? I can look for a way to only shut the listeners down?
In what way is mongoose critical to OCPP? Is there a tcp client, http server, or what? What ports are you using?
Also: do you need certificates on the device? Are they specific to the device or can they be generic?
Keep up the great work!
Hans.

From the user perspective it's no problem to disable OCPP while the Wi-Fi portal is up and running. The only thing necessary is to shut down OCPP before MG is deinitialized and then to start it up again. I looked for possible locations on the recent master branch, but doing so I still found that the MG lifecycle model seems quite complex. The reason to shut down MG is to free the ports 80 and 443 again for WiFiManager? I'm wondering why not unbind the listeners on these ports and keep MG initialized. The other background tasks of MG (i.e. MQTT and OCPP trying to reconnect) shouldn't be a problem.
This would also avoid MG functions being called from another thread here:
https://github.com/dingo35/SmartEVSE-3.5/blob/f60523249f87dc30cc3f5c5017b187abc8072719/SmartEVSE-3/src/evse.cpp#L4769
https://github.com/dingo35/SmartEVSE-3.5/blob/f60523249f87dc30cc3f5c5017b187abc8072719/SmartEVSE-3/src/evse.cpp#L4777
What do you think? I can also make a quick write up in another draft PR so we can discuss about it there.

Also: do you need certificates on the device? Are they specific to the device or can they be generic?

The device needs only one root CA cert for the OCPP server. But between OCPP servers, the root certs can differ of course. How do you plan to do certificate management for MQTT? I think the easiest is to just use the same approach for both protocols.
In OCPP, there is also the possibility to have the certificates managed by the server. I will add that as an extra feature in future, but I'm not sure how widely it is used in practice at the moment.

Keep up the great work!

Thanks, I also appreciate how well this project is made!

I tried removing those mg_mgr_free and mg_mgr_init lines out of the code, because the listeners ARE already closed when in portal mode:
but the portal becomes unresponsive if I remove those two lines; it might be the closing isn't done completely or in time, or it has to do with the fact that the closing is done on receipt of the first traffic in portal mode (WIFImode == 2) ; probably the latter one.
I need the mg_connection *c for the closing, I would hate to have to make a global out of that, also, the portal is started from the menu, and also as a separate task, so not in the mongoose thread.....
How about we close down OCPP completely when in / before going into portal mode, and either restart OCPP or, if that is not possible, reboot?
We don't have any root certificate for MQTT currently, I'm currently integrating an automatic OTA update facility that will use a CA certificate. I guess we would prefer to have that on LittleFS partition to keep the code small, perhaps take care of that on the initial flash? Although if that is programmed, the certificate would be in the code anyways ?
Hans.
"Matthias Akstaller" @.***> schreef op 6 juni 2024 om 20:35:

From the user perspective it's no problem to disable OCPP while the Wi-Fi portal is up and running. The only thing necessary is to shut down OCPP before MG is deinitialized and then to start it up again. I looked for possible locations on the recent master branch, but doing so I still found that the MG lifecycle model seems quite complex. The reason to shut down MG is to free the ports 80 and 443 again for WiFiManager? I'm wondering why not unbind the listeners on these ports and keep MG initialized. The other background tasks of MG (i.e. MQTT and OCPP trying to reconnect) shouldn't be a problem.
This would also avoid MG functions being called from another thread here:
https://github.com/dingo35/SmartEVSE-3.5/blob/f60523249f87dc30cc3f5c5017b187abc8072719/SmartEVSE-3/src/evse.cpp#L4769
https://github.com/dingo35/SmartEVSE-3.5/blob/f60523249f87dc30cc3f5c5017b187abc8072719/SmartEVSE-3/src/evse.cpp#L4777
What do you think? I can also make a quick write up in another draft PR so we can discuss about it there.

Also: do you need certificates on the device? Are they specific to the device or can they be generic?

The device needs only one root CA cert for the OCPP server. But between OCPP servers, the root certs can differ of course. How do you plan to do certificate management for MQTT? I think the easiest is to just use the same approach for both protocols.
In OCPP, there is also the possibility to have the certificates managed by the server. I will add that as an extra feature in future, but I'm not sure how widely it is used in practice at the moment.

Keep up the great work!

Thanks, I also appreciate how well this project is made!
—
Reply to this email directly, view it on GitHub https://github.com/dingo35/SmartEVSE-3.5/pull/82#issuecomment-2153158813 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOSIXZZBQ7SD2YVWEHYHUDZGCTXLAVCNFSM6AAAAABITFPLJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJTGE2TQOBRGM .
You are receiving this because you were mentioned.

I made a little test before suggesting this. The resulting setup is:

Port listeners 80 and 443 become globals
Before starting WiFiManager, unbind the ports by setting the flag port_listener_80->is_closing = 1; (same for 443)
Wait for one loop() iteration on the main thread to be executed (the next mg_mgr_poll() closes the connection). However I'm not sure if that's actually needed, didn't do it in my test and the WiFiManager web page still showed up
Start WiFiManager

The alternative of shutting down OCPP would mean roughly the same setup, because ocppDeinit() and mg_mgr_free() also need to be called from the main thread. Instead of defining the port listeners as globals we would need other global variables which allow to shut down MG and OCPP from another thread. Not bad, but it adds to the complexity of the system if the MG lifecycle is variable.

We don't have any root certificate for MQTT currently, I'm currently integrating an automatic OTA update facility that will use a CA certificate. I guess we would prefer to have that on LittleFS partition to keep the code small, perhaps take care of that on the initial flash? Although if that is programmed, the certificate would be in the code anyways ?

Actually I think that compiling the certificate into the firmware has some advantages, if done automatically. The built-in OTA procedure of espressif is well tested and comes with fail-safety and integrity check measures. We would effectively reuse all of that. On the other hand, for some users that's no option, because they want a pre-programmed device where they only need to upload the cert file over the web dashboard.
For OCPP (or MG in general) it's no problem to work with built-in certs or certs from the data partition, both manually uploaded certs or stored as factory default.

Inline!
"Matthias Akstaller" @.***> schreef op 7 juni 2024 om 12:56:

I made a little test before suggesting this. The resulting setup is:

Port listeners 80 and 443 become globals

Before starting WiFiManager, unbind the ports by setting the flag port_listener_80->is_closing = 1; (same for 443)

Wait for one loop() iteration on the main thread to be executed (the next mg_mgr_poll() closes the connection). However I'm not sure if that's actually needed, didn't do it in my test and the WiFiManager web page still showed up

Start WiFiManager

Ok lets do it this way. Since you tested it, include it in your commits, no use for me doing it all over again.

The alternative of shutting down OCPP would mean roughly the same setup, because ocppDeinit() and mg_mgr_free() also need to be called from the main thread. Instead of defining the port listeners as globals we would need other global variables which allow to shut down MG and OCPP from another thread. Not bad, but it adds to the complexity of the system if the MG lifecycle is variable.

We don't have any root certificate for MQTT currently, I'm currently integrating an automatic OTA update facility that will use a CA certificate. I guess we would prefer to have that on LittleFS partition to keep the code small, perhaps take care of that on the initial flash? Although if that is programmed, the certificate would be in the code anyways ?

Actually I think that compiling the certificate into the firmware has some advantages, if done automatically. The built-in OTA procedure of espressif is well tested and comes with fail-safety and integrity check measures. We would effectively reuse all of that. On the other hand, for some users that's no option, because they want a pre-programmed device where they only need to upload the cert file over the web dashboard.
For OCPP (or MG in general) it's no problem to work with built-in certs or certs from the data partition, both manually uploaded certs or stored as factory default.
—

Ok lets go for the builtin stuff as much as possible!

Reply to this email directly, view it on GitHub https://github.com/dingo35/SmartEVSE-3.5/pull/82#issuecomment-2154596210 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOSIX2GD7TNERM7MEBCCDTZGGGV7AVCNFSM6AAAAABITFPLJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJUGU4TMMRRGA .
You are receiving this because you were mentioned.

The initial integration is ready now!
To comment on the latest changes: in 3ee0fb19e856e3b6e67696f2ada85bc6f1861335 I implemented the Mongoose HTTP server lifecycle as described in https://github.com/dingo35/SmartEVSE-3.5/pull/82#issuecomment-2154596210. In the next commit 71e84128517a342b2e8b51c83c2190ac35273711 I recreated the MQTT timer lifecycle that it stops while the WiFi connection is lost. I think that it wouldn't be harmful if that timer continued running (maybe at a lower frequency), but it's no hassle to stop it.
For Smart Charging, the connector lock (and RFID authorization) I implemented "OCPP-only" modes, i.e. OCPP takes over full control over the connector lock and RFID (if in mode EnableOne or EnableAll) and the load balancer if the load balancer is disabled.
For firmware updates and diagnostics uploads I finally made the built-in solution of MicroOcpp ready (which will also be tested in other installations). We could, however, customize the OTA process and add more hardware diagnostics, if we have use cases which require that.

Nice, tried both the fork of @matth-x and the merged one here. With the fork of Matthias I can connect to E-Flux

With the merged one here I doesn't connect. Pretty weird?
First test with remotestart and remotestop seems to work. Only to be shut off after 1-2s since the station and tag is not authorized. But I hear the contactor clicking.

Tagging @dingo35 @mstegen so they know I'm already fiddling around.
They only thing that I cannot get to work is the RFID reader. Looks like the local rfid.txt list is disabled/ignored (what I've also read here in the conv.) but the RFIDLastRead is not getting updated when holding tags in front of the reader.

Hi @fluppie, thanks for taking a look at the OCPP integration!
The existing RFID whitelisting is fully bypassed in this first integration. OCPP catches the RFID events and doesn't forward them to SmartEVSE again. So RFIDLastRead remains blank.
To use RFID-based authorization with OCPP, the RFID settings must be "EnableOne" or "EnableAll". To use OCPP Smart Charging, the SmartEVSE load balancer must be turned off so that it's in mode "0". Not too user friendly, but should do the job in the beginning.

I can't get the RFID stuff to work. Tried it on a real one connected to a vehicle and then on a EVSE next to my computer with only an RFID reader connected. is there a way to see if the EVSE is actually reading a tag? Maybe we should flash the red and green LED's on the reader at the same time when a tag is read? (that's more towards @dingo35 and @mstegen ) So we get visual feedback that something is happening. For example on the Alfen Eve charging points there's also a buzzer that beeps when you hold a tag in front of the reader. Some "succes" beep and a "rejected" beepbeep.
BTW did you also try to build the merged version here? when I compile from Dingo35's repo it will not connect to the backoffice. Compiling from your repo works.

Just noticed the RFID readers we use send 'only' the 6 LSB of the UID, while Mifare cards can have a 4, 7 or 10 byte UID.
With the SteVe simulator this works fine, but it might not with a real backend.
Will ask the manufacturer of the RFID readers is there is a way to extend the number of bytes that can be read.
Yes good idea. The LED should flash if the card is accepted or not.

@mstegen I installed Steven on a VM and have it running, but I don't see any RFID information being communicated to the platform. At least I don't see anything, but could be due to insufficient knowledge of Steve.
I did not fill in the auth key field, don't know if this is needed?

@fluppie, I am following the same path and I can't see any RFID info either.....

@fluppie, how many bytes is the RFID tag you had to define in OCCP? Does it correspond to the 6 bytes in the SmartEVSE logs or did you have to find out the 7th byte?

Testing with the Steve implementation Matthias provided. If i try to authenticate with a RFID card, the ID is visible on the serial output of the SmartEVSE:
[MO] Recv: [3,"1000003",{"idTagInfo":{"status":"Invalid"}}]

When i go to the SteVe webserver, Data Management -> OCPP tags, then click on 'Unknown Tags (i)' The ID is visible here.
Then click on Add card (or something like that)
Now the card should be accepted by the SmartEVSE.
But i noticed you'll have to tap the card very quickly, otherwise it will go to Enable and then immediately back to Disable.
[MO] Recv: [3,"1000016",{"idTagInfo":{"status":"Accepted","expiryDate":"2024-07-09T11:15:05.268Z"}}]
[MO] Send: [2,"1000017","StartTransaction",{"connectorId":1,"idTag":"04656B82EB2CDD","meterStart":25,"timestamp":"2024-07-09T10:15:03.305Z"}]
[MO] Recv: [3,"1000017",{"transactionId":173,"idTagInfo":{"status":"Accepted","expiryDate":"2024-07-09T11:15:05.591Z"}}]
[MO] Send: [2,"1000018","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"SuspendedEV","timestamp":"2024-07-09T10:15:03.538Z"}]

Yes it only started working when I made a user and assigned a tag to a user.
16:08:51.529 -> [MO] Send: [2,"1000005","Authorize",{"idTag":"5CED2D290000AF"}]
948A17C300002F
5CED2D290000AF

RFIDLastRead
948A17C30000
5CED2D290000

Is rfid.txt already ready to support the 7th byte? Or maybe we shouldn't be using the 7th at all, since an Alfen doesn't read it either.
Would be nice if we can support a local list via de txt file for when the (internet) connection between EVSE and Steve/Backend cuts and charging can still be started/stopped.
Maybe we should think of some debounce for sending the tag id? 1000ms? 2000ms?

Can you document that Alphen only uses 6 bytes for OCPP?
It might be needed when talking to backend providers...

I just pushed a 1,5s debounce 3e963e9

Nope, with a Robocharge tag it's longer.
Can we flash the led green or red when the tag is valid or invalid? Based on that idTagInfo message?
20:18:50.730 -> [MO] Send: [2,"1000009","Authorize",{"idTag":"948A17C300002F"}]
20:18:50.776 -> [MO] Recv: [3,"1000009",{"idTagInfo":{"status":"Invalid"}}]

@fluppie Yes that's already on the road map for the next revision.

@matth-x would you be so kind to apply this patch to your mongoose adapter, so we can upgrade to mongoose 7.14:
mongoose714.zip

@dingo35 Thank you for the contribution! The new commit hash is dae388fe04beff6174b7fc30bc67dd4ad8343df3

Moving the integration + discussion to a new PR (this branch and dingo35/master have diverged quite a bit)


Add configuration options to keep graphql file extension

@bgentry Could we get a new release out with the changes in this PR? Thanks.

@josemarluedke well I tried to do this today but my GPG key isn't set up on this machine, will have to wait until later when I'm at home 🤷♂

@josemarluedke v2.0.0-beta.2 released, sorry for the delay :v:


add linting and validation to terraform code

PR draft to trigger github actions

Looks good! Maybe just needs a comment in the readme reminding people to keep the test fixture project yaml in sync?


Upgrade to EKS 1.30

The EKS clusters should use version 1.30. This is gated on all required EKS addons supporting this version.

Closed by #1006


Graphviz

closes jgrss/geowombat#261
@conda-forge-admin, please rerender

Checklist

[x ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x ] Ensured the license file is being packaged.

Non noarch packages should have python requirement without any version constraints.
Non noarch packages should have python requirement without any version constraints.
refers to     - python >=3.7,<=3.9.16

Consider using
build:
- python                                 # [build_platform != target_platform]
- cross-python_{{ target_platform }}     # [build_platform != target_platform]
- cython                                 # [build_platform != target_platform]
- numpy                                  # [build_platform != target_platform]
might fix need to pin python

Seemed to work
commit 4a3ec991e65b1394ae43c616af9251d996f3b49b


How to make speak HA with google home

I seek has to vocally send temperature measurements on the apparatus google home.
Can advise me? (Translate by systran , because my english is bad !)

Please use our help channels for support questions.
https://home-assistant.io/help/#communication-channels


Problems with pax and proceedings with hundred of papers

@zhzhang @ryancotterell  I think I found the issue about the ACL compile error.
It was not a problem only tied to save_size, but also to pool_size.
Here is what I did on my mac.
First I relaxed the umount of files I could open:
ulimit -S -n 2048
I searched for the place to add my parameters:
kpsewhich --all texmf.cnf
It pointed to the two files
/usr/local/texlive/2016/texmf.cnf`
/usr/local/texlive/2016/texmf-dist/web2c/texmf.cnf

The first one needed to be modified. I just added a larger
pool_size = 20000000
save_size = 800000

(maybe too large, but I was not sure about the limit) and it seems to work!
I think that know we should re-add  \usepackage{pax} to aclpub2/templates/proceedings.tex and invoke twice pdflatex from aclpub2/generate.py.
Unfortunately, I fear we cannot apply Ryan's suggestion to merge smaller parts of the proceedings, as the reference to one page is "absolute" and it will be lost

Great! So is this working now?

@zhzhang @ryancotterell : maybe I have a viable solution.
We can build two exported versions of the papers:

The main (whole) proceedings with the concatenation of papers, without inner links (so disabling the pax library).
A second export for each watermarked paper: each paper should be read, watermarked (even with pages), and saved, preserving the original inner links. After all, these are the papers that will be used in the future and for which links are needed.

As a side-effect, links will be consistent in the watermarked papers (with the actual procedure, internal hyperlink are out-of-sync).
What do you think? @zhzhang is it simple for the actual software?
I am pretty sure that such a workaround is gonna work

@zhzhang: we must remember to also include in the watermarked paper a dedicated paper with only the frontmatter (to be included alone in aclanthology)

@zhzhang @ryancotterell I shared with you on slack the link to the first versions of the proceedings with all long papers. If you like that output, you can close this issue.


"Certificate doesn't exist" when trying to create a new revision

This issue is a:

[x] bug report
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
The error:
Certificate '/subscriptions/97e6785f-b82b-48b5-8a66-6844aa792173/resourceGroups/rg-ratior/providers/Microsoft.App/managedEnvironments/managedEnvironment-rgratior-bf97/certificates/' doesn't exist

is suddenly showing up when trying to update a container app and creating a new revision. Both with the Azure Portal and the Azure CLI.
This procedure was working fine in our CI/CD pipelines a week ago, without anyone changing anything!
I checked the certificate in the Container Apps Environment. There was nothing wrong with it and no one has changed anything.
Steps to reproduct

Ran the following command: az containerapp update --name ratior-frontend-production --resource-group rg-ratior --image crdevonso.azurecr.io/ratior-frontend-production:2196

Expected behavior [What you expected to happen.]
I expected to see a new revision created and my service updated.
Actual behavior [What actually happened.]
The above mentioned error is printed in the console.
Screenshots
Also tested with the Azure Portal and the same error showed up:

This is happening for all of our current container apps that are inside the mentioned Container Apps Environment, but not for the new container apps that are created inside it.

@AliMirlou we have identified a bug. We will be preparing a fix and deploying it shortly. Thank you for reporting this

The bug seems to have been fixed. Thanks and I'll close the issue.


FirebaseAppDelegateProxyEnabled Info.plist value not always respected in Xcode 13

[REQUIRED] Step 1: Describe your environment

Xcode version: 13.0 RC
Firebase SDK version: 8.7.0
Installation method: Swift Package Manager
Firebase Component: Core

[REQUIRED] Step 2: Describe the problem
When I set FirebaseAppDelegateProxyEnabled to NO in my Info.plist, Xcode 13 seems to ignore this value and proceed with method swizzling.
I get the following output in my console:
8.7.0 - [Firebase/Messaging][I-FCM001000] FIRMessaging Remote Notifications proxy enabled, will swizzle remote notification receiver handlers. If you'd prefer to manually integrate Firebase Messaging, add "FirebaseAppDelegateProxyEnabled" to your Info.plist, and set it to NO. Follow the instructions at:
https://firebase.google.com/docs/cloud-messaging/ios/client#method_swizzling_in_firebase_messaging

Steps to reproduce:
Set FirebaseAppDelegateProxyEnabled in your Info.plist to NO.
Note that this doesn't seem to happen all the time, which is even more confusing. If it occurs and I manually remove and re-add the value via the source code, it works again. Shortly later, it'll stop detecting and I'll need to do it again. I have no clue what is going on.
Relevant Code:
n/a

Additionally, in Xcode 13, when setting a custom Boolean value in the Info.plist, it also now displays the boolean in binary rather than YES/NO strings. This likely doesn't have anything to do with the issue, because the underlying Info.plist source code still shows <true/> and <false/> appropriately. Just calling this out.

I'm also unsure if it is related, but no amount of disabling Firebase prevents the following spam in my console:
8.7.0 - [Firebase/Performance][I-PRF100013] Dropping event since data collection is disabled.

and
8.7.0 - [Firebase/Firestore][I-FST000001] WriteStream (7fec31f0ad38) Stream error: 'Unknown: An internal error has occurred, print and inspect the error details for more information.'

Both repeating just about endlessly...
All I want is for Firebase to stop spamming my console with stuff in local development. Why is it so hard to do this?

Hey @bdrelling - sorry for the troubles you're seeing. I haven't been able to reproduce this at all and I think we'll have trouble doing so without a reliable repro. I'd suggest setting a breakpoint here:
https://github.com/firebase/firebase-ios-sdk/blob/f243335a256264a5190830406208c524b1bdd527/FirebaseMessaging/Sources/FIRMessaging.m#L268
and trying to see what the Info.plist values show when that evaluates to true.
One thing that comes to mind though, we read from the mainBundle so perhaps using it in an extension or in an environment where the mainBundle isn't what we expect?: https://github.com/google/GoogleUtilities/blob/616fac2626b6b2d1424d79a6f786b4e2ed1cfb49/GoogleUtilities/AppDelegateSwizzler/GULAppDelegateSwizzler.m#L191

All I want is for Firebase to stop spamming my console with stuff in local development. Why is it so hard to do this?

Can you please file a new issue for this one so we can track it separately?

@ryanwilson Thanks, it helps at least knowing if it's happening to others vs. just me. I'll dig a little deeper into it. If I figure anything out, I'll post back to this ticket. If I can't, I'll make a reproducible project if possible.
Re: New issue for that one, sure thing! Wasn't sure if it was related, will do. 👍🏻
Thanks!


Validation tool flagging errors incorrectly

I ran the validation tool and had a Level 2 compliant GDB, with errors flagged for having glossary terms that were not used in the database. I deleted the two Glossary definitions that weren't used in the GDB (questionable, and geomaterial-low), and when I ran the validation tool again it flagged all these errors and suddenly the GDB was Level 1 compliant. The error report listed all these type values as not being defined, and missing data sources - errors which were not errors prior to deleting these values. I re-ran the tool a few times in ArcMap and was still getting these wild errors, ones that I knew were not actually errors. So, I ran the validation tool in ArcCatalog and the GDB had no errors and was Level 3 compliant. I unfortunately didn't save any of the error reports from when this was happening. I've attached the message and environments from the results of the validation tool.
ValidationMessage.txt

In my experience, errors like this reflect the presence of a join or a definition query. Or the presence (in ArcMap) of a map-composition layer that Arc wrongly identifies as part the database being validated--hence the advice to run from ArcCatalog.  I don't understand ArcMap well enough to code a test for this latter possibility.  I have modified the help text for the script to emphasize these causes of incorrectly-flagged errors.
I'm closing this issue, but if you'd like to see it re-opened, and especially if you have ideas about how to better address it, I'd be happy to revisit.
Ralph

I have run into this same issue but have never run from ArcMap.  Also do not have joins in my glossary.
Linda

Linda-
Do you have any idea as to the triggering phenoma?
Ralph

From: LindaTedrow<EMAIL_ADDRESS>Sent: Wednesday, December 23, 2020 10:58 AM
To: usgs/gems-tools-arcmap<EMAIL_ADDRESS>Cc: Haugerud, Ralph A<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Subject: [EXTERNAL] Re: [usgs/gems-tools-arcmap] Validation tool flagging errors incorrectly (#47)
This email has been received from outside of DOI - Use caution before clicking on links, opening attachments, or responding.
I have run into this same issue but have never run from ArcMap. Also do not have joins in my glossary.
Linda
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fusgs%2Fgems-tools-arcmap%2Fissues%2F47%23issuecomment-750430658&data=04|01|rhaugerud%40usgs.gov|6094af609d6243cdf9e308d8a774d001|0693b5ba4b184d7b9341f32f400a5494|0|0|637443467751550774|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=XJxO%2BlUavLzyUrpySCuI%2BBKTKp6SW%2BH8MYOL%2BnXZB1I%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFS3CJO4DVSANTHSP2Y5C4DSWI4WFANCNFSM4OPG3BIA&data=04|01|rhaugerud%40usgs.gov|6094af609d6243cdf9e308d8a774d001|0693b5ba4b184d7b9341f32f400a5494|0|0|637443467751560729|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=j%2FQC%2B1u7%2F5woYm%2B2fak7sOoZAE%2F%2FNzddlIgD8Gv4%2BK0%3D&reserved=0.

Ralph,
I don’t know why this happens – but generally what happens is the values do not show up.
Then I add again and then I have two values.
For some reason ArcCatalog mostly does not look like it updates; but it does.
I blamed our server system but if others are having this same problem it is not “our server”.
Linda
From: Ralph Haugerud<EMAIL_ADDRESS>Sent: Wednesday, December 23, 2020 11:02 AM
To: usgs/gems-tools-arcmap<EMAIL_ADDRESS>Cc: Tedrow, Linda<EMAIL_ADDRESS><EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [usgs/gems-tools-arcmap] Validation tool flagging errors incorrectly (#47)
Linda-
Do you have any idea as to the triggering phenoma?
Ralph

From: LindaTedrow <notifications<EMAIL_ADDRESS>Sent: Wednesday, December 23, 2020 10:58 AM
To: usgs/gems-tools-arcmap <gems-tools-arcmap<EMAIL_ADDRESS>Cc: Haugerud, Ralph A <rhaugerud<EMAIL_ADDRESS>State change <state_change<EMAIL_ADDRESS>Subject: [EXTERNAL] Re: [usgs/gems-tools-arcmap] Validation tool flagging errors incorrectly (#47)
This email has been received from outside of DOI - Use caution before clicking on links, opening attachments, or responding.
I have run into this same issue but have never run from ArcMap. Also do not have joins in my glossary.
Linda
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fusgs%2Fgems-tools-arcmap%2Fissues%2F47%23issuecomment-750430658&data=04|01|rhaugerud%40usgs.gov|6094af609d6243cdf9e308d8a774d001|0693b5ba4b184d7b9341f32f400a5494|0|0|637443467751550774|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=XJxO%2BlUavLzyUrpySCuI%2BBKTKp6SW%2BH8MYOL%2BnXZB1I%3D&reserved=0https://urldefense.com/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fusgs*2Fgems-tools-arcmap*2Fissues*2F47*23issuecomment-750430658&data=04*7C01*7Crhaugerud*40usgs.gov*7C6094af609d6243cdf9e308d8a774d001*7C0693b5ba4b184d7b9341f32f400a5494*7C0*7C0*7C637443467751550774*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=XJxO*2BlUavLzyUrpySCuI*2BBKTKp6SW*2BH8MYOL*2BnXZB1I*3D&reserved=0*3E__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!JYXjzlvb!xh08fphiZB7hBIOiAHWSBzq71fvvGqkR172j56iyqylK_UMrafian6NMPZjwO7bL$, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFS3CJO4DVSANTHSP2Y5C4DSWI4WFANCNFSM4OPG3BIA&data=04|01|rhaugerud%40usgs.gov|6094af609d6243cdf9e308d8a774d001|0693b5ba4b184d7b9341f32f400a5494|0|0|637443467751560729|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=j%2FQC%2B1u7%2F5woYm%2B2fak7sOoZAE%2F%2FNzddlIgD8Gv4%2BK0%3D&reserved=0https://urldefense.com/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fnotifications*2Funsubscribe-auth*2FAFS3CJO4DVSANTHSP2Y5C4DSWI4WFANCNFSM4OPG3BIA&data=04*7C01*7Crhaugerud*40usgs.gov*7C6094af609d6243cdf9e308d8a774d001*7C0693b5ba4b184d7b9341f32f400a5494*7C0*7C0*7C637443467751560729*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&sdata=j*2FQC*2B1u7*2F5woYm*2B2fak7sOoZAE*2F*2FNzddlIgD8Gv4*2BK0*3D&reserved=0*3E__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!JYXjzlvb!xh08fphiZB7hBIOiAHWSBzq71fvvGqkR172j56iyqylK_UMrafian6NMPXAo38Rm$.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/usgs/gems-tools-arcmap/issues/47*issuecomment-750431875__;Iw!!JYXjzlvb!xh08fphiZB7hBIOiAHWSBzq71fvvGqkR172j56iyqylK_UMrafian6NMPeiokwhW$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AKYEVB323OT2NU6RVULMI5DSWI5DFANCNFSM4OPG3BIA__;!!JYXjzlvb!xh08fphiZB7hBIOiAHWSBzq71fvvGqkR172j56iyqylK_UMrafian6NMPZ0NbTuP$.


Automatic generation for CSS, SASS, ... classes

Hello everyone! I am a web developer and mostly work with Angular, HTML and SASS. When building layouts, you have to create a SASS/CSS class parallel to the HTML class. Would it be possible to include a function that automatically creates a class in my SASS/CSS file when creating a class in my HTML code?
It would save a lot of time in development!

Automatically adding stuff is IMO to aggressive, especially as we can't know in which css file you want that rule what would be a good location in that file.
But having a smarter code assist makes IMO sense: https://github.com/microsoft/vscode/issues/28442
Closing as dup


Middlewares activation is not correct

The current implementation creates several middlewares for each database, to do CORS and authentication, but uses a convoluted method to actually enable the correct ones for a database; basically, all the handlers are registered, and if the URL doesn't match the database in each one they are skipped. The problem is that the match is done on the name of the database, but the URL may contain e.g. a trailing slash and the match fails. This mean that for example the authentication could not trigger if the URL have trailing slashes.
Better let Fiber do the match, by registering the relevant middlewares on the POST; this also should have performances benefits, even if probably negligible.

Released in v0.12.6


Implement interpreter support for module import/exports

Add bytecodes and interpreter handlers for StModuleSlot and LdModuleSlot.
Add parser support for exporting async functions.
Better parsing support for export default statements.

@pleath @Yongqu @abchatra would you mind taking a look?
Note: This change is built on top of Yong's work so build will fail until his work is pushed and this change is rebased.

Did I miss the JIT support, or is it coming later?

JIT support is not added here but it should be a bug-level fix later.

Right, it shouldn't be complicated. Now, if people turn on the feature locally are they going to experience random death when we try to JIT? Or is it not possible to enable it?

I'm not sure if the JS experimental flag will turn the feature on or not. I think it will but, yes, we are going to experience random death if we try to JIT one of these until the JIT support is added.

Change looks good from runtime part. I'll leave the remaining bytecode change to Paul.


Fix bug #141

Handle uniqueness of Categories in the same way as Entries.
To enable this patch, one should re-create DB file.

Looks nice. Thank you.


Fix code scanning alert - Overly permissive regular expression range

Tracking issue for:

[x] https://github.com/KingPrimes/NyxBot/security/code-scanning/32
[x] https://github.com/KingPrimes/NyxBot/security/code-scanning/31
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/30
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/29
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/28
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/27
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/26
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/25
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/24
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/23
[ ] https://github.com/KingPrimes/NyxBot/security/code-scanning/22

1b471a44 Fix


Monochrome icon

Adds support for themed icons (Android 13 feature).
The monochrome icon consists only of the white parts of ic_launcher_foreground (in other words, I removed the shadow and blue bar).
Seems to work fine on my device with LineageOS 20 and Trebuchet.

 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.


Request: Tooling option for C# model generation.

From @jaszb on December 7, 2017 11:26
I'd love to have the ability to use the scaffolding ability like "Razor Pages using EF CRUD" except allowing us to control the Class generated.
For example say we want to connect to a restful web api, then being ale to scaffold CRUD against a DTO object would be super useful.
right now the only way i can hack around this is to gen against EF, then turn those classes into DTOs and rip out all the gen'd db context code and replace it with http client calls.
not a small task on a big project.
having some customization over the class gen'd would be great.
just a small bit of feed back for you.
thanks
Copied from original issue: aspnet/Razor#1802

We have the service reference option in new version of Visual Studio that supports generating contents to talk to open API end point.


When updating an opening, if stageOrder is modified, the new length must be equal to the totalStages on the opening

If you want to delete a stage, call /openings/:openingId/stages/:stageId, we handle the stage order update for you in a transaction.
Stages will not be deleted by modifying the stageOrder on the opening

Closed in #536


Add a Birthdate field to the profile information

Added new "birthDate" field to the Profile builder and the Castform template.
This new "Date of Birth" field will only be shown by the template if the user entered it.
Resolves #314

Looks like a good PR, but just a few things I'd like to see. Happy that you already got the translations to other languages down, that helps a lot.

Would you be able to export BirthDate into a separate component BirthDateA?
Would it be possible to update all templates to incorporate the birth date field, not just Castform?
Instead of passing down language to the component, you should be able to get language from data.metadata.language. This is done because language should be visible even when other non-logged in users visit the resume public link and should be able to see the same language.

Thanks for creating this useful tool and for checking the PR 👍
I will look into applying the changes you'd like to see. They should all be possible.

@AmruthPillai Hi Amruth, I've now applied the changes you suggested. I hope that the birthday cake icon looks fine in the templates and not too "unprofessional"?  While modifying the Celebi template, I changed it from using the ContactE block to using the ContactC block. As a result of this change, the ContactE block is not used any longer and has been deleted. Hope this is fine for you.

I always appreciate people who keep their code clean 🧹
Thank you for the contribution, will merge it as soon as I'm done testing.

Hi, is this already deployed?

@marinang Hi, yes I believe this has been deployed with version 2.3


Fix: Configure Cloud-Init Script to execute automatically

What this PR does / why we need it:
This PR will fix a tiny bug. After provisioning the baremetal server successfully, the generated cloud-init script require manual interaction to execute correctly
Which issue(s) this PR fixes:

Fixes #
What type of PR is this?

/kind bug
Special notes for your reviewer:
Does this PR introduce a user-facing change? Then add your Release Note here:

NONE

Documentation:

NONE

/assign


extconf: clean up pkg config logic

What problem is this PR intended to solve?
Part of continuing work to simplify extconf.rb
Have you included adequate test coverage?
Test coverage of extconf.rb is still inadequate in my mind, but this doesn't make the problem worse, and in fact adds two flags to test variations of pkg-config.
Does this change affect the C or the Java implementations?
Only the compilation/installation of C extensions. No functional change outside that.

:white_check_mark: Build nokogiri 1.0.766 completed (commit https://github.com/sparklemotion/nokogiri/commit/86601f323a by @flavorjones)

:white_check_mark: Build nokogiri 1.0.770 completed (commit https://github.com/sparklemotion/nokogiri/commit/8c2958b37a by @flavorjones)

:x: Build nokogiri 1.0.777 failed (commit https://github.com/sparklemotion/nokogiri/commit/4ee4078cb5 by @flavorjones)

:white_check_mark: Build nokogiri 1.0.781 completed (commit https://github.com/sparklemotion/nokogiri/commit/6a9ae8c826 by @flavorjones)


Diagnostic API

Diagnostic REST API provides profiling data via pprof, cluster and worker logs, cluster and controller statuses and configuration.

Coverage decreased (-0.6%) to 8.584% when pulling 82d5583809fabbfae5ef0fab4d6b127e643c1e80 on diagnostic-api into 9c7492f38c5e647a5d01ffbe76b4da5047beacb9 on master.

👍

👍

Coverage decreased (-0.6%) to 8.584% when pulling 228639b8391b24227945600a51aadea8be36f9f8 on diagnostic-api into 9c7492f38c5e647a5d01ffbe76b4da5047beacb9 on master.

Coverage decreased (-0.2%) to 9.038% when pulling 38e0ffecf7fd4822ed951a3b4a328a353c1d2755 on diagnostic-api into 9c7492f38c5e647a5d01ffbe76b4da5047beacb9 on master.

👍

👍


Adding file for new High School entry

The school to be added is "Colegio San Ignacio de Loyola", which is located in San Juan, Puerto Rico (U.S. territory). domain name for the official email addreses: @sanignacio.pr

Excellent. Thank!
[cid:9a1161b0-ccbb-4dd6-961d-050d8583f561]
Reynaldo Belfort, S.J.
Profesor de Tecnologías Digitales
Colegio San Ignacio de Loyola
1940 Calle Saúco · Urb. Santa María · San Juan · PR @.,-66.0870064,17z/data=!4m5!3m4!1s0x0:0xc61977667631ea0c!8m2!3d18.3767263!4d-66.0868923>
787.765.3814, Ex. 304 | @. | www.sanignacio.prhttp://www.sanignacio.pr/
Síguenos en:
[cid:d6484c91-1a8f-45f6-8beb-7190d02a5984]https://www.facebook.com/ColegioSanIgnacioPR[cid:dc93da94-3208-48cf-bf28-8d5aef6200af]https://www.instagram.com/colegiosanignaciopr/[cid:9c9a7c39-54d6-4d88-9323-fe4179617a72]https://www.linkedin.com/school/colegiosanignaciopr/[cid:05238537-2f56-4684-b9cf-ca4a3089a9ca]https://twitter.com/colsanignaciopr[cid:78d92584-0908-413e-b2fb-b27d1ecd4805]https://www.youtube.com/c/ColegioSanIgnaciodeLoyolaSanJuan

From: Philip Torchinsky @.>
Sent: Monday, August 19, 2024 2:40 AM
To: JetBrains/swot @.>
Cc: Reynaldo Belfort Pierrilus @.>; Mention @.>
Subject: Re: [JetBrains/swot] Adding file for new High School entry (PR #22670)
@rbelfortcsihttps://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3A%2F%2Fgithub.com%2Frbelfortcsi&umid=8009652a-ed0b-4c92-8371-915e1da48f82&auth=c417ffc75d5966fc36bee9ada6dcb48a27c445ce-edf423cd867597ceb5058b8434dcd15fb1adf279 Thank you for your patience while waiting for a review and processing your request. Pull request merged.
Please start requesting the licenses in about an hour, to let the changes to propagate through our system.
—
Reply to this email directly, view it on GitHubhttps://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3A%2F%2Fgithub.com%2FJetBrains%2Fswot%2Fpull%2F22670%23issuecomment-2295778652&umid=8009652a-ed0b-4c92-8371-915e1da48f82&auth=c417ffc75d5966fc36bee9ada6dcb48a27c445ce-6b629239b042721bfd958a50903ebaf660628d7e, or unsubscribehttps://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FBH5PM3PEHUCENG7GZW5TYXDZSGHNNAVCNFSM6AAAAABMUG354SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVG43TQNRVGI&umid=8009652a-ed0b-4c92-8371-915e1da48f82&auth=c417ffc75d5966fc36bee9ada6dcb48a27c445ce-20f5b96f911c7040f0ad64d4e69ca0664501d3f8.
You are receiving this because you were mentioned.Message ID: @.***>


A question regarding the flow++ structure

Hi chrischute:
Very good implementation work!
One question is for the flow++ structure. In the official implementation, their is a "SpaceToDepth" operation between the CheckboardSplit block and the ChannelSplit block. (https://github.com/aravindsrinivas/flowpp/blob/master/flows/run_cifar.py line 67). However, I didn't find this operation in your implementation. Do you merge this operation to any other blocks? Or you choose to not use it? (If so, any reasons for not using this operation?)

After carefully read the code, I find the operation in the squeeze function. Sorry for disturbing you.


fix: user input malformed bug in config flow

Proposed change

Fix the user input malformed bug in config flow
Type of change

[ ] Dependency upgrade
[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests
[ ] Documentation update
[ ] Adds a new shipper
[ ] Update existing shipper

Additional information

This PR is related to issue: n/a

Codecov Report

Merging #495 (17fd86e) into dev (16a33ab) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##              dev     #495   +/-   ##
=======================================
  Coverage   99.06%   99.06%
=======================================
  Files           6        6
  Lines        1287     1287
=======================================
  Hits         1275     1275
  Misses         12       12

Impacted Files
Coverage Δ

custom_components/mail_and_packages/config_flow.py
100.00% <100.00%> (ø)


Require profiler stack sampling period to be configurable

Yeah, #157 dropped an expected bomb on this. Going to recreate.


ATOMS3 LITE

Hello,
I am looking to use ATOMS3 LITE which are ESP32 S3.
after looking at this project https://github.com/gekkekoe/esphome-ecodan-hp/ which is made for MHI ecodan heat pump
Do you know what I need to adapt ?
I don't know about the pin
#define SCK_PIN  18
#define MOSI_PIN 23
#define MISO_PIN 19
For the moment I have :
13:11:40	[W]	[mhi_ac_ctrl:143]     mhi_ac_ctrl_core.loop error: -3
13:11:40	[W]	[component:237]	Component  took a long time for an operation (102 ms).
13:11:40	[W]	[component:238]	Components should block for at most 30 ms.

@Marc911H what are you trying to do? The Ecodan seems to be a whole different product line. That's not going to work with this project.


unfork specs2

the reason we'd forked had to do with scalamock but we've addressed
the issue there instead
fixes #157

test run: https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/753/consoleFull

argh we need to fork lift-json to depend on "specs2-core" instead of "specs2". well, better to have forked lift-json than forked specs2.

new test run: https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/755/consoleFull (404 til Jenkins catches up)

(the spire change is unrelated, but it was getting in my way when trying to test this)


How To Interfaces Requests To Server

It is not implemented right now, but I'll add server requests for SAMP and GTA:V soon.

@GimmickPlus I'm sorry for the long anser.


Fix CircleCI config

Re-add workspace attachment removed by #4132.
Signed-off-by: Ben Kochie<EMAIL_ADDRESS>

/cc @simonpasquier
It looks like we dropped the attach_workspace in the release workflow.  We need the binaries produced by the build step for promu crossbuild tarballs to work.

:+1: thanks for fixing it!

Ugh, our make test is getting too big for our CI providers.


Use without Express (microservice)

I am trying to create an auth microservice that connects the marketing site with the app I am building. Currently, the example included in this repo requires Express to be used but I'm just using micro. So far I have the marketing site querying my microservice and looking up the user's info.
I'd love to have some input on how I could integrate Passwordless into my microservice but in the event I don't, I'll just come back here with my solution for future searchers. Once I went Passwordless, I couldn't go back.
EDIT: #66 seems close to my issue, hooray!

I am currently getting (node:4141) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 57): The "url" argument must be of type string. Received type undefined with the below code:
MongoStore.prototype.storeOrUpdate(token, userID, 3600000, domain, function (err) {
  if (err) log(`Error saving/updating TokenStore: ${err}`);
});

I have no idea why because domain IS a string. I'm pretty sure I'm matching what's in the passwordless-mongostore code here.

@florianheinemann Is there something obvious I'm missing here?

I figured out how to use jsonwebtoken, bcrypt, and other things to create my own passwordless system. The hardest part was figuring out how to save to a session.


future is only supported by android64 gcc 4.9

Unfortunately, Android32 gcc 4.9 does not support future.
This is required to upgrade android32 gcc4.8 to gcc 4.9.

:+1:

This logic is a bit different from what we have in platform. Ideally the limitation will get fixed on Android 32-bit with gcc 5, yet the logic here would continue using boost/future for all 32-bit Android.
However, I haven't confirmed that it'll get fixed, and up until recently thought the same about gcc 4.9. It's also likely that we'll switch over to the clang ndk rather than gcc 5, so we can deal with that when the time comes.

Agree. In fact, I wasn't sure that gcc 5.0 on android 32bit will includes future. I will keep it in mind to fix this when the time comes.


Do not Send Organization Rejection Email

Describe the problem
When rejecting an organization, an email automatically goes out. However, the vast majority of rejections are due to duplication, so the emails are confusing to the users.
Describe the solution
Don't send rejection emails any more when the admin rejects an organization. Or at least allow the admin to choose whether to send an email, and add a personal note, in addition to choosing the reason for rejecting the organization.
Additional context and instructions
Add any other context or screenshots about the feature request here.

Disabling the email was a one line change, so done that.
Modify this issue to

allow the admin to choose whether to send an email, and add a personal note, in addition to choosing the reason for rejecting the organization.

at a lower priority?

@wodow Yes, that would be great. And it would also be great to allow the admin to add a personal note, like "I'm rejecting this registration, but it's only because you registered the same organization 15 times."


Readonly properties

Hi,
Firstly, thanks for your hard work!
I have just switched to v5.2.1 and previous readonly properties are no longer being generated with the "readonly" attribute. So somethign like:
public string Code { get; }
get generated to (using C# AutoRest):
public string Code { get; set; }
Previously this was only happenin on enums, but is now happening on everything, including value types. Is this a bug or by design?
Thanks in advance.

Do you know which serializer, Newtonsoft or System.Text.Json (STJ), is in use by your application? The readonly flag is derived according to "serializer behavior". STJ requires properties to have public setters for de-serialization. Newtonsoft on the other hand, does support de-serialization of payload values into properties with no public setter, provided the declaring type has a constructor with a parameter of the same name.
So, if you're using Newtonsoft AND your DTOs have constructors for setting the properties, then the readonly flag WILL NOT be set, and this is by design. Could this be the case?
If this is not the case, then it could be a bug and I would suggest creating a minimal sample app that repro's the issue, and posting to github where I can pull down and repro myself.

Thanks for the quick reply!
We are using Newtonsoft and our DTOs do indeed have constructors for setting these properties. This was already the case previously and in v4.0.1 at least it was creating readonly fields, but I see your point so this almost certainly isn't a bug.
Thanks again.

No problem. Given that you're using Newtonsoft AND you have the constructors, then I imagine your API will in fact accept those values in the payload. Therefore, readOnly = false seems like the correct outcome.

Thanks again @domaindrivendev


feat: switch eu-de-1 to PER category

Description
switch eu-de-1 to PER category.
:warning:  :warning:   :warning:
If solution was deployed using previous versions in powervs zone eu-de-1, please do not update to this version. Upgrading to this version for eu-de-1 powervs zone will corrupt your landscape. Use this solution for new deployments in eu-de-1 region. if deployed in other powervs_zone it can be upgraded without any issue.
Release required?

[ ] No release
[ ] Patch release (x.x.X)
[x] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline


don't delete existing third party plugins

I'm using https://github.com/Slava/tern-meteor by dropping in meteor.js into ~/.atom/packages/atom-ternjs/node_modules/tern/plugin/ but every time atom-ternjs gets an update, the external plugin file gets deleted and I get to place it there once more.
Is it possible you replace only internal plugins and not touch the third party ones on update?
Or rather than copying over 3rd party plugins, there may perhaps be a setting somewhere  we can add outside locations for atom-tern to look for existince of them.

I think this is related to atom itself.
Every time the package is updated, atom cleans the directory and performs a fresh apm install for the package. I don' think there is any way to keep old files in that directory. But that's just speculation from my site :D
But i will have a look definitely. :)
thx
tststs

Hmm, then,  do you think it is possible to:

Or rather than copying over 3rd party plugins, there may perhaps be a setting somewhere we can add outside locations for atom-tern to look for existince of them.

I think this issue is also discussed in #79


Bug 2015548: fix paging items in to use list options passed by the paging function

The client-go pager sets the Limit options for the list call
to paginate the request[1]. This PR fixes the paging function
to use the options passed by the pager instead of shadowed options
This is required for the pagination to work correctly.
Signed-off-by: Alay Patel<EMAIL_ADDRESS>Thank you for contributing to Velero!
Please add a summary of your change
Does your change fix a particular issue?
Fixes #(issue)
Please indicate you've done the following:

[ ] Accepted the DCO. Commits without the DCO will delay acceptance.
[ ] Created a changelog file or added /kind changelog-not-required.
[ ] Updated the corresponding documentation in site/content/docs/main.

Verified the fix. Deployed konveyor-1.7.0 and I see all backup queries are paged now.
["2021-11-08T19:01:19.160896Z","system:serviceaccount:velero:velero-backup-dev-rcdn-01-server","/api/v1/secrets?limit=500"]
["2021-11-08T19:01:20.162586Z","system:serviceaccount:velero:velero-backup-dev-rcdn-01-server","/api/v1/secrets?continue=eyJ2IjoibWV0YS5rOHMuaW8vdjEiLCJydiI6MTI0MjA0NTc2LCJzdGFydCI6ImZlbGl4LXRlc3Rpbmc0MS1wcm9qZWN0LWludGVybmFsLWludmFsaWQtY2x1c3Rlci1pbmZvL2RlcGxveWVyLXRva2VuLXFnOXhtXHUwMDAwIn0&limit=500"]


Discussion on the diff generator

In order to generate the difference between two JSON data, either we can use an existing library or implement our own JSON diffing library, but before we make that decision, I think it's important that we look at some great existing JSON diffing libraries.
If none of them work according to our needs, then can look into implementing our own.
After looking at some most popular as well as some most suitable libraries, I came up with these diffing libraries:

https://github.com/flitbit/diff (deep-diff)
https://github.com/andreyvit/json-diff (diff)
https://github.com/benjamine/jsondiffpatch (jsondiffpatch)
https://github.com/chbrown/rfc6902 (rfc6902)
https://github.com/kpdecker/jsdiff (diff)

After having tried them all, the most suitable library to me was: deep-diff
Reason:

No external dependencies, thus not having to worry about frequently updating the library.
Suitable diff output, this included the type of change, what's the current values, what was the previous one, and the path where the change has been made.

But before we agree on this, we have to make sure that this library is really suitable for us in terms of performance, the output, etc.
Therefore, this issue has been made in order to start a discussion on it. Also, whether we should really go with a ready-made library or make our own.
CC @vinitshahdeo

I'm always saying don't reinvent the wheel unless over time you see the wheel you are using is not playing its role and its owner doesn't want your help to improve it 😄  (actually it is a first time are articulated it this way 😄 )
So yeah, first use what others spent hours on, and then over time if we see too many limitations we can think of some custom solution.

No external dependencies, thus not having to worry about frequently updating the library.

not a problem from my point of view because we have updating of libraries automated, not a big deal. More important is to make sure the library also can work in a browser so we can integrate it in the future not only in the CLI but also in the UI
I think that while choosing the best library you will face the challenge of "performance vs output quality". The question is - how much is performance really important for us? I think more important is reliable output. So from my perspective, https://github.com/chbrown/rfc6902 looks interesting as it is compliant with standards and looks like actively developed as was released this year.
Just grab this largest AsyncAPI file I've ever seen and see how these diff libraries perform with it.

don't reinvent the wheel unless over time you see the wheel you are using is not playing its role and its owner doesn't want your help to improve it

This just became one of my favorite quotes of all time.

I think more important is reliable output.

You pretty much nailed the point. Right now, instead of worrying about picking up a suitable diffing library, we(@vinitshahdeo, @onbit-syn and I) took a step back, and started thinking about what will the output of our library. We are brainstorming the idea, and will come up something that can be considered suitable, extensible and future-proof.(Will be making an issue about it after some time).

So from my perspective, https://github.com/chbrown/rfc6902 looks interesting as it is compliant with standards and looks like actively developed as was released this year.

I will definitely consider this point :)

As I see in the Readme of the mentioned tools, they return the path of change and information about the kind of change. Based also on this comment I have an idea to use the XPath or JSONPath and mapping for breaking, non-breaking changes to have relationship between changes and our diff standard.
For example, if someone remove the protocol from one of servers, then from diff tool we should have output that /servers/{serverName}/protocol has changed and based on mapping between our spec and breaking and non-breaking changes, we can extend output that for /servers/{serverName}/protocol is a breaking change or not. Mapping can looks like:
/servers/{serverName}/protocol: {
  'add': 'breaking',
  'remove': 'breaking',
  'update': 'breaking',
}

but for example, if someone add new server, then we can have mapping:
/servers/{serverName}: {
  'add': 'non-breaking',
  'remove': 'breaking',
  'update': 'breaking',
}

etc.
I think that by the mapping our diff tool can be spec-agnostic and easy to extend for the next version of asyncapi. What do you think?

@magicmatatjahu I had some thoughts about how to map our standard into a JSON file, and I came up with something similar.
For example, taking the protocol, we can have
{
  "server" : {
    "protocol" : {
       "add": "non-breaking",
       "remove": "breaking",
       "update": "breaking"
     }
  }
}

But I like your approach better because you have basically flattened the nesting, which would be faster + easier to find, and having JSONpath is certainly a plus point. I will look into how we can implement it(like bypassing the {serverName} and stuff). :+1:
Thanks :)

We can also use the normal JSON as in your suggestion - we should choose which is better and easier to maintanance :)

I think that no matter what format you choose, it is a good decision to have this mapping approach, for first version any decision will be good imho


Cannot use cltorch

I'm trying to using the OpenCL back-end because I have an ATI card and not an nVidia, but I keep getting the following:
donald@alfheim:~/torch-rnn$ th train.lua -input_h5 shake.h5 -input_json shake.json -model_type rnn -num_layers 3 -gpu_backend opencl
libthclnn_searchpath    /home/donald/distro-cl/install/lib/lua/5.1/libTHCLNN.so
/home/donald/distro-cl/install/bin/luajit: C++ exception

I have correctly installed distro-cl, though.

My specific video card did not support OpenCL. I tried on another machine, and everything is working as expected.


[NCL-8342] Update GH workflow dependencies

actions/setup-node@v3 is updated in separated PR https://github.com/project-ncl/pnc-js-libs/pull/34


Treat pointer cancel events similarly to pointer up events

@Hixie

Test please.

Added a test of the gesturer binding.  PTAL.

Test looks great, thanks!


Issue 48 delete dashboard

Tipo da mudança

[ ] Deleta dashboard
[ ] botao de deletar no observatory detail:

Pull Request Test Coverage Report for Build 129

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build 125:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls


Update package.json and readme.md to release 1.0.2

package.json version is currently 1.0.0 this updates both package.json and readme.md to 1.0.2.

Hey, sorry to leave this hanging. There's an imminent release of mithril with types included, at which point I was going to merge the 'class-fact' branch into master with an updated package version which should be in sync with mithril.js 1.0.2 going forward.

The latest has updated the version numbers.


!!DO NOT MERGE!! 02865531_patch

DON'T MERGE THIS
Just for testing purposes

@samugi Can we close this PR or do you still need it?

@samugi Can we close this PR or do you still need it?

I'm closing it, thanks for the reminder @davidor


Update lewis profile and add M&C 2023 publications

While updating my personal profile, I realized that we should add the recent publications from M&C 2023 to the Conference Papers webpage.
Both @ngranda and I have entries to add, but I wasn't able to figure out where in this repo we add the data for our papers. @gonuke could you please let me know the proper way to add our publications?
Closes #217.

Converting to draft due to the open questions.

Papers get added to Zotero and then magic happens - the workflow automatically queries Zotero for data.

Specifically, add things to "CNERG/CNERG Publications/Refereed Publications" and mark it as type "Conference Paper"

I've added my paper to CNERG/CNERG Publications/Refereed Publications. Can someone who's local jekyll is working test this bulid? This PR will be ready to merge when
PR completion checklist

[ ] Website updates look good
[ ] Lewis MC Paper added to publications
[ ] Nancy MC paper added to publications

I don't think a local build pulls the website update, but you can probably trigger the GitHub action to do so

It requires a private key that I have registered with GH but isn't available to the average local build

I just launched it - it should be updated in a few min or less

Looks like it worked for Lewis' paper.  I'll check this PR with a local build next

LGTM - merging now.


US456084 Make Size property nullable

A developer build has not yet been created for this branch. Click here to go ahead and create the build...

CI Build Link:
http://sou-jenkins2.swinfra.net:8080/job/FileAnalysisSuite/job/FileAnalysisSuite~adaptersdk-convenience~US456084FileSize~CI


Resizing the safari window beyond some size pulls in the wallpaper

As title says, if I resize Safari (only at the initial page), beyond some size the wallpaper is bleeding through instead of it being the default Safari app. I don't think this is the behavior on MacOS but maybe it has changed in the more recent release in which case please ignore.

Chrome on Linux

Sorry. I thought I attached the screenshot last time.

The issue disappears once I navigate somewhere.

[](url)

Hi @vlovich, I think I know where the problem lies, it occurs when the height of the window is very large. I couldn't reproduce it before since my screen is small. Now the problem should be fixed, could you have a look? Thanks!


fix(e2e): re-enable ica unordered channel upgrade

Description

closes: #5644
Commit Message / Changelog Entry
type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against the correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

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

Comparison is base (310a4bd) 81.49% compared to head (68fd350) 81.51%.
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5756      +/-   ##
==========================================
+ Coverage   81.49%   81.51%   +0.02%
==========================================
  Files         199      199
  Lines       15203    15225      +22
==========================================
+ Hits        12389    12411      +22
  Misses       2348     2348
  Partials      466      466

Files
Coverage Δ

modules/core/04-channel/keeper/keeper.go
90.84% <100.00%> (+0.06%)
:arrow_up:

modules/core/04-channel/keeper/upgrade.go
92.52% <100.00%> (+0.21%)
:arrow_up: