[1.0] [TC-OPCREDS-3.2] Fail to verify the value of NOC and ICAC are same in step 22 and 4

Reproduction steps
Prerequisite:
1. There are two TH, one is TH1, another is TH2.
2. One DUT.
Step:
1.Use TH1 to commission DUT:
  $ ./chip-tool pairing ble-wifi 0x2 wifi 12345678 20202021 3840 --trace_decode 1 > th-1.log
  After finished commission, use follow command to open commissioning window:
  $ ./chip-tool  pairing open-commissioning-window 2 1 400 2000 3840
  Save the Manual pairing code: [35170644493]
2. Use TH2 to commission DUT:
  $ ./chip-tool pairing code 3<PHONE_NUMBER>3  --trace_decode 1  > th-2.log
3. We found that :The DUT is commissioned successfully and can be controlled onoff. But there are no messages about 'InvokeRequestMessage ', So we can't get Verify the NOC and ICAC value during commissioning
 in TH2 Log.
The TH2 log is as below
[1665561605.746139][17384:17389] CHIP:CTL: Sending root certificate to the device
[1665561605.746210][17384:17389] CHIP:DMG: ICR moving to [AddingComm]
[1665561605.746237][17384:17389] CHIP:DMG: ICR moving to [AddedComma]
[1665561605.746630][17384:17389] CHIP:IN: Prepared secure message 0xffffa4012538 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 28398i with MessageCounter:174566278.
[1665561605.746670][17384:17389] CHIP:IN: Sending encrypted msg 0xffffa4012538 with MessageCounter:174566278 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>FAD1A1 msec
[1665561605.747022][17384:17389] CHIP:DMG: ICR moving to [CommandSen]
[1665561605.747059][17384:17389] CHIP:CTL: Sent root certificate to the device
[1665561605.747416][17384:17389] CHIP:DMG: ICR moving to [AwaitingDe]
[1665561605.747454][17384:17389] CHIP:EM: Sending Standalone Ack for MessageCounter:111034323 on exchange 28397i
[1665561605.747652][17384:17389] CHIP:DMG: >> to UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 174566279 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 28685 / Exchange = 28397]
[1665561605.747684][17384:17389] CHIP:DMG: Header Flags =
[1665561605.747703][17384:17389] CHIP:DMG: {
[1665561605.747732][17384:17389] CHIP:DMG:     Exchange (0x03) =
[1665561605.747750][17384:17389] CHIP:DMG:     {
[1665561605.747766][17384:17389] CHIP:DMG:         Initiator = true
[1665561605.747785][17384:17389] CHIP:DMG:         AckMsg = 111034323
[1665561605.747803][17384:17389] CHIP:DMG:     }
[1665561605.747827][17384:17389] CHIP:DMG: }
[1665561605.747844][17384:17389] CHIP:DMG:
[1665561605.747901][17384:17389] CHIP:DMG: Error: ../../examples/common/tracing/decoder/secure_channel/Decoder.cpp:159: CHIP Error 0x00000003: Incorrect state
0 0xffffb6fdc12a, tag[Anonymous]: 0xffffffff, type: Signed Fixed Point (0x00), value: 13
0 0xffffb6fdc130, tag[Common Profile (4 Bytes)]: 0x0::0x0::0x67ab8600, type: Data (0x10), length: 10, value: 0xffffb6fdc130

[1665561605.747971][17384:17389] CHIP:IN: Prepared secure message 0xffffb6fdd978 to 0xFFFFFFFB00000000 (0)  of type 0x10 and protocolId (0, 0) on exchange 28397i with MessageCounter:174566279.
[1665561605.748004][17384:17389] CHIP:IN: Sending encrypted msg 0xffffb6fdd978 with MessageCounter:174566279 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>FAD1A3 msec
[1665561605.748228][17384:17389] CHIP:EM: Flushed pending ack for MessageCounter:111034323 on exchange 28397i
[1665561605.853785][17384:17389] CHIP:EM: Received message of type 0x10 with protocolId (0, 0) and MessageCounter:111034324 on exchange 28398i
[1665561605.853887][17384:17389] CHIP:EM: Found matching exchange: 28398i, Delegate: 0xffffa4009668
[1665561605.853967][17384:17389] CHIP:EM: Rxd Ack; Removing MessageCounter:174566278 from Retrans Table on exchange 28398i
[1665561605.854025][17384:17389] CHIP:EM: Removed CHIP MessageCounter:174566278 from RetransTable on exchange 28398i
[1665561607.147099][17384:17389] CHIP:DMG: << from UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 111034324 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 57570 / Exchange = 28398]
[1665561607.147245][17384:17389] CHIP:DMG: Header Flags =
[1665561607.147302][17384:17389] CHIP:DMG: {
[1665561607.147388][17384:17389] CHIP:DMG:     Exchange (0x02) =
[1665561607.147443][17384:17389] CHIP:DMG:     {
[1665561607.147586][17384:17389] CHIP:DMG:         AckMsg = 174566278
[1665561607.147641][17384:17389] CHIP:DMG:     }
[1665561607.147713][17384:17389] CHIP:DMG: }
[1665561607.147767][17384:17389] CHIP:DMG:
[1665561607.147833][17384:17389] CHIP:DMG: Encrypted Payload (67 bytes) =
[1665561607.147886][17384:17389] CHIP:DMG: {
[1665561607.147937][17384:17389] CHIP:DMG:     data = 00e2e000d53f9e06eac0864022a557a198ed1a6f44d08876df9944fae2e63c088973ff8681dc7b72c28b9ba4ca3e918ad1226eff6431e1eb68c422f1235f8f4eabf6bb
[1665561607.147989][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>65296
[1665561607.148039][17384:17389] CHIP:DMG: }
[1665561607.148088][17384:17389] CHIP:DMG:
[1665561607.148176][17384:17389] CHIP:DMG: Additional Fields =
[1665561607.148231][17384:17389] CHIP:DMG: {
[1665561607.148288][17384:17389] CHIP:DMG:     peer_address = UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540
[1665561607.148342][17384:17389] CHIP:DMG: }
[1665561607.148392][17384:17389] CHIP:DMG:
[1665561607.149112][17384:17389] CHIP:EM: Received message of type 0x9 with protocolId (0, 1) and MessageCounter:111034325 on exchange 28398i
[1665561607.149199][17384:17389] CHIP:EM: Found matching exchange: 28398i, Delegate: 0xffffa4009668
[1665561607.149262][17384:17389] CHIP:EM: CHIP MessageCounter:174566278 not in RetransTable on exchange 28398i
[1665561607.149347][17384:17389] CHIP:DMG: ICR moving to [ResponseRe]
[1665561607.149453][17384:17389] CHIP:DMG: InvokeResponseMessage =
[1665561607.149512][17384:17389] CHIP:DMG: {
[1665561607.149570][17384:17389] CHIP:DMG: 	suppressResponse = false,
[1665561607.149621][17384:17389] CHIP:DMG: 	InvokeResponseIBs =
[1665561607.149689][17384:17389] CHIP:DMG: 	[
[1665561607.149742][17384:17389] CHIP:DMG: 		InvokeResponseIB =
[1665561607.149810][17384:17389] CHIP:DMG: 		{
[1665561607.149863][17384:17389] CHIP:DMG: 			CommandStatusIB =
[1665561607.149920][17384:17389] CHIP:DMG: 			{
[1665561607.149973][17384:17389] CHIP:DMG: 				CommandPathIB =
[1665561607.150028][17384:17389] CHIP:DMG: 				{
[1665561607.150086][17384:17389] CHIP:DMG: 					EndpointId = 0x0,
[1665561607.150144][17384:17389] CHIP:DMG: 					ClusterId = 0x3e,
[1665561607.150200][17384:17389] CHIP:DMG: 					CommandId = 0xb,
[1665561607.150251][17384:17389] CHIP:DMG: 				},
[1665561607.150316][17384:17389] CHIP:DMG:
[1665561607.150370][17384:17389] CHIP:DMG: 				StatusIB =
[1665561607.150426][17384:17389] CHIP:DMG: 				{
[1665561607.150484][17384:17389] CHIP:DMG: 					status = 0x00 (SUCCESS),
[1665561607.150536][17384:17389] CHIP:DMG: 				},
[1665561607.150592][17384:17389] CHIP:DMG:
[1665561607.150644][17384:17389] CHIP:DMG: 			},
[1665561607.150707][17384:17389] CHIP:DMG:
[1665561607.150758][17384:17389] CHIP:DMG: 		},
[1665561607.150821][17384:17389] CHIP:DMG:
[1665561607.150873][17384:17389] CHIP:DMG: 	],
[1665561607.150938][17384:17389] CHIP:DMG:
[1665561607.150993][17384:17389] CHIP:DMG: 	InteractionModelRevision = 1
[1665561607.151042][17384:17389] CHIP:DMG: },
[1665561607.151174][17384:17389] CHIP:DMG: Received Command Response Status for Endpoint=0 Cluster=0x0000_003E Command=0x0000_000B Status=0x0
[1665561607.151236][17384:17389] CHIP:CTL: Device confirmed that it has received the root certificate
[1665561607.151298][17384:17389] CHIP:CTL: Successfully finished commissioning step 'SendTrustedRootCert'
[1665561607.151350][17384:17389] CHIP:CTL: Commissioning stage next step: 'SendTrustedRootCert' -> 'SendNOC'
[1665561607.151409][17384:17389] CHIP:CTL: Performing next commissioning step 'SendNOC'
[1665561607.151545][17384:17389] CHIP:DMG: ICR moving to [AddingComm]
[1665561607.151626][17384:17389] CHIP:DMG: ICR moving to [AddedComma]
[1665561607.152553][17384:17389] CHIP:IN: Prepared secure message 0xffffa4010928 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 28399i with MessageCounter:174566280.
[1665561607.152648][17384:17389] CHIP:IN: Sending encrypted msg 0xffffa4010928 with MessageCounter:174566280 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>FAD71F msec
[1665561607.153532][17384:17389] CHIP:DMG: ICR moving to [CommandSen]
[1665561607.153632][17384:17389] CHIP:CTL: Sent operational certificate to the device
[1665561607.153734][17384:17389] CHIP:DMG: ICR moving to [AwaitingDe]
[1665561607.153803][17384:17389] CHIP:EM: Sending Standalone Ack for MessageCounter:111034325 on exchange 28398i
[1665561607.154281][17384:17389] CHIP:DMG: >> to UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 174566281 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 28685 / Exchange = 28398]
[1665561607.154368][17384:17389] CHIP:DMG: Header Flags =
[1665561607.154424][17384:17389] CHIP:DMG: {
[1665561607.154507][17384:17389] CHIP:DMG:     Exchange (0x03) =
[1665561607.154563][17384:17389] CHIP:DMG:     {
[1665561607.154611][17384:17389] CHIP:DMG:         Initiator = true
[1665561607.154667][17384:17389] CHIP:DMG:         AckMsg = 111034325
[1665561607.154719][17384:17389] CHIP:DMG:     }
[1665561607.154788][17384:17389] CHIP:DMG: }
[1665561607.154841][17384:17389] CHIP:DMG:
[1665561607.155065][17384:17389] CHIP:DMG: Error: ../../examples/common/tracing/decoder/secure_channel/Decoder.cpp:159: CHIP Error 0x00000003: Incorrect state
0 0xffffb6fdc12a, tag[Anonymous]: 0xffffffff, type: Signed Fixed Point (0x00), value: 13
0 0xffffb6fdc130, tag[Common Profile (4 Bytes)]: 0x0::0x0::0x67ab8800, type: Data (0x10), length: 10, value: 0xffffb6fdc130

0 0xffffb6fdc149, tag[Fully Qualified (6 Bytes)]: 0x6610::0x9a93::0x247, type: Signed Fixed Point (0x00), value:<PHONE_NUMBER>335706245
[1665561607.155244][17384:17389] CHIP:IN: Prepared secure message 0xffffb6fdd978 to 0xFFFFFFFB00000000 (0)  of type 0x10 and protocolId (0, 0) on exchange 28398i with MessageCounter:174566281.
[1665561607.155327][17384:17389] CHIP:IN: Sending encrypted msg 0xffffb6fdd978 with MessageCounter:174566281 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>FAD722 msec
[1665561607.155785][17384:17389] CHIP:EM: Flushed pending ack for MessageCounter:111034325 on exchange 28398i
[1665561607.299788][17384:17389] CHIP:EM: Received message of type 0x10 with protocolId (0, 0) and MessageCounter:111034326 on exchange 28399i
[1665561607.300010][17384:17389] CHIP:EM: Found matching exchange: 28399i, Delegate: 0xffffa403c3b8
[1665561607.300098][17384:17389] CHIP:EM: Rxd Ack; Removing MessageCounter:174566280 from Retrans Table on exchange 28399i
[1665561607.300157][17384:17389] CHIP:EM: Removed CHIP MessageCounter:174566280 from RetransTable on exchange 28399i
[1665561610.346265][17384:17389] CHIP:DMG: << from UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 111034326 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 57570 / Exchange = 28399]
[1665561610.346419][17384:17389] CHIP:DMG: Header Flags =
[1665561610.346477][17384:17389] CHIP:DMG: {
[1665561610.346564][17384:17389] CHIP:DMG:     Exchange (0x02) =
[1665561610.346619][17384:17389] CHIP:DMG:     {
[1665561610.346677][17384:17389] CHIP:DMG:         AckMsg = 174566280
[1665561610.346730][17384:17389] CHIP:DMG:     }
[1665561610.346800][17384:17389] CHIP:DMG: }
[1665561610.346853][17384:17389] CHIP:DMG:
[1665561610.346918][17384:17389] CHIP:DMG: Encrypted Payload (70 bytes) =
[1665561610.346971][17384:17389] CHIP:DMG: {
[1665561610.347023][17384:17389] CHIP:DMG:     data = 00e2e000d73f9e06a861669d082c12ea9d7b11da9ded5c69d7f68e340c1a2aae5e1674d356087f4fa30913e57743b173073519593a70619d2b427ade773d1b822b1a03cb3a70
[1665561610.347075][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>74544
[1665561610.347125][17384:17389] CHIP:DMG: }
[1665561610.347174][17384:17389] CHIP:DMG:
[1665561610.347262][17384:17389] CHIP:DMG: Additional Fields =
[1665561610.347317][17384:17389] CHIP:DMG: {
[1665561610.347375][17384:17389] CHIP:DMG:     peer_address = UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540
[1665561610.347431][17384:17389] CHIP:DMG: }
[1665561610.347482][17384:17389] CHIP:DMG:
[1665561610.348123][17384:17389] CHIP:EM: Received message of type 0x9 with protocolId (0, 1) and MessageCounter:111034327 on exchange 28399i
[1665561610.348278][17384:17389] CHIP:EM: Found matching exchange: 28399i, Delegate: 0xffffa403c3b8
[1665561610.348341][17384:17389] CHIP:EM: CHIP MessageCounter:174566280 not in RetransTable on exchange 28399i
[1665561610.348427][17384:17389] CHIP:DMG: ICR moving to [ResponseRe]
[1665561610.348532][17384:17389] CHIP:DMG: InvokeResponseMessage =
[1665561610.348592][17384:17389] CHIP:DMG: {
[1665561610.348650][17384:17389] CHIP:DMG: 	suppressResponse = false,
[1665561610.348776][17384:17389] CHIP:DMG: 	InvokeResponseIBs =
[1665561610.348866][17384:17389] CHIP:DMG: 	[
[1665561610.348920][17384:17389] CHIP:DMG: 		InvokeResponseIB =
[1665561610.348989][17384:17389] CHIP:DMG: 		{
[1665561610.349042][17384:17389] CHIP:DMG: 			CommandDataIB =
[1665561610.349098][17384:17389] CHIP:DMG: 			{
[1665561610.349151][17384:17389] CHIP:DMG: 				CommandPathIB =
[1665561610.349209][17384:17389] CHIP:DMG: 				{
[1665561610.349268][17384:17389] CHIP:DMG: 					EndpointId = 0x0,
[1665561610.349325][17384:17389] CHIP:DMG: 					ClusterId = 0x3e,
[1665561610.349381][17384:17389] CHIP:DMG: 					CommandId = 0x8,
[1665561610.349432][17384:17389] CHIP:DMG: 				},
[1665561610.349492][17384:17389] CHIP:DMG:
[1665561610.349546][17384:17389] CHIP:DMG: 				CommandFields =
[1665561610.349601][17384:17389] CHIP:DMG: 				{
[1665561610.349661][17384:17389] CHIP:DMG: 					0x0 = 0,
[1665561610.349719][17384:17389] CHIP:DMG: 					0x1 = 2,
[1665561610.349775][17384:17389] CHIP:DMG: 				},
[1665561610.349826][17384:17389] CHIP:DMG: 			},
[1665561610.349890][17384:17389] CHIP:DMG:
[1665561610.349941][17384:17389] CHIP:DMG: 		},
[1665561610.350006][17384:17389] CHIP:DMG:
[1665561610.350056][17384:17389] CHIP:DMG: 	],
[1665561610.350123][17384:17389] CHIP:DMG:
[1665561610.350177][17384:17389] CHIP:DMG: 	InteractionModelRevision = 1
[1665561610.350227][17384:17389] CHIP:DMG: },
[1665561610.350365][17384:17389] CHIP:DMG: Received Command Response Data, Endpoint=0 Cluster=0x0000_003E Command=0x0000_0008
[1665561610.350447][17384:17389] CHIP:CTL: Device returned status 0 on receiving the NOC
[1665561610.350502][17384:17389] CHIP:CTL: Operational credentials provisioned on device 0xffffa400b9b0
[1665561610.350552][17384:17389] CHIP:TOO: Secure Pairing Success
[1665561610.350599][17384:17389] CHIP:TOO: CASE establishment successful
[1665561610.350657][17384:17389] CHIP:CTL: Successfully finished commissioning step 'SendNOC'
[1665561610.350712][17384:17389] CHIP:CTL: Commissioning stage next step: 'SendNOC' -> 'FindOperational'
[1665561610.350773][17384:17389] CHIP:CTL: Performing next commissioning step 'FindOperational'
[1665561610.350826][17384:17389] CHIP:CSM: FindOrEstablishSession: PeerId = [1:0000000000000003]
[1665561610.350879][17384:17389] CHIP:CSM: FindOrEstablishSession: No existing OperationalSessionSetup instance found
[1665561610.350947][17384:17389] CHIP:CTL: OperationalSessionSetup[1:0000000000000003]: State change 1 --> 2
[1665561610.351010][17384:17389] CHIP:DIS: Resolving AA32FAFC936BEE87:0000000000000003 ...
[1665561610.353255][17384:17389] CHIP:DMG: ICR moving to [AwaitingDe]
[1665561610.353377][17384:17389] CHIP:EM: Sending Standalone Ack for MessageCounter:111034327 on exchange 28399i
[1665561610.354106][17384:17389] CHIP:IN: Prepared secure message 0xffffb6fdd978 to 0xFFFFFFFB00000000 (0)  of type 0x10 and protocolId (0, 0) on exchange 28399i with MessageCounter:174566282.
[1665561610.354204][17384:17389] CHIP:IN: Sending encrypted msg 0xffffb6fdd978 with MessageCounter:174566282 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>FAE3A1 msec
[1665561610.354803][17384:17389] CHIP:EM: Flushed pending ack for MessageCounter:111034327 on exchange 28399i
[1665561610.355280][17384:17389] CHIP:DL: Avahi resolve found
[1665561610.355399][17384:17389] CHIP:DIS: Node ID resolved for AA32FAFC936BEE87:0000000000000003
[1665561610.355459][17384:17389] CHIP:DIS: 	Hostname: AC93C4C15CAE
[1665561610.355517][17384:17389] CHIP:DIS: 	IP Address #1: fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae
[1665561610.355567][17384:17389] CHIP:DIS: 	Port: 5540
[1665561610.355701][17384:17389] CHIP:DIS: 	Mrp Interval idle: 5000 ms
[1665561610.355753][17384:17389] CHIP:DIS: 	Mrp Interval active: 300 ms
[1665561610.355800][17384:17389] CHIP:DIS: 	TCP Supported: 1
[1665561610.357580][17384:17389] CHIP:DIS: Lookup clearing interface for non LL address
[1665561610.357665][17384:17389] CHIP:DIS: UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540: new best score: 6
[1665561610.357719][17384:17389] CHIP:DIS: Checking node lookup status after 7 ms
[1665561610.357769][17384:17389] CHIP:DIS: Keeping DNSSD lookup active
[1665561610.551079][17384:17389] CHIP:DIS: Checking node lookup status after 200 ms
[1665561610.551206][17384:17389] CHIP:DIS: OperationalSessionSetup[1:0000000000000003]: Updating device address to UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae]:5540 while in state 2
[1665561610.551261][17384:17389] CHIP:CTL: OperationalSessionSetup[1:0000000000000003]: State change 2 --> 3
[1665561610.551461][17384:17389] CHIP:IN: SecureSession[0xffffa400ff70]: Allocated Type:2 LSID:57571
[1665561610.551547][17384:17389] CHIP:SC: Initiating session on local FabricIndex 1 from 0x000000000001B669 -> 0x0000000000000003
[1665561610.553210][17384:17389] CHIP:SC: Including MRP parameters
[1665561610.554012][17384:17389] CHIP:DMG: >> to UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 187492484 | [Secure Channel  (0) / Certificate Authenticated Session Establishment Sigma '1' (0x30) / Session = 0 / Exchange = 28400]
[1665561610.554108][17384:17389] CHIP:DMG: Header Flags =
[1665561610.554164][17384:17389] CHIP:DMG: {
[1665561610.554235][17384:17389] CHIP:DMG:     Message (0x04) =
[1665561610.554290][17384:17389] CHIP:DMG:     {
[1665561610.554347][17384:17389] CHIP:DMG:         SourceNodeId = FC1E90BCCFA36223
[1665561610.554400][17384:17389] CHIP:DMG:     }
[1665561610.554473][17384:17389] CHIP:DMG:     Exchange (0x05) =
[1665561610.554527][17384:17389] CHIP:DMG:     {
[1665561610.554575][17384:17389] CHIP:DMG:         Initiator = true
[1665561610.554626][17384:17389] CHIP:DMG:         NeedsAck = true
[1665561610.554677][17384:17389] CHIP:DMG:     }
[1665561610.554745][17384:17389] CHIP:DMG: }
[1665561610.554798][17384:17389] CHIP:DMG:
[1665561610.554864][17384:17389] CHIP:DMG: Encrypted Payload (155 bytes) =
[1665561610.554918][17384:17389] CHIP:DMG: {
[1665561610.554969][17384:17389] CHIP:DMG:     data = 153001207a9e5388e802db31a7541a9881c637f248f2214a968e9e3acf529c455f7b83b52502e3e030032027dbc6afaf59172722afc208a89c8456b8de941d2117d3017682e818ee4c3f0f30044104b3b502fb78b183a8bb760f5506c6eb5703b9ed8884e28d53d06aaa59e7c10a40c67cea59ba0c469dd3f99f095d290392de36a4509d6fbb1605915b766e3fd44b35052501881325022c011818
[1665561610.555021][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>74544
[1665561610.555072][17384:17389] CHIP:DMG: }
[1665561610.555121][17384:17389] CHIP:DMG:
[1665561610.555228][17384:17389] CHIP:DMG: Error: ../../src/lib/core/CHIPTLVReader.cpp:543: CHIP Error 0x00000026: Wrong TLV type
0 0xffffb6fdc4ea, tag[Anonymous]: 0xffffffff, type: Signed Fixed Point (0x00), value: 13
0 0xffffb6fdc4f0, tag[Common Profile (4 Bytes)]: 0x0::0x0::0x67ab8a00, type: Data (0x10), length: 10, value: 0xffffb6fdc4f0

[1665561610.555345][17384:17389] CHIP:IN: Prepared unauthenticated message 0xffffa4012508 to 0x0000000000000000 (0)  of type 0x30 and protocolId (0, 0) on exchange 28400i with MessageCounter:187492484.
[1665561610.555430][17384:17389] CHIP:IN: Sending unauthenticated msg 0xffffa4012508 with MessageCounter:187492484 to 0x0000000000000000 at monotonic time:<PHONE_NUMBER>FAE46A msec
[1665561610.555929][17384:17389] CHIP:SC: Sent Sigma1 msg
[1665561610.556000][17384:17389] CHIP:CTL: OperationalSessionSetup[1:0000000000000003]: State change 3 --> 4
[1665561610.640336][17384:17389] CHIP:EM: Received message of type 0x10 with protocolId (0, 0) and MessageCounter:137549918 on exchange 28400i
[1665561610.640432][17384:17389] CHIP:EM: Found matching exchange: 28400i, Delegate: 0xffffa400d668
[1665561610.640501][17384:17389] CHIP:EM: Rxd Ack; Removing MessageCounter:187492484 from Retrans Table on exchange 28400i
[1665561610.640619][17384:17389] CHIP:EM: Removed CHIP MessageCounter:187492484 from RetransTable on exchange 28400i
[1665561612.513928][17384:17389] CHIP:DMG: << from UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 137549918 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 0 / Exchange = 28400]
[1665561612.514260][17384:17389] CHIP:DMG: Header Flags =
[1665561612.514324][17384:17389] CHIP:DMG: {
[1665561612.514400][17384:17389] CHIP:DMG:     Message (0x01) =
[1665561612.514457][17384:17389] CHIP:DMG:     {
[1665561612.514515][17384:17389] CHIP:DMG:         DestinationNodeId = FC1E90BCCFA36223
[1665561612.514568][17384:17389] CHIP:DMG:     }
[1665561612.514640][17384:17389] CHIP:DMG:     Exchange (0x02) =
[1665561612.514694][17384:17389] CHIP:DMG:     {
[1665561612.514751][17384:17389] CHIP:DMG:         AckMsg = 187492484
[1665561612.514803][17384:17389] CHIP:DMG:     }
[1665561612.514873][17384:17389] CHIP:DMG: }
[1665561612.514927][17384:17389] CHIP:DMG:
[1665561612.515000][17384:17389] CHIP:DMG: Encrypted Payload (732 bytes) =
[1665561612.515054][17384:17389] CHIP:DMG: {
[1665561612.515107][17384:17389] CHIP:DMG:     data = 010000005fd832082362a3cfbc901efc0631f06e000084e82c0b153001203ada8346f0ab8acecd88bc8cccbd6b5422a04deec89e2f295816bdd25a3d423e25020b7030034104d0f057f2ca714f11d947a87fc596b4ca1322c8c2c17eb5da61bac62285931b0df130742bf44f80c7cedd8cffabc17a526dd53c9eb1df281b9a88481519578f0531044602a783dfc5a84221b898eb1d4ce0708f3adb2009fb783212924afe71df265eb3d67ef0b65b83685238f4495d1515fa678104c94a397006e20829e20943b2122f9da7ce96c10cc09a5d45aa8a80de61f6ff72db66a5a6cef032f909d9c9bfdae8e996cea5c6e3ef1ee39c25477bf627ddd6118c7981300e0313ab9ea1d8dc2df930f8fcd1113bd1eaadd297759e4a19a3fc7b1ce253e68870fc664f265358dd9ebbe063c2c68d76f95b7f6ae89b9b577c898ce3c25a3ccd1f8f9b45b512569964e0e208246f3ec98a6a5051ed71afa167b5736551a7e80562f0f68f70613ae41fbca9f3e0cc428472fbfe943d15704b018071bba3cb08d73524d19092db3793d83f34fc1a30badb2e2538fe311375566457704ffbafa3b6e51e2ba4ae7d54c885cdecfe8a2bdc24b865ff081642a41c9c8446c6306ccbdcb0c318a2cc9800d1aff8516d0bfe718d5d97e62b708c898e47f9a3a1556be13d24aca4a7b6a47797db58ab3f8e395ae0a73d9cf8bd6c41e95990dc7f75e5add89247fdceccdc498daaa1d17a7a25990572eec6e4c830a4cd2949e47123c83410542fdc944bbbdc34407476e6652feeb3cd00457e60d5f6579889d999060ceb8127bbacd287a847717b69737a81baa9ec44b9ba49834b3dd71ea5cc4bd4ce3f4e894da712352b0d90e35da7e07ecd7b47fce41cfaa44f048c4242e1c1b0390ba9eb317a2beda0c1bceba24467fce1e5d177abc507c306f0fb52f124e49e4cf443fd09dcca7bd32f023df345b881c26757628e1f11f55328fe6e2538b01cf96279c2bd64c717aa53cdddf6808ab058261a35052501881325022c011818
[1665561612.515161][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>57232
[1665561612.515211][17384:17389] CHIP:DMG: }
[1665561612.515260][17384:17389] CHIP:DMG:
[1665561612.515350][17384:17389] CHIP:DMG: Additional Fields =
[1665561612.515407][17384:17389] CHIP:DMG: {
[1665561612.515464][17384:17389] CHIP:DMG:     peer_address = UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540
[1665561612.515520][17384:17389] CHIP:DMG: }
[1665561612.515570][17384:17389] CHIP:DMG:
[1665561612.516357][17384:17389] CHIP:EM: Received message of type 0x31 with protocolId (0, 0) and MessageCounter:137549919 on exchange 28400i
[1665561612.516435][17384:17389] CHIP:EM: Found matching exchange: 28400i, Delegate: 0xffffa400d668
[1665561612.516496][17384:17389] CHIP:EM: CHIP MessageCounter:187492484 not in RetransTable on exchange 28400i
[1665561612.516589][17384:17389] CHIP:SC: Received Sigma2 msg
[1665561612.516667][17384:17389] CHIP:SC: Peer assigned session session ID 28683
[1665561612.526733][17384:17389] CHIP:SC: Found MRP parameters in the message
[1665561612.526875][17384:17389] CHIP:SC: Sending Sigma3
[1665561612.527619][17384:17389] CHIP:EM: Piggybacking Ack for MessageCounter:137549919 on exchange: 28400i
[1665561612.527970][17384:17389] CHIP:IN: Prepared unauthenticated message 0xffffa403ea28 to 0x0000000000000000 (0)  of type 0x32 and protocolId (0, 0) on exchange 28400i with MessageCounter:187492485.
[1665561612.528009][17384:17389] CHIP:IN: Sending unauthenticated msg 0xffffa403ea28 with MessageCounter:187492485 to 0x0000000000000000 at monotonic time:<PHONE_NUMBER>FAEC1F msec
[1665561612.528420][17384:17389] CHIP:SC: Sent Sigma3 msg
[1665561612.677238][17384:17389] CHIP:EM: Received message of type 0x10 with protocolId (0, 0) and MessageCounter:137549920 on exchange 28400i
[1665561612.677332][17384:17389] CHIP:EM: Found matching exchange: 28400i, Delegate: 0xffffa400d668
[1665561612.677411][17384:17389] CHIP:EM: Rxd Ack; Removing MessageCounter:187492485 from Retrans Table on exchange 28400i
[1665561612.677469][17384:17389] CHIP:EM: Removed CHIP MessageCounter:187492485 from RetransTable on exchange 28400i
[1665561616.577075][17384:17389] CHIP:DMG: << from UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 137549920 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 0 / Exchange = 28400]
[1665561616.577233][17384:17389] CHIP:DMG: Header Flags =
[1665561616.577290][17384:17389] CHIP:DMG: {
[1665561616.577365][17384:17389] CHIP:DMG:     Message (0x01) =
[1665561616.577420][17384:17389] CHIP:DMG:     {
[1665561616.577479][17384:17389] CHIP:DMG:         DestinationNodeId = FC1E90BCCFA36223
[1665561616.577532][17384:17389] CHIP:DMG:     }
[1665561616.577606][17384:17389] CHIP:DMG:     Exchange (0x02) =
[1665561616.577660][17384:17389] CHIP:DMG:     {
[1665561616.577717][17384:17389] CHIP:DMG:         AckMsg = 187492485
[1665561616.577770][17384:17389] CHIP:DMG:     }
[1665561616.577841][17384:17389] CHIP:DMG: }
[1665561616.577895][17384:17389] CHIP:DMG:
[1665561616.577961][17384:17389] CHIP:DMG: Encrypted Payload (34 bytes) =
[1665561616.578014][17384:17389] CHIP:DMG: {
[1665561616.578066][17384:17389] CHIP:DMG:     data =<PHONE_NUMBER>d832082362a3cfbc901efc0640f06e000085e82c0b0000000000000000
[1665561616.578119][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>55360
[1665561616.578169][17384:17389] CHIP:DMG: }
[1665561616.578219][17384:17389] CHIP:DMG:
[1665561616.578308][17384:17389] CHIP:DMG: Additional Fields =
[1665561616.578366][17384:17389] CHIP:DMG: {
[1665561616.578425][17384:17389] CHIP:DMG:     peer_address = UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540
[1665561616.578480][17384:17389] CHIP:DMG: }
[1665561616.578530][17384:17389] CHIP:DMG:
[1665561616.579121][17384:17389] CHIP:EM: Received message of type 0x40 with protocolId (0, 0) and MessageCounter:137549921 on exchange 28400i
[1665561616.579195][17384:17389] CHIP:EM: Found matching exchange: 28400i, Delegate: 0xffffa400d668
[1665561616.579256][17384:17389] CHIP:EM: CHIP MessageCounter:187492485 not in RetransTable on exchange 28400i
[1665561616.579351][17384:17389] CHIP:SC: Success status report received. Session was established
[1665561616.585606][17384:17389] CHIP:SC: SecureSession[0xffffa400ff70]: Moving from state 'kEstablishing' --> 'kActive'
[1665561616.585714][17384:17389] CHIP:IN: SecureSession[0xffffa400ff70]: Activated - Type:2 LSID:57571
[1665561616.585769][17384:17389] CHIP:IN: New secure session activated for device <0000000000000003, 1>, LSID:57571 PSID:28683!
[1665561616.585831][17384:17389] CHIP:CTL: OperationalSessionSetup[1:0000000000000003]: State change 4 --> 5
[1665561616.585955][17384:17389] CHIP:CTL: Successfully finished commissioning step 'FindOperational'
[1665561616.586016][17384:17389] CHIP:CTL: Commissioning stage next step: 'FindOperational' -> 'SendComplete'
[1665561616.586078][17384:17389] CHIP:CTL: Performing next commissioning step 'SendComplete'
[1665561616.586206][17384:17389] CHIP:DMG: ICR moving to [AddingComm]
[1665561616.586275][17384:17389] CHIP:DMG: ICR moving to [AddedComma]
[1665561616.587044][17384:17389] CHIP:IN: Prepared secure message 0xffffa4008b68 to 0x0000000000000003 (1)  of type 0x8 and protocolId (0, 1) on exchange 28401i with MessageCounter:151075039.
[1665561616.587143][17384:17389] CHIP:IN: Sending encrypted msg 0xffffa4008b68 with MessageCounter:151075039 to 0x0000000000000003 (1) at monotonic time:<PHONE_NUMBER>FAFBFA msec
[1665561616.587800][17384:17389] CHIP:DMG: ICR moving to [CommandSen]
[1665561616.587987][17384:17389] CHIP:EM: Sending Standalone Ack for MessageCounter:137549921 on exchange 28400i
[1665561616.588503][17384:17389] CHIP:DMG: >> to UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 187492486 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 0 / Exchange = 28400]
[1665561616.588592][17384:17389] CHIP:DMG: Header Flags =
[1665561616.588647][17384:17389] CHIP:DMG: {
[1665561616.588764][17384:17389] CHIP:DMG:     Message (0x04) =
[1665561616.588832][17384:17389] CHIP:DMG:     {
[1665561616.588891][17384:17389] CHIP:DMG:         SourceNodeId = FC1E90BCCFA36223
[1665561616.588944][17384:17389] CHIP:DMG:     }
[1665561616.589018][17384:17389] CHIP:DMG:     Exchange (0x03) =
[1665561616.589072][17384:17389] CHIP:DMG:     {
[1665561616.589120][17384:17389] CHIP:DMG:         Initiator = true
[1665561616.589176][17384:17389] CHIP:DMG:         AckMsg = 137549921
[1665561616.589229][17384:17389] CHIP:DMG:     }
[1665561616.589298][17384:17389] CHIP:DMG: }
[1665561616.589352][17384:17389] CHIP:DMG:
[1665561616.589462][17384:17389] CHIP:DMG: Error: ../../examples/common/tracing/decoder/secure_channel/Decoder.cpp:159: CHIP Error 0x00000003: Incorrect state
0 0xffffb6fdc11a, tag[Anonymous]: 0xffffffff, type: Signed Fixed Point (0x00), value: 11
0 0xffffb6fdc120, tag[Common Profile (4 Bytes)]: 0x0::0x0::0x138df00, type: Data (0x10), length: 9, value: 0xffffb6fdc120

[1665561616.589586][17384:17389] CHIP:IN: Prepared unauthenticated message 0xffffb6fdd968 to 0x0000000000000000 (0)  of type 0x10 and protocolId (0, 0) on exchange 28400i with MessageCounter:187492486.
[1665561616.589670][17384:17389] CHIP:IN: Sending unauthenticated msg 0xffffb6fdd968 with MessageCounter:187492486 to 0x0000000000000000 at monotonic time:<PHONE_NUMBER>FAFBFC msec
[1665561616.590165][17384:17389] CHIP:EM: Flushed pending ack for MessageCounter:137549921 on exchange 28400i
[1665561616.952936][17384:17389] CHIP:EM: Retransmitting MessageCounter:151075039 on exchange 28401i Send Cnt 1
[1665561616.953098][17384:17389] CHIP:IN: Sending encrypted msg 0xffffa4008b68 with MessageCounter:151075039 to 0x0000000000000003 (1) at monotonic time:<PHONE_NUMBER>FAFD68 msec
[1665561616.953723][17384:17389] CHIP:CSM: UpdatePeerAddress: No existing OperationalSessionSetup instance found
[1665561616.953802][17384:17389] CHIP:CTL: OperationalSessionSetup[1:0000000000000003]: State change 1 --> 2
[1665561616.953868][17384:17389] CHIP:DIS: Resolving AA32FAFC936BEE87:0000000000000003 ...
[1665561616.957814][17384:17389] CHIP:DL: Avahi resolve found
[1665561616.957974][17384:17389] CHIP:DIS: Node ID resolved for AA32FAFC936BEE87:0000000000000003
[1665561616.958036][17384:17389] CHIP:DIS: 	Hostname: AC93C4C15CAE
[1665561616.958095][17384:17389] CHIP:DIS: 	IP Address #1: fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae
[1665561616.958144][17384:17389] CHIP:DIS: 	Port: 5540
[1665561616.958193][17384:17389] CHIP:DIS: 	Mrp Interval idle: 5000 ms
[1665561616.958240][17384:17389] CHIP:DIS: 	Mrp Interval active: 300 ms
[1665561616.958287][17384:17389] CHIP:DIS: 	TCP Supported: 1
[1665561616.959811][17384:17389] CHIP:DIS: Lookup clearing interface for non LL address
[1665561616.959878][17384:17389] CHIP:DIS: UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%wlan0]:5540: new best score: 6
[1665561616.959932][17384:17389] CHIP:DIS: Checking node lookup status after 6 ms
[1665561616.959984][17384:17389] CHIP:DIS: Keeping DNSSD lookup active
[1665561617.152342][17384:17389] CHIP:DMG: << from UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 183576057 | [Interaction Model  (1) / InvokeCommandResponse (0x09) / Session = 57571 / Exchange = 28401]
[1665561617.152488][17384:17389] CHIP:DMG: Header Flags =
[1665561617.152549][17384:17389] CHIP:DMG: {
[1665561617.152635][17384:17389] CHIP:DMG:     Exchange (0x06) =
[1665561617.152690][17384:17389] CHIP:DMG:     {
[1665561617.152838][17384:17389] CHIP:DMG:         AckMsg = 151075039
[1665561617.152892][17384:17389] CHIP:DMG:         NeedsAck = true
[1665561617.152943][17384:17389] CHIP:DMG:     }
[1665561617.153015][17384:17389] CHIP:DMG: }
[1665561617.153147][17384:17389] CHIP:DMG:
[1665561617.153218][17384:17389] CHIP:DMG: Encrypted Payload (70 bytes) =
[1665561617.153270][17384:17389] CHIP:DMG: {
[1665561617.153323][17384:17389] CHIP:DMG:     data = 00e3e000f925f10a1abcd2b3fbce4a0dffa7f35f3a50d4d77defbe83d9f1ede26ab600b1889f8013e61c6992a7017c1a0c334833ec6d65dc0eb7f1d037cd085ec69bd5e528ec
[1665561617.153375][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>86320
[1665561617.153425][17384:17389] CHIP:DMG: }
[1665561617.153474][17384:17389] CHIP:DMG:
[1665561617.153613][17384:17389] CHIP:DMG:
[1665561617.153696][17384:17389] CHIP:DMG: Additional Fields =
[1665561617.153754][17384:17389] CHIP:DMG: {
[1665561617.153813][17384:17389] CHIP:DMG:     peer_address = UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540
[1665561617.153869][17384:17389] CHIP:DMG: }
[1665561617.153919][17384:17389] CHIP:DMG:
[1665561617.153983][17384:17389] CHIP:EM: Received message of type 0x9 with protocolId (0, 1) and MessageCounter:183576057 on exchange 28401i
[1665561617.154043][17384:17389] CHIP:EM: Found matching exchange: 28401i, Delegate: 0xffffa4009668
[1665561617.154126][17384:17389] CHIP:EM: Rxd Ack; Removing MessageCounter:151075039 from Retrans Table on exchange 28401i
[1665561617.154184][17384:17389] CHIP:EM: Removed CHIP MessageCounter:151075039 from RetransTable on exchange 28401i
[1665561617.154260][17384:17389] CHIP:DMG: ICR moving to [ResponseRe]
[1665561617.154354][17384:17389] CHIP:DMG: InvokeResponseMessage =
[1665561617.154413][17384:17389] CHIP:DMG: {
[1665561617.154471][17384:17389] CHIP:DMG: 	suppressResponse = false,
[1665561617.154522][17384:17389] CHIP:DMG: 	InvokeResponseIBs =
[1665561617.154591][17384:17389] CHIP:DMG: 	[
[1665561617.154644][17384:17389] CHIP:DMG: 		InvokeResponseIB =
[1665561617.154714][17384:17389] CHIP:DMG: 		{
[1665561617.154768][17384:17389] CHIP:DMG: 			CommandDataIB =
[1665561617.154825][17384:17389] CHIP:DMG: 			{
[1665561617.154878][17384:17389] CHIP:DMG: 				CommandPathIB =
[1665561617.154934][17384:17389] CHIP:DMG: 				{
[1665561617.154992][17384:17389] CHIP:DMG: 					EndpointId = 0x0,
[1665561617.155050][17384:17389] CHIP:DMG: 					ClusterId = 0x30,
[1665561617.155105][17384:17389] CHIP:DMG: 					CommandId = 0x5,
[1665561617.155156][17384:17389] CHIP:DMG: 				},
[1665561617.155215][17384:17389] CHIP:DMG:
[1665561617.155269][17384:17389] CHIP:DMG: 				CommandFields =
[1665561617.155325][17384:17389] CHIP:DMG: 				{
[1665561617.155385][17384:17389] CHIP:DMG: 					0x0 = 0,
[1665561617.155446][17384:17389] CHIP:DMG: 					0x1 = "" (0 chars),
[1665561617.155502][17384:17389] CHIP:DMG: 				},
[1665561617.155553][17384:17389] CHIP:DMG: 			},
[1665561617.155616][17384:17389] CHIP:DMG:
[1665561617.155668][17384:17389] CHIP:DMG: 		},
[1665561617.155733][17384:17389] CHIP:DMG:
[1665561617.155784][17384:17389] CHIP:DMG: 	],
[1665561617.155851][17384:17389] CHIP:DMG:
[1665561617.155905][17384:17389] CHIP:DMG: 	InteractionModelRevision = 1
[1665561617.155955][17384:17389] CHIP:DMG: },
[1665561617.156094][17384:17389] CHIP:DMG: Received Command Response Data, Endpoint=0 Cluster=0x0000_0030 Command=0x0000_0005
[1665561617.156172][17384:17389] CHIP:CTL: Received CommissioningComplete response, errorCode=0
[1665561617.156239][17384:17389] CHIP:CTL: Successfully finished commissioning step 'SendComplete'
[1665561617.156291][17384:17389] CHIP:CTL: Commissioning stage next step: 'SendComplete' -> 'Cleanup'
[1665561617.156352][17384:17389] CHIP:CTL: Performing next commissioning step 'Cleanup'
[1665561617.156467][17384:17389] CHIP:CTL: Successfully finished commissioning step 'Cleanup'
[1665561617.156535][17384:17389] CHIP:TOO: Device commissioning completed with success
[1665561617.156681][17384:17389] CHIP:DMG: ICR moving to [AwaitingDe]
[1665561617.156803][17384:17389] CHIP:EM: Sending Standalone Ack for MessageCounter:183576057 on exchange 28401i
[1665561617.157240][17384:17389] CHIP:IN: Prepared secure message 0xffffb6fdd978 to 0x0000000000000003 (1)  of type 0x10 and protocolId (0, 0) on exchange 28401i with MessageCounter:151075040.
[1665561617.157392][17384:17389] CHIP:IN: Sending encrypted msg 0xffffb6fdd978 with MessageCounter:151075040 to 0x0000000000000003 (1) at monotonic time:<PHONE_NUMBER>FAFE34 msec
[1665561617.158011][17384:17389] CHIP:DMG: >> to UDP:[fd5b:35de:ad5b:beef:ae93:c4ff:fec1:5cae%eth0]:5540 | 151075040 | [Secure Channel  (0) / Standalone Ack (0x10) / Session = 28683 / Exchange = 28401]
[1665561617.158102][17384:17389] CHIP:DMG: Header Flags =
[1665561617.158158][17384:17389] CHIP:DMG: {
[1665561617.158241][17384:17389] CHIP:DMG:     Exchange (0x03) =
[1665561617.158296][17384:17389] CHIP:DMG:     {
[1665561617.158344][17384:17389] CHIP:DMG:         Initiator = true
[1665561617.158400][17384:17389] CHIP:DMG:         AckMsg = 183576057
[1665561617.158452][17384:17389] CHIP:DMG:     }
[1665561617.158522][17384:17389] CHIP:DMG: }
[1665561617.158575][17384:17389] CHIP:DMG:
[1665561617.158640][17384:17389] CHIP:DMG: Encrypted Payload (34 bytes) =
[1665561617.158693][17384:17389] CHIP:DMG: {
[1665561617.158744][17384:17389] CHIP:DMG:     data = 000b7000e038010938ef0fe3ab8a500625dd4ae4e9bc408a59c1771cbca2ca24597c
[1665561617.158796][17384:17389] CHIP:DMG:     buffer_ptr =<PHONE_NUMBER>25456
[1665561617.158846][17384:17389] CHIP:DMG: }
[1665561617.158895][17384:17389] CHIP:DMG:
[1665561617.159159][17384:17389] CHIP:EM: Flushed pending ack for MessageCounter:183576057 on exchange 28401i
[1665561617.159580][17384:17384] CHIP:CTL: Shutting down the commissioner
[1665561617.159659][17384:17384] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1665561617.159714][17384:17384] CHIP:CTL: Shutting down the controller
[1665561617.159770][17384:17384] CHIP:DIS: OperationalSessionSetup[1:0000000000000003]: Cancelling incomplete address resolution as device is being deleted.
[1665561617.159860][17384:17384] CHIP:IN: Expiring all sessions for fabric 0x1!!
[1665561617.159917][17384:17384] CHIP:IN: SecureSession[0xffffa400ff70]: MarkForEviction Type:2 LSID:57571
[1665561617.159970][17384:17384] CHIP:SC: SecureSession[0xffffa400ff70]: Moving from state 'kActive' --> 'kPendingEviction'
[1665561617.160022][17384:17384] CHIP:IN: SecureSession[0xffffa400ff70]: Released - Type:2 LSID:57571
[1665561617.160079][17384:17384] CHIP:FP: Forgetting fabric 0x1
[1665561617.160148][17384:17384] CHIP:TS: Pending Last Known Good Time: 2022-09-26T18:46:11
[1665561617.160429][17384:17384] CHIP:TS: Previous Last Known Good Time: 2022-09-26T18:46:11
[1665561617.160489][17384:17384] CHIP:TS: Reverted Last Known Good Time to previous value
[1665561617.160573][17384:17384] CHIP:CTL: Shutting down the commissioner
[1665561617.160630][17384:17384] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1665561617.160680][17384:17384] CHIP:CTL: Shutting down the controller
[1665561617.160777][17384:17384] CHIP:CTL: Shutting down the System State, this will teardown the CHIP Stack
[1665561617.162683][17384:17384] CHIP:DMG: IM WH moving to [Uninitialized]
[1665561617.162770][17384:17384] CHIP:DMG: IM WH moving to [Uninitialized]
[1665561617.162822][17384:17384] CHIP:DMG: IM WH moving to [Uninitialized]
[1665561617.162870][17384:17384] CHIP:DMG: IM WH moving to [Uninitialized]
[1665561617.162924][17384:17384] CHIP:DMG: All ReadHandler-s are clean, clear GlobalDirtySet
[1665561617.163083][17384:17384] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.
[1665561617.163511][17384:17384] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-oa3grm)
[1665561617.164411][17384:17384] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1665561617.164476][17384:17384] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1665561617.164500][17384:17384] CHIP:DL: Inet Layer shutdown
[1665561617.164520][17384:17384] CHIP:DL: BLE shutdown
[1665561617.164540][17384:17384] CHIP:DL: System Layer shutdown
[1665561617.164622][17384:17384] CHIP:IN: SecureSession[0xaaab12defa30]: MarkForEviction Type:1 LSID:57570
[1665561617.164646][17384:17384] CHIP:SC: SecureSession[0xaaab12defa30]: Moving from state 'kActive' --> 'kPendingEviction'
[1665561617.164697][17384:17384] CHIP:IN: SecureSession[0xaaab12defa30]: Released - Type:1 LSID:57570

Bug prevalence
always
GitHub hash of the SDK that was being used
26a054c31144478e3c27391c06b0dc3230bb0882
Platform
ameba
Platform Version(s)
Realtek 8720CMF
Type
Common Cluster Logic
Anything else?
No response

The description of So we can't get Verify the NOC and ICAC value during commissioning does not seem to match with the title of `Decoder.cpp: incorrect state'.

But there are no messages about 'InvokeRequestMessage '

Those would be coming from the DUT, not the TH, so why would you expect to see them in the TH log?
The Decoder.cpp bit seems like a bug in the trace decoder or in the messages it's decoding; more details on what the actual bytes look like would be needed to tell for sure.
@mideayanghui What exactly is this issue about?  Please clearly describe:

What you expected to happen.
What happened differently from the expectation.

if I try the follow command to pair TH2 into another Fabric and test again,  Step4 of the test case also fail.
1:
.Use TH1 to commission DUT:
$ ./chip-tool pairing ble-wifi 0x2 wifi 12345678 20202021 3840 --trace_decode 1 >
th-1.log
th-1.log
th-1-window.log
2：After finished commission, use follow command to open commissioning window:
$ ./chip-tool pairing open-commissioning-window 2 1 400 2000 3840
Save the Manual pairing code: [35170644493]
th-2.log
3: Use TH2 to commission DUT:
$ ./chip-tool pairing code 3<PHONE_NUMBER>3  --commissioner-name beta --trace_decode 1 > th-2.log
th-2.log
Attach DUT's Log:
dev.log
Can you give me some suggestion?

@bzbarsky-apple @andy31415 I happened to face this same issue, it happens intermittently. NoCValue and ICACValue is expected to be logged out correctly with trace_decoder enabled, but sometimes the chiptool decoder is getting errors like incorrect state / wrong TLV type.

@andy31415 @bzbarsky-apple @step0035  Hello, I have another method to validate NOC in Step 23, Can you help me double check?
NOC Chain Verify Method-V1.1.pdf

@andy31415 @bzbarsky-apple @step0035 @mideayanghui  I fix a bug  on Chip-Tool in the trace decoder or in the messages it's decoding.
I upload a patch based on commit 87bee4de25 , I test and pass the test case, Can you help me do a double check?
0001-TraceDecoder-fix-a-bug-in-the-trace-decoder-or-in-th.zip

@liuck8 Please create a pull request with that change?  Then the folks who know the trace decoder code will see it....

@bzbarsky-apple Thanks, I have created a pull request as this link.
Beside, I upload the chip-tool based on Raspberry-Pi 4, It's can run in TH2.5.
chip-tool.tar.gz


Fix visible production environment tag

What problem does this pull request solve?
Trello card: https://trello.com/c/VeOkfpZv/1250-update-forms-runner-to-govuk-frontend-v5

In #535 we updated the tags to reflect the new tag casing rules in version 5 of govuk-frontend. Unfortunately, the 'production' text was not updated to 'Production' everywhere, so the logic for hiding the environment tag in production broke.
This PR fixes the problem, and updates the 'production' check to look at the translation directly, so that the environment check will stay up to date with any future changes to this text.
Things to consider when reviewing

Ensure that you consider the wider context.
Does it work when run on your machine?
Is it clear what the code is doing?
Do the commit messages explain why the changes were made?
Are there all the unit tests needed?
Has all relevant documentation been updated?

@chao-xian yes, we should - we do the same tag in forms-admin and possibly also in forms-product-page, I think it makes sense to do this as part of the govuk-frontend v5 update in those repos.


Error when creating an embed link

I have the following request according to the document from https://docs.microsoft.com/en-us/onedrive/developer/rest-api/api/driveitem_createlink
POST https://api.onedrive.com/v1.0/me/drive/items/{myitemid}/createLink
Authorization: bearer {token}
Content-Type: application/json
Accept: application/json
{
"type": "embed"
}
I received the below error, not sure what is wrong or missing from my request, please advice.
{
"error": {
"code": "invalidRequest",
"message": "Invalid API or resource"
}
}
Thanks,

Actually I figured it out, it needs to be https://api.onedrive.com/v1.0/drive/items/{myitemid}/oneDrive.createLink.
Thanks,


Move project dependency management from pip to pipenv

There is a lot of complexity with virtualenv, pip, requirements.txt and tox. It's better to switch to pipenv, which is the modern way to manage dependencies in python world
https://github.com/kennethreitz/pipenv

Codecov Report

Merging #146 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #146   +/-   ##
=======================================
  Coverage   62.77%   62.77%
=======================================
  Files          25       25
  Lines        1131     1131
  Branches       97       97
=======================================
  Hits          710      710
  Misses        415      415
  Partials        6        6

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fa3dd29...a4daa1b. Read the comment docs.

Pipenv now is officially recommended to use as python dependency manager
https://bryson3gps.wordpress.com/2017/11/08/stop-everything-start-using-pipenv/


Connectivity 0.4.6+2 crashes if Proguard is applied.

I'm using connectivity 0.4.6+2 listen to connectivity changes, release app crashes on wifi connection restored. Debug works well.
Crash log:
Fatal Exception: java.lang.NullPointerException: throw with null exception        at com.pubnub.api.models.server.SubscribeMetadata.getTimetoken(SubscribeMetadata.java:3)        at com.pubnub.api.managers.SubscriptionManager$5.a(SubscriptionManager.java:201)        at com.pubnub.api.managers.SubscriptionManager$5.a(SubscriptionManager.java:2)        at com.pubnub.api.endpoints.Endpoint$1.a(Endpoint.java:45)        at retrofit2.ExecutorCallAdapterFactory$ExecutorCallbackCall$1$1.run(ExecutorCallAdapterFactory.java:37)        at android.os.Handler.handleCallback(Handler.java:873)        at android.os.Handler.dispatchMessage(Handler.java:99)        at android.os.Looper.loop(Looper.java:193)        at android.app.ActivityThread.main(ActivityThread.java:6715)        at java.lang.reflect.Method.invoke(Method.java)        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:911)
Flutter version:
Flutter 1.12.13+hotfix.5 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 27321ebbad (4 weeks ago) • 2019-12-10 18:15:01 -0800
Engine • revision 2994f7e1e6
Tools • Dart 2.7.0

Hi @appstute-pratik
In your logs I see that it is an pubnub issue.
It should be fixed for master channel.
Try to update this plugin.
If the problem persists, consider to write issue to the flutter_pubnub repository.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you

Thanks


No Connection to gotify/server-arm64 Container

Describe the bug
I'm having trouble getting igotify to work with gotify/server-arm64. The igotify container isn't able to establish a connection with the gotify container using this image. On another instance running the regular gotify image, everything works fine.
Expected behavior
It would be great if arm64 support were available. Does igotify also require a separate image for that?
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Version of Container [e.g. <IP_ADDRESS>]
Version of iGotify [e.g. 1.0.5]

Additional context
Add any other context about the problem here.

Can you give me please some logs?
What version do you use?
The assistant works with arm64 because it's a multiplatform image that includes arm/arm64/amd64.
If there are some trouble with the gotify image please consider the dev of gotify, I'm only the guy who developed an bridge for iOS

Database is created: True
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://[::]:8080
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: /app
warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
Failed to determine the https port for redirect.
This is the log of the igotify container. Is the problem maybe relatet to nginx proxy manager? Because on the setup working i use the one from synology and here where this happens it ist nginx.

that's all? when not please provide the me the full log, the domain and token etc can be removed.
nothing like
Gotify - Url: http://xyz.xyz
Is Gotify - Url available: yes/no
SecNtfy Server - Url: http://xyz.xyz
Is SecNtfy Server - Url available: yes/no
Client - Token: XXXXX

did you can see the swagger api when you open you're iospush.mydomain.ch domain?
when yes please try to send a test message with the last endpoint in the list. you need the notification token starting with NTFY-DEVICE-. You will find it in the app, when you everything setuped

Sending the testmessage to the device over Swagger worked.
The Container Log says still:
Gotify Server is not available try to reconnect in 10s
It has lost the Websocket connection as i sendt the first Testnotification and connectioncan no longer be established to the gotify server from igotify container... But i can reached the server over push.mydomain.ch without a problem with a browser...

can you test if the domain is reachable from inside the iGotify Notification Container?

Yes, got it!! Sorry, you can close this issue. How could i be so dumb. It was ufw. But i was so shure that i did the disable while testing.
If any one wonders how to test if a host is reachable from inside the container, here is how to:
docker exec -ti <ContainerName> timeout 3 /bin/bash -c "echo > /dev/tcp/push.yourdomain.ch/443 >& /dev/null" && echo "ok" || echo "nok"
As soon as i disable ufw and ran the cmd above i got "ok"... Now i allowed docker networkbridge ip range to any app 'Nginx Full' and the containers can connect over the reverse proxy.

Ok
Nice, ufw I also sometimes forget 😅


Make AnnotationLiteral lazy

AnnotationLiteral eagerly initializes the reflective state of annotations. This state may not be needed if the implementation does not use reflection to access annotation literal members. This change makes this intialization lazy to avoid always initializing this state.

Looks good, WDYT @manovotn?


Slider is kept showing even after closing the filter

I am facing an issue with the slider, the 2 dots are kept showing when I closed the filter
Ex:

I'm using the last nova version: 3.17

@milewski

@milewski any updates regarding this issue?

@Algeneralo I don't have time right now to take a closer look at this issue, I think it might be solvable by triggering an input.blur() manually whenever a click outside is detected..  if you are able to submit a PR for this, would be more than happy to merge.

@milewski
I tried to, but there was an issue when I tried to compile the files again, something related to Sass loader.
Any idea?

Can you show me what's the error? perhaps you just need to remove node_modules and do npm install again?

No longer an issue on the latest version which now supports nova 4


Command Tree filtering by context does not work

GET command_tree { capture { id { data: 1abfba1bb57bc960f0b230587e126d34e9c52ae9 } } }
GET command_tree { capture { id { data: 1abfba1bb57bc960f0b230587e126d34e9c52ae9 } } context { data: d0e2d452f40db8783c4776f0d7ad6d6c20b7093c } }
Although they return two different root paths, the resulting trees still contain all commands.

Yup. There's a big fat TODO in there.

Done. See:
45cfa8668d219be8f2dfdd7fb7fabb5a4352af16
0d23a969ba9be715d570444d92f94beacaad6cf8
681b579e1f9bb88fbb289b61ef0bd95953aacda8


Ability to edit redirect_uri / redirect_url

Hi
I didn’t found any way to edit app settings from the developer.tesla.com website
I would like to add a localhost url or the default one from postman to test oauth: https://oauth.pstmn.io/v1/browser-callback

Currently no way to do so. Quickly setting up a test environment, that's an absolute show stopper.

ping @teslamotors this is an absolute show-stopper.

Friendly ping @teslamotors @tesla-sdk-publish there are already >20 upvotes. Is there any chance to get this addressed short-term? We'd need to double- and triple-register otherwise for testing and production changes would not be possible.

If it is difficult to implement an edit function, how about creating a delete function first? Currently, tesla developer console can only create two apps, so it is difficult to test them anymore.

We'll be adding the ability to edit redirect_uri, return_url, and allowed_origins in the coming weeks.  Sorry for the lame inconvenience/blocker.

We'll be adding the ability to edit redirect_uri, return_url, and allowed_origins in the coming weeks. Sorry for the lame inconvenience/blocker.

Is it also possible to allow editing scope? Users will be prompted to approve/deny the new scope.
If one forgets to add a scope a new domain needs to be acquired and registered and a new https certificate needs to be acquired and it's a huge hassle. Not to mention that users need to re-log in.
Thanks

Any timeline on this @aaronpkahn ?

It also looks like you cannot register more than 5 apps...

@grantmac yes it is. So I created an additional new account.
Sadly this is the only solution.

This appears to be possible now. I just edited the redirect URLs for an existing app.

How can I create a redirect link pls

Yup you can do it now via the UI.

Plus: you can even changes scopes now 👍🏻


Handle columns with double underscores in the name

For example 'properties__number_of_sources'.
Previously anything prefixed by 'properties__' was coalesced to 'properties'.
For example this was being generated against our events using segment -> stitch -> Redshift:
WITH final AS (

select

    coalesce(
                cast("properties__meta__content__count__string" as
  varchar
),
                cast("properties__meta__frequency__at__string" as
  varchar
),
                cast("properties__meta__frequency__between__from__string" as
  varchar
),
                cast("properties__meta__frequency__between__to__string" as
  varchar
),
                cast("properties__created__string" as
  varchar
),
                cast("properties__meta__frequency__between__from__bigint" as
  varchar
),
                cast("properties__meta__frequency__at__bigint" as
  varchar
),
                cast("properties__meta__frequency__between__to__bigint" as
  varchar
),
                case
                    when "properties__created__boolean" = true then cast('true' as
  varchar
)
                    when "properties__created__boolean" = false then cast('false' as
  varchar
)
                    else null end
                ,
                cast("properties__item__journalistic_quality__double" as
  varchar
),
                cast("properties__item__journalistic_quality__bigint" as
  varchar
),
                cast("properties__item__original_id__string" as
  varchar
),
                cast("properties__sentiment__compound__bigint" as
  varchar
),
                cast("properties__sentiment__pos__bigint" as
  varchar
),
                cast("properties__entity__sentiment__neu__bigint" as
  varchar
),
                cast("properties__entity__sentiment__pos__bigint" as
  varchar
),
                cast("properties__entity__sentiment__neg__bigint" as
  varchar
),
                cast("properties__sentiment__neu__bigint" as
  varchar
),
                cast("properties__entity__sentiment__compound__bigint" as
  varchar
),
                cast("properties__sentiment__neg__bigint" as
  varchar
),
                cast("properties__entity__sentiment__compound__double" as
  varchar
),
                cast("properties__sentiment__neu__double" as
  varchar
),
                cast("properties__entity__sentiment__pos__double" as
  varchar
),
                cast("properties__entity__sentiment__neu__double" as
  varchar
),
                cast("properties__sentiment__compound__double" as
  varchar
),
                cast("properties__sentiment__pos__double" as
  varchar
),
                cast("properties__sentiment__neg__double" as
  varchar
),
                cast("properties__entity__sentiment__neg__double" as
  varchar
),
                cast("properties__item__original_id__bigint" as
  varchar
),
                cast("properties__number_of_sources__string" as
  varchar
),
                cast("properties__number_of_sources__bigint" as
  varchar
),
                cast("properties__meta__content__count__bigint" as
  varchar
)) as "properties"

from "analytics"."migrated_app"."track"

)

SELECT * FROM final

After this change:
    coalesce(
                cast("properties__created__string" as
  varchar
),
                case
                    when "properties__created__boolean" = true then cast('true' as
  varchar
)
                    when "properties__created__boolean" = false then cast('false' as
  varchar
)
                    else null end
                ) as "properties__created",
    coalesce(
                cast("properties__entity__sentiment__compound__bigint" as
  varchar
),
                cast("properties__entity__sentiment__compound__double" as
  varchar
)) as "properties__entity__sentiment__compound",
    coalesce(
                cast("properties__entity__sentiment__neg__bigint" as
  varchar
),
                cast("properties__entity__sentiment__neg__double" as
  varchar
)) as "properties__entity__sentiment__neg",
    coalesce(
                cast("properties__entity__sentiment__neu__bigint" as
  varchar
),
                cast("properties__entity__sentiment__neu__double" as
  varchar
)) as "properties__entity__sentiment__neu",
    coalesce(
                cast("properties__entity__sentiment__pos__bigint" as
  varchar
),
                cast("properties__entity__sentiment__pos__double" as
  varchar
)) as "properties__entity__sentiment__pos",
    coalesce(
                cast("properties__item__journalistic_quality__double" as
  varchar
),
                cast("properties__item__journalistic_quality__bigint" as
  varchar
)) as "properties__item__journalistic_quality",
    coalesce(
                cast("properties__item__original_id__string" as
  varchar
),
                cast("properties__item__original_id__bigint" as
  varchar
)) as "properties__item__original_id",
    coalesce(
                cast("properties__meta__content__count__string" as
  varchar
),
                cast("properties__meta__content__count__bigint" as
  varchar
)) as "properties__meta__content__count",
    coalesce(
                cast("properties__meta__frequency__at__string" as
  varchar
),
                cast("properties__meta__frequency__at__bigint" as
  varchar
)) as "properties__meta__frequency__at",
    coalesce(
                cast("properties__meta__frequency__between__from__string" as
  varchar
),
                cast("properties__meta__frequency__between__from__bigint" as
  varchar
)) as "properties__meta__frequency__between__from",
    coalesce(
                cast("properties__meta__frequency__between__to__string" as
  varchar
),
                cast("properties__meta__frequency__between__to__bigint" as
  varchar
)) as "properties__meta__frequency__between__to",
    coalesce(
                cast("properties__number_of_sources__string" as
  varchar
),
                cast("properties__number_of_sources__bigint" as
  varchar
)) as "properties__number_of_sources",
    coalesce(
                cast("properties__sentiment__compound__bigint" as
  varchar
),
                cast("properties__sentiment__compound__double" as
  varchar
)) as "properties__sentiment__compound",
    coalesce(
                cast("properties__sentiment__neg__bigint" as
  varchar
),
                cast("properties__sentiment__neg__double" as
  varchar
)) as "properties__sentiment__neg",
    coalesce(
                cast("properties__sentiment__neu__bigint" as
  varchar
),
                cast("properties__sentiment__neu__double" as
  varchar
)) as "properties__sentiment__neu",
    coalesce(
                cast("properties__sentiment__pos__bigint" as
  varchar
),
                cast("properties__sentiment__pos__double" as
  varchar
)) as "properties__sentiment__pos"

from "analytics"."migrated_app"."track"

@Limess Looks great, thanks for updating! I'll merge this.

Thanks for the quick turnaround! Would it be possible to publish the latest release to DBT hub (https://hub.getdbt.com/fishtown-analytics/stitch_utils/latest/)?

Release 0.1.6 should be deployed on the hub site now!


theTeam.join() link

When you click theTeam.join(), it should link you to the Apply Page

Got it!


Corrections and clarifications for FILE_RENAME_INFO

Remove duplicated ReplaceIfExists field.
Since ReplaceIfExists and Flags are in a union, we need to explain when each one is used. ReplaceIfExists is used for FileRenameInfo, and Flags is used for FileRenameInfoEx.
Ideally the accepted values for Flags should be documented (they're listed in https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_rename_information), but I'm not sure which flags should be shown here or the version of windows when each flag becomes valid, so I'm not going to add that.
Clarify the usage of RootDirectory. Most users should set it to NULL. Wording is taken from https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_rename_information.
FileNameLength needs to be clearly documented as the FileName size in bytes without the NUL termination. (Technical note: at present this value is only used in some code paths. In other code paths, FileName needs to be nul-terminated.)
Clarify that FileName MUST be NUL-terminated. Some code paths use the NUL-termination and other code paths use FileNameLength, so both must be set correctly.

@idigdoug : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@idigdoug : Thanks for your contribution! The author(s) have been notified to review your proposed change.


⚠ ClamAV has degraded performance

In ade7386, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 69 ms

Resolved: ClamAV performance has improved in 90ab498.


Failed deposit of asset - missing funds - "block height >= packet timeout"

Hi guys, I don't know where to go for support so I came here
I setup Keplr wallet and received ATOM to it.
Then I logged into Osmosis with the Keplr extension, Assets > Deposit Cosmos Hub - ATOM
I could see my ATOM balance, so used MAX and even got the notifications in browser that it was succesful.
I waited 10 minutes and nothing appeared in assets - 1 hour later and still nothing.
Origin ATOM wallet :
https://atomscan.com/accounts/cosmos13cpa3h7tjceqpnuu38ts9u5l0pyf80x322lvly
Destination "Deposit Cosmos Hub - ATOM" wallet :
https://www.mintscan.io/osmosis/account/osmo13cpa3h7tjceqpnuu38ts9u5l0pyf80x3z3vufk
Here is proof of IBC Transfer success:
https://atomscan.com/transactions/91BDDCAADBAD0F8CC27695F3F29150B848050580B85AFEA16B0A75D02CD31350
And the error message of the ATOM (Osmosis) receiving wallet:
failed to execute message; message index: 1: receive packet verification failed: block height >= packet timeout height (1-134107 >= 1-134104): packet timeout

https://www.mintscan.io/osmosis/txs/C2DF94570A862ECF0F31228644347C9037C8058D3761F2FF386DBBDDD9F82873
Even though this "failed" the original ATOM was not re-deposited to the origin wallet.
I am new user - don't know who to call or what to do now but I am missing $1000 because of some packet timeout error...

@88plug you can go to discord


Make untyped fields use serde_json::Value directly

Fixes #229
This fixes fields which explicitly or implicitly specify +kubebuilder:validation:Schemaless annotation. HashMap or BTreeMap is not always expected in such case, this can be anything, thus serde_json::Value.

I think this makes sense. Looking back at historical discussions it doesn't look like we had a strong argument for why we packed it inside a map in https://github.com/kube-rs/kopium/issues/31
I am confused why this passes unit tests without changes to unit tests though.. There should be at least one here that causes this to fail? https://github.com/kube-rs/kopium/blob/main/src/analyzer.rs#L611-L649

I think the test passes correctly, because all of the fields defined there have a type: object. The field we having problem with has no type: defined at all. I’ll add a test case for this


Campaign: Pre-registration (encourage authors to complete)

Rationale
Pre-registration requires researchers to specify their planned research protocol, objectives and hypotheses, and plans for data collection and the confirmatory analysis to be conducted in order to test the stated hypotheses prior to beginning a study. This means that researchers are accountable to producing the research as intended and will help to protect against practices such as “hypothesising after results are known” or “p-hacking”, which can inflate positive results in scientific research.
Pledge
By joining this campaign, you pledge to pre-register all one of your conducted studies via one of the pre-registration formats specified by the Center for Open Science (https://help.osf.io/hc/en-us/articles/360019738834-Create-a-Preregistration#Go-to-the-OSF-Prereg-Challenge-landing-page). This does not need to be hosted on the Open Science Framework (e.g., it could be on a site like AsPredicted.org). There simply needs to be a time-stamped, publicly available document that can be verified as existing before the study was conducted.
Issues to work out (all sorted, see comments below):
1. I wrote this as all studies conducted since the pledge activates, but perhaps some buffer time is needed so that studies just about to launch at the time won't be suddenly help back by a pledge activation. Maybe a grace period for pledgers to adjust?
2. Should this focus instead on hitting a target number of pre-registered studies (instead of creating a pre-registration 'habit')? It is a smaller step, but maybe we need the smaller step to allow people to committing to pre-registering X studies in a time frame before making a larger pledge.
3. Threshold — Your pledge will activate when 100 researchers have joined the campaign. --> what is a reasonable threshold to set?
4. Duration—Your pledge will expire after 2 years, but you are encouraged to renew it! --> is expiration a good idea for this? This is also related to point (2) about whether the commitment should be all studies in the specified duration or X number of studies pre-registered in the specified duration.
5. Anonymity?—Your pledge will be public once the threshold is activated. --> does this seem reasonable?
Note: We'll be developing the campaign text using HackMD here

Thanks for posting @dlholf!

Should this focus instead on hitting a target number of pre-registered studies (instead of creating a pre-registration 'habit')? It is a smaller step, but maybe we need the smaller step to allow people to committing to pre-registering X studies in a time frame before making a larger pledge.

Have been thinking about this lately. Making it a habit would certainly be a bigger statement, but then could also turn some people off, e.g. if unsure supervisor might resist etc. The other end of the extreme could be to ask for just a single preregistration in a 2 year period? I think I lean toward this end, just because its easy and tangible for people to commit to, and doesn't stop people from doing more than that. I talked to a friend last night who said they would commit to such a pledge -- so that's a start ;)
Maybe we need to ask around a bit and see what people would be willing to commit to? Would be great if we can get a 'mini critical mass' ready to sign when it goes live, so that we can build momentum quickly -- people seem more willing to commit to a sure thing after all. I started a google doc to collect expressions of interest for the RR campaign (#8), could do something similar here once the details are clearer.

I think it may be helpful to specify the situations in which pre-registration is expected, or alternatively to specify the preregistration options for different kinds of studies. From the conversations I've been having, people are finding the push to preregister everything unrealistic because they dont realise they can preregister exploratory work.
Is the pledge aiming to have people preregister all of their work, or only their confirmatory studies?

I wondered about having different levels of this—at the basic level, go for one pre-registered study in the next two years. At the most committed, pre-register everything. And in between that, pre-register all confirmatory. It's a bit of a slow habit-building exercise I guess. I'm not sure what is the best way to present that in practice. Only put out the most basic at the start, then put in a new pledge for people to re-commit to? Or put all three and let people pick what they can commit to?
I think a good motivator would be realising after doing it that it's easy and has its rewards (for example, if reviewers are favourable about seeing a study has been pre-registered). Though this is a culture change that needs to happen, and I'd like to think would happen it is enough of a norm that we start to question why a study is not pre-registered.

I wondered about having different levels of this—at the basic level, go for one pre-registered study in the next two years. At the most committed, pre-register everything. And in between that, pre-register all confirmatory. It's a bit of a slow habit-building exercise I guess. I'm not sure what is the best way to present that in practice. Only put out the most basic at the start, then put in a new pledge for people to re-commit to? Or put all three and let people pick what they can commit to?

I'm also not sure about this, but suspect we'll have the most success by defining a single thing for people to commit to, rather than giving them multiple options. Every time we give people a decision to make, we increase the chance they bounce without making a pledge. Point in case: one person told me they still hadn't signed campaign #5 because they really wanted to think about it and get the settings right, but then never returned to make the pledge. Admittedly the OA campaigns are much more complex than what you're proposing, but I think the same principle applies -- keep it simple. To me the obvious candidate actions are: (a) preregister one study, or (b) preregister all confirmatory studies in the next X years (but we should just choose one of these options for the campaign)

Is the pledge aiming to have people preregister all of their work, or only their confirmatory studies?

Good point. If we're going with a 'blanket pledge' (option b above) we should clearly state that it only applies to confirmatory studies. If we're going with option a, then I think people can work it out for themselves which study they want to preregister.

Threshold — Your pledge will activate when 100 researchers have joined the campaign. --> what is a reasonable threshold to set?

Here I think it could be 100 people from your field (thinking of the Tier 2 from such list: https://docs.google.com/spreadsheets/d/1APu3Hi5UtexvISTGkk1D1uZK-7Efjpj9_sQBq_dH38I/edit#gid=222728450) which means you would need to ask people to pick their field from a list.

Duration—Your pledge will expire after 2 years, but you are encouraged to renew it! --> is expiration a good idea for this?
Anonymity?—Your pledge will be public once the threshold is activated. --> does this seem reasonable?

both yes

By joining this campaign, you pledge to pre-register all your conducted studies
maybe we need the smaller step to allow people to committing to pre-registering X studies in a time frame
Is the pledge aiming to have people preregister all of their work, or only their confirmatory studies?
(a) **preregister one study in the next X years **(which means we don't need to specify whether confirmatory/exploratory), or (b) preregister all confirmatory studies in the next X years

Even if I can see the value of preregistering qualitative research just for the sake of transparency and reflection of peoples positionality, for someone involved with both type of research it would primarily be important for them to preregister quantitative research and especially confirmatory one, so I would also not suggest to preregister all. And not to start polarizing people from different disciplines, I like the idea of not mentioning it like with (a) **preregister one study in the next X years **. However, I do wish people who do mostly experimental work would preregister all their experiments... so I do like (b) preregister all confirmatory studies in the next X years.... I think both could be offered, but probably the first one matters most. The first one will be most appealing to people who have never written a publication, the second will be for people who are already convinced by it and have already written one, and who will probably do this anyway??

100 people from your field is a good idea!

I think both could be offered, but probably the first one matters most. The first one will be most appealing to people who have never written a publication, the second will be for people who are already convinced by it and have already written one, and who will probably do this anyway??

I wonder if those who would probably do it anyway would still be willing to join the 'pre-register one study in the next X years' pledge as a way of showing people who are new to pre-registration that this is popular and accepted?
In which case we probably do want (a) as a simple starting point to spread the practice beyond the converted.

Duration—Your pledge will expire after 2 years, but you are encouraged to renew it! --> is expiration a good idea for this?
Anonymity?—Your pledge will be public once the threshold is activated. --> does this seem reasonable?

both yes

agreed :)

I wonder if those who would probably do it anyway would still be willing to join the 'pre-register one study in the next X years' pledge as a way of showing people who are new to pre-registration that this is popular and accepted?
In which case we probably do want (a) as a simple starting point to spread the practice beyond the converted.

This is how I feel about it. There's nothing stopping people from going the next step, and preregistering all of their studies, but if we start out by asking too much we might lose some people. I guess the alternative could be true too though -- people might look at it and ask "What's the point in pledging to preregister one study? I already do that (or I'm planning to do that anyway)". So if we go with this option, we'd have to make it clear that this campaign is just the beginning, and aims to build a supportive community with bigger goals in the future.
Alternatively, we could include an additional checkbox in the pledge, where people pledge to prereg all studies. But this would mean extra development of the platform, and also at the end of the day wouldn't mean much because we'd still just be counting the number of pledges.

100 people from your field is a good idea!

I like it too. We should be able to categorise people using their previous publications in ORCID, or alternatively could get people to fill in a dropdown box. We actually built the platform to have a dropdown box in the first place (currently hidden), so might not be too hard to re-implement. But the tricky part would be showing people how many pledges there are for each field, because the platform is only set up for a single number to be shown on each campaign page (the total number of pledges). I'm trying to minimise development work at this stage until we learn more about what features are necessary, and so was thinking it best to leave these early campaigns as either (a) field-general, or (b) pick a single field to target (and put this in the campaign description). But if you think it's an important feature, I can raise it with the platform developers to see how much work would be involved?

I think it would be nice to have the total number displayed for the pledge (across disciplines) but actually activate the pledge per discipline (with a drop down menu if this can't be done automatically with ORCID - and perhaps it is best to let people pick the field for which they want to activate their pledge for people spanning several disciplines?)

I think it would be nice to have the total number displayed for the pledge (across disciplines) but actually activate the pledge per discipline

Good to know. I was thinking that people would prefer to see how many pledges there have been in their field, but perhaps that's just me. In any case what you suggest is the easiest given the current state of the platform, so it makes sense to go with that and build in field-specific metrics down the track if/when required.

perhaps it is best to let people pick the field for which they want to activate their pledge for people spanning several disciplines

Great point. At present, the field variable is built in at the user level, rather than the campaign level, so unfortunately must be the same across all campaigns (i.e. not possible to pick psychology for one campaign and neuroscience for another). But I don't think this is a big problem for now, because we'll just be uploading one campaign at a time, and we can re-assess down the track when we get a clearer picture of who our users are and what features they want to see.

I like the idea of not mentioning it like with (a) **preregister one study in the next X years **. However, I do wish people who do mostly experimental work would preregister all their experiments... so I do like (b) preregister all confirmatory studies in the next X years.... I think both could be offered, but probably the first one matters most. The first one will be most appealing to people who have never written a publication, the second will be for people who are already convinced by it and have already written one, and who will probably do this anyway??

I might be coming back around to the idea of having different pledge 'levels', providing we do it in a way that doesn't confuse people. One thing I'm conscious of is offering people a reason to join the campaign, rather than just carry out the action by themselves (@bnosek suggested this a while back). I think a real strength of FOK is the chance to connect with a community of like-minded individuals, many of whom have experience with the behaviour in question. So this got me thinking -- what if we set the default pledge to 'preregister one study in the next X years', but give people an opportunity to 'level up' and become 'mentors' in the community? Mentors should have experience carrying out the behaviour in question (preregistration) and be available to advise newcomers if they run into troubles (or be paired with newcomers in their field?). This could be a powerful drawcard by showing people that there's a supportive community ready to help them carry out their pledged action. And since mentors should already be familiar with preregistration, we could get them to pledge to preregister all of their (confirmatory) studies rather than just one, as a sign of their commitment?
I know this goes against what I said about keeping things simple, but wondering if it might also help motivate those people who are already familiar with prereg to join our campaign, as it gives them recognition for their skills and place in the community. If it helps, we could offer them a special 'mentor badge', which recognises their contribution to the community, and extra points on the community 'leaderboard' if and when this becomes a thing :)

Following up from a chat with @CooperSmout today, here is a summary and actions we'll take to move this campaign forward:

Keep the text of the pledge simple, focusing on what and why to sign up.

A global why pledge link (or possibly later, if functionality allows) could be added so people can see why pledging is important, but this would apply to all campaigns, so the pledge text should focus on why this campaign in particular.

Start with pledging to pre-register one study in the next year (we forgot to speak about what X should be, but I think one year should be enough time to make just one pre-registration?)

Something to test could be whether positioning a pledge with gain-framed reasons (e.g., providing support for the movement) vs. loss-framed reasons (e.g., avoiding being on the 'wrong' side of research history) is better at converting interest to pledges. We'd be able to learn better from this on how to craft an effective pledge.
If the site developers can manage split testing easily, we could try presenting different versions randomly to site visitors (would this be by IP address?); an alternative is to amend the text daily to the different versions, though there are many potential confounds such as people who visit the site more than once, and the inability to effectively randomise, limiting conclusions.

To keep things simple for signing up to the pledge, we should focus just on the basic pledge, and then email pledgers offering for them to take on a mentor role and/or 'level up' their pledge to a higher commitment voluntarily as part of their pledge activation. (And we should track uptake of this!)

Actions:

I'll start drafting the pledge text to include on the website (with gain and loss versions so we can decide how we want to proceed with that)
We'll include a link to an editable pledge document at the top of this thread (thanks @CooperSmout !)

Following up from a chat with @CooperSmout today, here is a summary and actions we'll take to move this campaign forward:

Keep the text of the pledge simple, focusing on what and why to sign up.

A global why pledge link (or possibly later, if functionality allows) could be added so people can see why pledging is important, but this would apply to all campaigns, so the pledge text should focus on why this campaign in particular.

Start with pledging to pre-register one study in the next year (we forgot to speak about what X should be, but I think one year should be enough time to make just one pre-registration?)

Something to test could be whether positioning a pledge with gain-framed reasons (e.g., providing support for the movement) vs. loss-framed reasons (e.g., avoiding being on the 'wrong' side of research history) is better at converting interest to pledges. We'd be able to learn better from this on how to craft an effective pledge.
If the site developers can manage split testing easily, we could try presenting different versions randomly to site visitors (would this be by IP address?); an alternative is to amend the text daily to the different versions, though there are many potential confounds such as people who visit the site more than once, and the inability to effectively randomise, limiting conclusions.

To keep things simple for signing up to the pledge, we should focus just on the basic pledge, and then email pledgers offering for them to take on a mentor role and/or 'level up' their pledge to a higher commitment voluntarily as part of their pledge activation. (And we should track uptake of this!)

Actions:

I'll start drafting the pledge text to include on the website (with gain and loss versions so we can decide how we want to proceed with that)
We'll include a link to an editable pledge document at the top of this thread (thanks @CooperSmout !)

The other thing to mention is that we've decided to make this campaign the next to go live on the website. I'm still interested in developing a peer-review protocol to assess other campaign proposals, but in lieu of that being developed (and advice I've been given) think it makes sense to just go ahead with this campaign and then look to develop a peer review protocol later.

A global why pledge link

I started [this document] to collect ideas for reasons why people should pledge (click the 'Edit on HackMD' button for easy editing)

Start with pledging to pre-register one study in the next year (we forgot to speak about what X should be, but I think one year should be enough time to make just one pre-registration?)

I think the general consensus above was 2 years (Malika and I agreed with your original post)? I agree that one year should be enough time, but as you said above we should give people some leeway after their pledges go live (in case they've just moved jobs/country etc) and so I think 2 years seems like a less confronting option. My bet is that everyone will do it in the first year anyway, but will be interesting to see.

We'll include a link to an editable pledge document at the top of this thread (thanks @CooperSmout !)

Have added that to the first comment, but can also find it here for easy reference :)

Here I think it could be 100 people from your field (thinking of the Tier 2 from such list: https://docs.google.com/spreadsheets/d/1APu3Hi5UtexvISTGkk1D1uZK-7Efjpj9_sQBq_dH38I/edit#gid=222728450) which means you would need to ask people to pick their field from a list.

100 people from your field is a good idea!

I like it too. We should be able to categorise people using their previous publications in ORCID, or alternatively could get people to fill in a dropdown box. We actually built the platform to have a dropdown box in the first place (currently hidden), so might not be too hard to re-implement.

So on further thought, I think it will be easiest for this campaign if we ask people to self-identify their field using a drop-down box, rather than categorise using ORCID profiles (which requires extra coding/testing). I'd still prefer to use the Fields of Research taxonomy (as used in Dimensions) rather than the BePress taxonomy, unless there's a good reason not to @MalikaIhle ? The main reason is that this leaves open the option to categorise people/papers automatically down the track, using Dimensions, as was the original intention for the OA campaigns. But please let me know if you have any thoughts on this!

I think it is best to leave open the option to categorise people/papers automatically down the track, as you suggest!

Had a skim read of the above conversation, but there was a lot of prose. What are the key things you wanted help making decisions on/ where are you at with launching the campaign? :)
Re: the level of commitment you're asking people to make to pre-registering. One avenue you could take, instead of having to think of every possible exception to why someone might not be able to pre-register a specific study, is to ask people to commit to pre-registering all upcoming studies unless there are extenuating circumstances. This puts the onus on the individual researcher to know the exceptions for their own field. I imagine if people are making the effort to sign this in the first place, their hearts are in the right place, and they won't be looking for ways to wiggle out of it.

What are the key things you wanted help making decisions on/ where are you at with launching the campaign?

We've moved into developing the campaign text in HackMD, and were last looking into whether it was possible to test if different framing of the reasons to pledge is more effective at getting support.  @CooperSmout may have other updates on the technological side of implementation?

I imagine if people are making the effort to sign this in the first place, their hearts are in the right place, and they won't be looking for ways to wiggle out of it.

I agree that people will have the right motivations. The complex issue may be when collaborative work crosses disciplines though—would that end up being an exemption?
Our current draft goes with pre-register one study within the next two years so avoids the issue of when something is exempt or not. We wanted in addition to give the option as well for those more advanced in pre-registration to 'mentor' those just starting out with it.

Yep, the main parameters of the campaign are worked out now, so the main obstacle to moving forward is the platform development. I've just emailed @ZoranPandovski to ask if he will have time over the next few weeks to take a look at it, as it would be great if we could use the upcoming AIMOS conference to launch this new campaign (3-4 Dec). Either way we might have to scale back our expectations on what will be possible (e.g. the different framings might be too hard to implement). Will keep you posted.
In the meantime, if anyone here is interested we could start working on marketing materials for the campaign launch, e.g. social media/blog posts etc. There's a list of places we will target here and a few prior posts here and here

Hi all, just an update on the development side of things. The custom python platform that we've been running until now is proving difficult to work on or find support for, and so I'm considering moving to a much simpler platform that lets us get the campaign out there and start collecting pledges/data/feedback sooner rather than later. I'll be presenting FOK at AIMOS in a couple weeks (3-4 December) and think it's too good an opportunity to miss. At the end of the day, we could build the perfect website but if no one is interested in the campaigns, we'd have wasted all that effort.
So to get things rolling, I've created a Github pages website today using Beautiful Jekkyl. It's still a work in progress but thought I'd post it here to see if anyone has any preliminary thoughts. If you click on the 'Pre-registration challenge' post, you'll see some of the text that @dlholf drafted (just the positive framing for now, as we won't be able to test multiple options) plus a Google form that I've embedded in the page. Unfortunately there's no simple way for users to login with ORCID using this setup, but I think that's a worthwhile sacrifice for the sake of moving things ahead. My plan is to enter people's details to the database manually when they pledge, at which point I'll be able to check if the people who registered are legitimate. Any thoughts welcome.
And it's my first time using Github pages so if anyone has experience let me know (currently trying to work out if I can host the website within this 'community' repository, rather than a [separate repository]... without breaking things!).

Website looks cool! A few thoughts:

Should we call it a pledge instead of challenge? (Because I know CoS had a preregistration challenge at some point, and we don't want to confuse the two.

The pledge page has quite a large header.

Join X researchers who have taken the pledge!

Would there be a way to update X to reflect the number of sign-ups currently available?

We probably need to amend this since there is no ORCID login currently.

Your pledge will activate when X people from your field (as determined by researcher field in ORCID) have joined the pledge.

(Also sorry I omitted to update the X in the draft after our discussions!)

Alternatively, we could ask the ORCID field in Forms to be a required answer. Thoughts on this?

Would tick boxes for Research Field work better, so multi-disciplinary researchers can select more than one?

Should we call it a pledge instead of challenge?

Ahhh so that's why 'Prereg Challenge' was sounding so nice in my head! :) I'll change it to pledge instead.

The pledge page has quite a large header

True. Not sure how to adjust but can take a look.

Would there be a way to update X to reflect the number of sign-ups currently available?

I'm planning to update the count manually as pledges come in, since this website is just a static page and doesn't have access to the database (feel free to test the form out and become number 1 ;))

Alternatively, we could ask the ORCID field in Forms to be a required answer. Thoughts on this?

Good question, I'm unsure about this one. On the one hand, requiring an ORCID means that we can check people are actual researchers and also that their chosen field makes sense, but on the other, we might scare some people off who don't have an ORCID (or more likely, don't have it ready to hand). I'm leaning toward making it optional at this stage.

Would tick boxes for Research Field work better, so multi-disciplinary researchers can select more than one?

Tick boxes are listed vertically in Google Forms, so take up heaps of space... Maybe people with multiple fields could add their second field in the 'Other' section...?

Tick boxes are listed vertically in Google Forms, so take up heaps of space...

Ugh, yes, that definitely is problematic. I wonder if we should just let people state their own fields, and we map it to classifications on ORCID? (Though I can't seem to find the relevant ORCID metadata at the moment.) But I'm ambivalent here, and I guess it's worth seeing how many self-input fields we get to start with so we have a better idea for future campaigns.

or more likely, don't have it ready to hand

Yes, that's probably the bigger issue! I certainly have to have mine on a sticky note for copy/pasting purposes because it's impossible to remember.

I wonder if we should just let people state their own fields

Would be interesting to get a feel for how people see themselves/their fields. But the trouble is people would pick their own level for categorisation, and then we'd have to re-classify people according to some taxonomy anyway (which requires communication to check they're ok with the new category). I think for this first campaign, probably makes sense to just pick the categories a priori so that people know what they're getting themselves into, and we can adjust later based on feedback if people aren't happy

Hi all, just closing this thread because this campaign is now live on the new website 🎉
Thanks for all your support in drafting this campaign. I ended up using the BePress taxonomy as per your suggestion @MalikaIhle, because the new website doesn't have ORCID integration anyway and so we won't be automatically classifying people anytime soon, and the BePress taxonomy seems like a cleaner taxonomy.
The comments on the website are now linked to a new Issue (#22), so I'll close this thread and reference it in the new thread in case anyone wants to see the discussion history. Thanks so much for all your input in getting this campaign out into the world!

Ok so we've had our first pledge with a self-entry for the field of Education (Tier 1 in Bepress). I've since emailed the pledger and asked what they thought of the classification level, and they responded that they (a) guessed a field because the Google Sheet wasn't shared (I've fixed this now) and (b) think "there is a chance to get quite a few education researchers involved, but not that many under any specific subclassification".
This is an interesting point -- the chance of reaching threshold really depends on how advanced the field is AND how big it is. Something like Psychology (tier 2) is quite likely to get 100 pledges because it's relatively progressive, but something like Education might need to include all sub-disciplines to have any chance of reaching the target. I also just did a quick search on Dimensions, and it looks like Psychology (Bepress tier 2) is larger than the entire field of Education (Bepress tier 1), with 2.67 million and 1.76 million papers, respectively, so probably makes sense that both are options despite them being at different tiers in the taxonomy.
So I think I'll put Education into the dropdown for now and see if other Education researchers select that or enter something new. I'm also thinking I should probably remove all of the dropdown options that haven't been selected yet (I pre-populated the dropdown with ~35 Tier 2 fields -- mostly life sciences), so that people can enter whatever level they think makes sense and we can connect people up after the fact. Looks like I'll be emailing the first wave of pledgers a fair bit anyway, so not much more effort to check in with people who enter something new. I guess what I'm trying to say is: @dlholf you were right all along ;)

I wonder if we should just let people state their own fields, and we map it to classifications on ORCID? (Though I can't seem to find the relevant ORCID metadata at the moment.) But I'm ambivalent here, and I guess it's worth seeing how many self-input fields we get to start with so we have a better idea for future campaigns

(although I missed your comment about ORCID metadata first time around, and not entirely sure what that means :))

(although I missed your comment about ORCID metadata first time around, and not entirely sure what that means :))

It was just that I couldn't find a place on ORCID that identified what fields researchers were in. I could have sworn they had a list of fields, but I feel like I must have been hallucinating that!


[BUG] --max_slice_nums > than 9 will not work

是否已有关于该错误的issue或讨论？ | Is there an existing issue / discussion for this?

[X] 我已经搜索过已有的issues和讨论 | I have searched the existing issues / discussions

该问题是否在FAQ中有解答？ | Is there an existing answer for this in FAQ?

[X] 我已经搜索过FAQ | I have searched FAQ

当前行为 | Current Behavior
When setting max_slice_nums > 9 for lora fine tune it gives the following error idx_dim >= 0 && idx_dim < index_size && "index out of bounds". There is any way to increase this number?
期望行为 | Expected Behavior
Fine tune the model
复现方法 | Steps To Reproduce
Follow the lora finetune instructions
运行环境 | Environment
- OS:
- Python:
- Transformers:
- PyTorch:
- CUDA (`python -c 'import torch; print(torch.version.cuda)'`):

备注 | Anything else?
No response

hi this is a bug, please fix the value to 9

There will be any future update? I would like to increase this value so I can improve for OCR tasks