HBASE-22380 break circle replication when doing bulkload

PR for master branch

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
36
Maven dependency ordering for branch

+1
mvninstall
307
master passed

+1
compile
119
master passed

+1
checkstyle
134
master passed

+1
shadedjars
274
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
76
master passed

0
spotbugs
236
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
445
master passed

_ Patch Compile Tests _

0
mvndep
17
Maven dependency ordering for patch

+1
mvninstall
293
the patch passed

+1
compile
121
the patch passed

+1
cc
121
the patch passed

+1
javac
121
the patch passed

-1
checkstyle
83
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
270
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
924
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
115
the patch passed

-1
javadoc
36
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
248
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
42
hbase-protocol-shaded in the patch passed.

+1
unit
108
hbase-client in the patch passed.

-1
unit
9315
hbase-server in the patch failed.

+1
asflicense
89
The patch does not generate ASF License warnings.

13835

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux e999bac446c9 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / 090c55f3ff

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/testReport/

Max. process+thread count
4545 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/1/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
276
Maven dependency ordering for branch

+1
mvninstall
317
master passed

+1
compile
127
master passed

+1
checkstyle
130
master passed

+1
shadedjars
277
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
78
master passed

0
spotbugs
251
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
483
master passed

_ Patch Compile Tests _

0
mvndep
18
Maven dependency ordering for patch

+1
mvninstall
305
the patch passed

+1
compile
120
the patch passed

+1
cc
120
the patch passed

+1
javac
120
the patch passed

-1
checkstyle
82
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
277
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
936
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
114
the patch passed

-1
javadoc
36
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
261
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
42
hbase-protocol-shaded in the patch passed.

+1
unit
109
hbase-client in the patch passed.

-1
unit
10229
hbase-server in the patch failed.

+1
asflicense
88
The patch does not generate ASF License warnings.

15113

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux b95aa8766f79 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / ee5cf0d209

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/testReport/

Max. process+thread count
4799 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/2/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
87
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
1
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
70
Maven dependency ordering for branch

+1
mvninstall
375
master passed

+1
compile
137
master passed

+1
checkstyle
153
master passed

+1
shadedjars
321
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
79
master passed

0
spotbugs
259
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
495
master passed

_ Patch Compile Tests _

0
mvndep
18
Maven dependency ordering for patch

+1
mvninstall
373
the patch passed

+1
compile
137
the patch passed

+1
cc
137
the patch passed

+1
javac
137
the patch passed

-1
checkstyle
99
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
299
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1008
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
114
the patch passed

-1
javadoc
35
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
216
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
42
hbase-protocol-shaded in the patch passed.

+1
unit
110
hbase-client in the patch passed.

-1
unit
9753
hbase-server in the patch failed.

+1
asflicense
83
The patch does not generate ASF License warnings.

14782

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux 28bff3de0826 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / b642ee0418

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/testReport/

Max. process+thread count
4270 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/3/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
40
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
1
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
37
Maven dependency ordering for branch

+1
mvninstall
319
master passed

+1
compile
130
master passed

+1
checkstyle
130
master passed

+1
shadedjars
278
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
73
master passed

0
spotbugs
244
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
473
master passed

_ Patch Compile Tests _

0
mvndep
18
Maven dependency ordering for patch

+1
mvninstall
298
the patch passed

+1
compile
121
the patch passed

+1
cc
121
the patch passed

+1
javac
121
the patch passed

-1
checkstyle
89
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
270
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
931
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
115
the patch passed

-1
javadoc
38
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
252
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
44
hbase-protocol-shaded in the patch passed.

+1
unit
110
hbase-client in the patch passed.

-1
unit
10313
hbase-server in the patch failed.

+1
asflicense
87
The patch does not generate ASF License warnings.

14950

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux 58cada9052c8 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / 97fbaa658e

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/testReport/

Max. process+thread count
4477 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/4/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
92
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
44
Maven dependency ordering for branch

+1
mvninstall
356
master passed

+1
compile
130
master passed

+1
checkstyle
145
master passed

+1
shadedjars
307
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
80
master passed

0
spotbugs
273
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
533
master passed

_ Patch Compile Tests _

0
mvndep
16
Maven dependency ordering for patch

+1
mvninstall
338
the patch passed

+1
compile
133
the patch passed

+1
cc
133
the patch passed

+1
javac
133
the patch passed

-1
checkstyle
93
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
303
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1052
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
122
the patch passed

-1
javadoc
37
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
290
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
44
hbase-protocol-shaded in the patch passed.

+1
unit
104
hbase-client in the patch passed.

-1
unit
16581
hbase-server in the patch failed.

+1
asflicense
76
The patch does not generate ASF License warnings.

21685

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

hadoop.hbase.client.TestFromClientSide

hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas

hadoop.hbase.client.TestFromClientSideWithCoprocessor

hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.master.TestSplitWALManager

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux e2b830907fd0 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / a5ef6b287c

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/testReport/

Max. process+thread count
4924 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/5/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
50
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
37
Maven dependency ordering for branch

+1
mvninstall
401
master passed

+1
compile
138
master passed

+1
checkstyle
157
master passed

+1
shadedjars
351
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
79
master passed

0
spotbugs
293
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
562
master passed

_ Patch Compile Tests _

0
mvndep
17
Maven dependency ordering for patch

+1
mvninstall
367
the patch passed

+1
compile
142
the patch passed

+1
cc
142
the patch passed

+1
javac
142
the patch passed

-1
checkstyle
111
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
351
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1161
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
140
the patch passed

-1
javadoc
41
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
304
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
51
hbase-protocol-shaded in the patch passed.

+1
unit
128
hbase-client in the patch passed.

-1
unit
9922
hbase-server in the patch failed.

+1
asflicense
85
The patch does not generate ASF License warnings.

15468

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux ee9b69d24593 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / 13b2edc1be

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/testReport/

Max. process+thread count
4640 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/6/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
40
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 2 new or modified test files.

_ master Compile Tests _

0
mvndep
34
Maven dependency ordering for branch

+1
mvninstall
332
master passed

+1
compile
124
master passed

+1
checkstyle
154
master passed

+1
shadedjars
314
branch has no errors when building our shaded downstream artifacts.

+1
javadoc
81
master passed

0
spotbugs
271
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
520
master passed

_ Patch Compile Tests _

0
mvndep
19
Maven dependency ordering for patch

+1
mvninstall
382
the patch passed

+1
compile
118
the patch passed

+1
cc
118
the patch passed

+1
javac
118
the patch passed

-1
checkstyle
82
hbase-server: The patch generated 1 new + 283 unchanged - 0 fixed = 284 total (was 283)

+1
whitespace
1
The patch has no whitespace issues.

+1
shadedjars
289
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
1000
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
hbaseprotoc
242
the patch passed

-1
javadoc
103
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

-1
findbugs
537
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1
unit
65
hbase-protocol-shaded in the patch passed.

+1
unit
181
hbase-client in the patch passed.

-1
unit
10539
hbase-server in the patch failed.

+1
asflicense
86
The patch does not generate ASF License warnings.

16575

Reason
Tests

FindBugs
module:hbase-server

org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(List, CellScanner, String, String, String) makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:makes inefficient use of keySet iterator instead of entrySet iterator  At ReplicationSink.java:[line 258]

Failed junit tests
hadoop.hbase.tool.TestBulkLoadHFilesSplitRecovery

hadoop.hbase.tool.TestSecureBulkLoadHFilesSplitRecovery

hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/566

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile cc hbaseprotoc

uname
Linux feb8ff49f0f1 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-566/out/precommit/personality/provided.sh

git revision
master / 8e8bd8b254

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/artifact/out/diff-checkstyle-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/artifact/out/diff-javadoc-javadoc-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/artifact/out/new-findbugs-hbase-server.html

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/testReport/

Max. process+thread count
4500 (vs. ulimit of 10000)

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/7/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

how is the implementation here different than on #494?

Concept is the same, but there were major changes between branch-2 and master code bases that required some re-work to come with a PR to master. For example, there's no LoadIncrementalHFiles, the most equivalent class is BulkLoadHFilesTool. Same for SecureBulkLoadClient, which was removed on master branch, being replaced by AsyncClusterConnection/AsyncClusterConnectionImpl methods.

Ok, so would it be ok as it is now?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
0m  0s
Docker mode activated.

:broken_heart:
patch
0m  5s
https://github.com/apache/hbase/pull/566 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/566

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/9/console

versions
git=2.17.1

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
0m  0s
Docker mode activated.

:broken_heart:
patch
0m  5s
https://github.com/apache/hbase/pull/566 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/566

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-566/10/console

versions
git=2.17.1

Powered by
Apache Yetus 0.11.0 https://yetus.apache.org

This message was automatically generated.


[ENG-7968][eas-cli][eas-json] print deprecation warnings for deprecated eas.json fields

Checklist

[ ] I've added an entry to CHANGELOG.md if necessary. You can comment this pull request with /changelog-entry [breaking-change|new-feature|bug-fix|chore] [message] and CHANGELOG.md will be updated automatically.

Why
https://linear.app/expo/issue/ENG-7968/do-not-cache-podfilelock-by-default
Companion to https://github.com/expo/turtle-v2/pull/1256.
How
Add a method in eas.json which returns deprecation warnings. Print them in the EAS CLI.
Test Plan
Test manually

/changelog-entry chore Print deprecation warnings for deprecated eas.json fields


How to use guidance to guide ddpm?

I have trained ddpm for a long time, then I select a image in training set, then add some noise or do some transform to this image, then use it to guide ddpm, but result is not good
def ddim_sample(self, shape, guide=None, mask=None, clip_denoised = True):
        batch, device, total_timesteps, sampling_timesteps, eta, objective = shape[0], self.betas.device, self.num_timesteps, self.sampling_timesteps, self.ddim_sampling_eta, self.objective

        times = torch.linspace(-1, total_timesteps - 1, steps=sampling_timesteps + 1)   # [-1, 0, 1, 2, ..., T-1] when sampling_timesteps == total_timesteps
        times = list(reversed(times.int().tolist()))
        time_pairs = list(zip(times[:-1], times[1:])) # [(T-1, T-2), (T-2, T-3), ..., (1, 0), (0, -1)]

        img = torch.randn(shape, device = device)

        x_start = None

        for time, time_next in tqdm(time_pairs, desc = 'sampling loop time step'):
            time_cond = torch.full((batch,), time, device=device, dtype=torch.long)
            self_cond = x_start if self.self_condition else None
            pred_noise, x_start, *_ = self.model_predictions(img, time_cond, self_cond, clip_x_start = clip_denoised)

            if time_next < 0:
                img = x_start
                continue

            alpha = self.alphas_cumprod[time]
            alpha_next = self.alphas_cumprod[time_next]

            sigma = eta * ((1 - alpha / alpha_next) * (1 - alpha_next) / (1 - alpha)).sqrt()
            c = (1 - alpha_next - sigma ** 2).sqrt()

            noise = torch.randn_like(img)

            img = x_start * alpha_next.sqrt() + \
                  c * pred_noise + \
                  sigma * noise

            # here use the guidance
            if guide is not None:
                time_next_cond = torch.full((batch,), time, device=device, dtype=torch.long)
                guide_t_1 = self.q_sample(guide, time_next_cond)
                img = img * mask + guide_t_1 * (1 - mask)

        img = unnormalize_to_zero_to_one(img)
        return img

Some results are showed below, the left is the origin image, the mid is added some transformation as the guidance, the right is the ddpm result.

You see, that the right, ddpm result is  not good. But I don't know why.

there are some problems in my code.
my ddpm is not good

training not enough, but I have trained it for 2 days, 500000 steps, 5000images, batch_size=12, image_size=256
training data is not good

Hi, I trained over 10000 steps using the flower classification dataset and obtained a noise map. And my fid score always is 150. Could you tell how to get your results.


CGO Dependency

Can CGO dependency be removed? this will greatly improve the portability
https://gitlab.com/cznic/sqlite
This library above is a CGO free port of sqlite

The github.com/mattn/go-sqlite3 is optional if you use Redka as a Go module. You can use any other driver. This is addressed in the docs:

You'll also need an SQLite driver. Use github.com/mattn/go-sqlite3 if you don't mind CGO. Otherwise use a pure Go driver modernc.org/sqlite.

There is also a CGO-free usage example in example/modernc/main.go.


Updates to error handling

Adds custom error codes to MICM classes and updates existing error handling to use them. The hope is that in the MUSICA library we can catch these errors and turn them into meaningful codes/messages that can be returned through the C API.
closes #466

Codecov Report
Attention: Patch coverage is 61.41479% with 120 lines in your changes are missing coverage. Please review.

Project coverage is 92.43%. Comparing base (20da447) to head (7cf2e07).

Files
Patch %
Lines

include/micm/configure/solver_config.hpp
76.19%
30 Missing :warning:

include/micm/process/process_set.hpp
0.00%
13 Missing :warning:

include/micm/jit/jit_compiler.hpp
0.00%
12 Missing :warning:

include/micm/process/rate_constant.hpp
0.00%
12 Missing :warning:

include/micm/solver/rosenbrock.inl
0.00%
12 Missing :warning:

include/micm/solver/state.inl
70.37%
8 Missing :warning:

include/micm/process/process.hpp
63.63%
4 Missing :warning:

include/micm/util/matrix.hpp
71.42%
4 Missing :warning:

include/micm/util/sparse_matrix.hpp
73.33%
4 Missing :warning:

...lude/micm/util/sparse_matrix_standard_ordering.hpp
71.42%
4 Missing :warning:

... and 8 more

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #468      +/-   ##
==========================================
- Coverage   94.34%   92.43%   -1.92%
==========================================
  Files          39       39
  Lines        3166     3303     +137
==========================================
+ Hits         2987     3053      +66
- Misses        179      250      +71

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

I like it! I guess one concern is that we are potentially masking system errors in our tests if they were ever to be thrown and happen to have the same numerical value as the micm error values.
And on that note, in MUSICA, I don't see how we will be able to identify exactly which error was thrown since we have overlapping codes. It seems like we would need to know exactly which part of the code threw this so that we know which enum class to match the error code to. What am I missing?

Yeah, I was starting to work through that in the MUSICA library. One option might be to use a combination of the category name and the int value of the enum. Something like:
struct Error {
  int code_;
  const char* category_;
  const char* message_;
};

This way on the user side (even in Fortran, and I'm guessing Python), you could use strcmp(error.category_, "MICM Matrix") == 0 && error.code_ == 2 to identify our MicmMatrixErrc::InvalidVector error. And this should avoid us masking other system errors. What do you think?

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion.  I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

If we do, we might be able to leverage the C++ library: https://en.cppreference.com/w/cpp/utility/source_location

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

I like that too. The only thing that's a little unclear to me is how the dependencies would work. If the error codes live in MUSICA, would MICM and TUV-x depend on MUSICA? Or if they live in MICM and TUV-x, would MICM and TUV-x depend on each other?

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

I like that too. The only thing that's a little unclear to me is how the dependencies would work. If the error codes live in MUSICA, would MICM and TUV-x depend on MUSICA? Or if they live in MICM and TUV-x, would MICM and TUV-x depend on each other?

If each project maintained a list of errors, their own errors.h, or <project>_errors.h which could be included as part of error handling, would that avoid explicit dependencies between the projects for error handling? I feel like that's a naive question, but it's the first that springs to mind.

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

From experience, ASSERT is great when it works for the intended purpose, but when it leaks out into user-space (e.g. unexpected/unanticipated behavior results in an 'unreachable' ASSERT being reached by a user at runtime) it can become a bit of a pain. So I guess with careful planning, using an ASSERT for debugging purposes instead of FILE and LINE would work.  +100 to the idea of 'clear error messaging'.
From a user support perspective, I wonder now about a user sending you details around a problem they had.  Would the error be enough for you to debug what's going on? Or would __FILE__ and __LINE__ be useful information to you then?  Just thinking out loud, clearly.

I'm taking a look at this today; getting caught up on the conversation. In C, software error codes are typically negative, and system error codes are typically positive, to avoid collisions/confusion. I'm about to review the PR changes so perhaps it's already in place, but in the netCDF project we have an errors.h file which we use to define all the errors in one place and easier developer reference.

I am a fan of having all of the errors in one place as well. It may mean a long file but it also means we don't need to have a specific error class for each header in micm. @mattldawson would you have anything against a single error file?

I like that too. The only thing that's a little unclear to me is how the dependencies would work. If the error codes live in MUSICA, would MICM and TUV-x depend on MUSICA? Or if they live in MICM and TUV-x, would MICM and TUV-x depend on each other?

If each project maintained a list of errors, their own errors.h, or <project>_errors.h which could be included as part of error handling, would that avoid explicit dependencies between the projects for error handling? I feel like that's a naive question, but it's the first that springs to mind.

I like that idea. Would you expect the error header to just define the int codes and the category strings? Something like:
#define ERR_CAT_MICM_MATRIX "MICM Matrix"
#define ERR_CODE_MICM_ROW_SIZE_MISMATCH 1
#define ERR_CODE_MICM_INVALID_VECTOR 2

and then update, e.g., the Matrix class to use them:
enum class MicmMatrixErrc
{
  RowSizeMismatch = ERR_CODE_MICM_ROW_SIZE_MISMATCH,
  InvalidVector = ERR_CODE_MICM_INVALID_VECTOR,
};

namespace
{
  class MicmMatrixErrorCategory : public std::error_category
  {
   public:
    const char *name() const noexcept override
    {
      return ERR_CAT_MICM_MATRIX;
    }
    ...

The only thing might be that we couldn't use the same label for specific errors in different categories. (like if INVALID_VECTOR is an error in another class like SparseMatrix)

The functionality of this looks good, albeit I'm taking a 10,000 foot view. My one thought is that the code would benefit from some comments; while a lot of it is self evident now, it might be less so down the road. "Code needing more in-line comments" is hardly novel feedback, I acknowledge XD. Particularly since it could apply to any number of my own PRs. But since I'm looking at this as an outsider and not a core developer, the function is less immediately obvious to me, and the lack of comments stands out more.

I have gone back and forth over time between 'comment everything' and 'try to write self-documenting code', and I don't know where I'm at right now. I'm happy to add more comments though. Was there anything in particular that you noticed should have more documentation?

Another benefit to the single file for errors might be that if we just use CPP definitions, we can include the same header in the fortran wrapper code and maybe cut down on the passing back and forth of strings between c and fortran or keeping this list in two places.

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

From experience, ASSERT is great when it works for the intended purpose, but when it leaks out into user-space (e.g. unexpected/unanticipated behavior results in an 'unreachable' ASSERT being reached by a user at runtime) it can become a bit of a pain. So I guess with careful planning, using an ASSERT for debugging purposes instead of FILE and LINE would work. +100 to the idea of 'clear error messaging'.
From a user support perspective, I wonder now about a user sending you details around a problem they had. Would the error be enough for you to debug what's going on? Or would __FILE__ and __LINE__ be useful information to you then? Just thinking out loud, clearly.

In going through the process of making these changes, I think it would be pretty clear what part of the code threw the error (the error categories are specific to one class, or in one case two classes that extend the same base class, and the individual errors are mostly only thrown in one place, or a few places at most).
To me what's important is that these errors always indicate a problem that the user should address, not one that indicates a bug in our code. If we also want to make it easier for users to report bugs in our code, what if we added something like an InternalMicmErrc? If we add some run-time bug check to our code that trips, it could throw this and include the file and line number of the detailed message. The user would get something like "Internal MICM Error(file, line): Please file a bug report..." What does everyone think of something like this?

For the error handling, would it be better to add the __FILE__ and __LINE__ information so that a user can be directed to the exact location where the error occurs?

My thinking is that the errors we return to API users should be clear enough for them to act upon without having to look through our source code. (Problems with configuration files, passing improperly sized arrays to API functions, etc.) If we're just interested in bug checking our code at runtime, we can do this with asserts instead of throwing exceptions. What does everyone think?

From experience, ASSERT is great when it works for the intended purpose, but when it leaks out into user-space (e.g. unexpected/unanticipated behavior results in an 'unreachable' ASSERT being reached by a user at runtime) it can become a bit of a pain. So I guess with careful planning, using an ASSERT for debugging purposes instead of FILE and LINE would work. +100 to the idea of 'clear error messaging'.
From a user support perspective, I wonder now about a user sending you details around a problem they had. Would the error be enough for you to debug what's going on? Or would __FILE__ and __LINE__ be useful information to you then? Just thinking out loud, clearly.

In going through the process of making these changes, I think it would be pretty clear what part of the code threw the error (the error categories are specific to one class, or in one case two classes that extend the same base class, and the individual errors are mostly only thrown in one place, or a few places at most).
To me what's important is that these errors always indicate a problem that the user should address, not one that indicates a bug in our code. If we also want to make it easier for users to report bugs in our code, what if we added something like an InternalMicmErrc? If we add some run-time bug check to our code that trips, it could throw this and include the file and line number of the detailed message. The user would get something like "Internal MICM Error(file, line): Please file a bug report..." What does everyone think of something like this?

Ah, I see. I am thinking about the code bug and I want the error message to be direct and pointed to the specific source code for faster debugging later. But regarding a user error, what you and others propose here makes sense to me, and using an error header file with enumed error code sounds a good idea. Thanks for your clarification.

I like it! I guess one concern is that we are potentially masking system errors in our tests if they were ever to be thrown and happen to have the same numerical value as the micm error values.
And on that note, in MUSICA, I don't see how we will be able to identify exactly which error was thrown since we have overlapping codes. It seems like we would need to know exactly which part of the code threw this so that we know which enum class to match the error code to. What am I missing?

Yeah, I was starting to work through that in the MUSICA library. One option might be to use a combination of the category name and the int value of the enum. Something like:
struct Error {
  int code_;
  const char* category_;
  const char* message_;
};

With this to turn std::system_error into an Error:
Error ToError(const std::system_error& e)
{
    Error error;
    error.code_ = e.code().value();
    error.category_ = e.code().category().name();
    error.message_ = e.what();
    return error;
}

This way on the user side (even in Fortran, and I'm guessing Python), you could use strcmp(error.category_, "MICM Matrix") == 0 && error.code_ == 2 to identify our MicmMatrixErrc::InvalidVector error. And this should avoid us masking other system errors. What do you think?

I like this idea

Based on the discussion, I'll go ahead and create a micm error header and add an internal error category that includes the filename and line number in the message. (I'm not sure if we actually have any run-time checks that I can apply this to, but if I can't find one I'll just add a test that throws this error.)
I'll request a re-review once that's ready, but let me know if you would prefer not to review this again and I won't include you in the re-review.
Thanks for the discussion everyone!

Reviewing now as well, although I'm sure I'll be the slowest due to relative unfamiliarity; I don't anticipate finding any issues, but I'm trying to digest what I'm looking at instead of skimming it :)

I agree about not making things confusing just to cater to fortran, but I think we should try to have the copyright and license on each source code file. What if we revisit this after the fortran wrapper is updated? It could be the case that we don't even need it in fortran and can just use normal comments.

I agree about not making things confusing just to cater to fortran, but I think we should try to have the copyright and license on each source code file. What if we revisit this after the fortran wrapper is updated? It could be the case that we don't even need it in fortran and can just use normal comments.

(I added this to our post-development review issue #211)

Sounds good, thank you!


Diem CLI fixes

This PR upgrades the Diem CLI component of the developers website. The upgraded version contains numerous improvements and bug fixes.
This PR builds upon diem/diem#7071 by @oriooctopus. If it looks like this PR has a lot of changes, it is only because diem/diem#7071 was not merged yet.

:exclamation: before this PR can be merged please make sure that you enable "Allow edits from maintainers".
This is needed for tooling to be able to update this PR in-place so that Github can properly recognize and mark it as merged once its merged into the upstream branch

:exclamation: before this PR can be merged please make sure that you enable "Allow edits from maintainers".
This is needed for tooling to be able to update this PR in-place so that Github can properly recognize and mark it as merged once its merged into the upstream branch

LSR dependency change summary:
target packages:
  A cpuid-bool 0.2.0 (transitive third-party, crates.io) (other versions: 0.1.2)
    * features: [none]
  M bcs 0.1.2 (direct third-party, crates.io)
    * version upgraded from 0.1.1
    * (unchanged features: [none])
  M openssl-sys 0.9.59 (transitive third-party, crates.io)
    * version upgraded from 0.9.58
    * (unchanged features: [none])
  M parking_lot 0.11.1 (transitive third-party, crates.io)
    * version upgraded from 0.11.0
    * (unchanged features: default)
  M polyval 0.4.3 (transitive third-party, crates.io)
    * version upgraded from 0.4.1
    * (unchanged features: [none])

LSR dependency change summary:
target packages:
  A cpuid-bool 0.2.0 (transitive third-party, crates.io) (other versions: 0.1.2)
    * features: [none]
  M bcs 0.1.2 (direct third-party, crates.io)
    * version upgraded from 0.1.1
    * (unchanged features: [none])
  M openssl-sys 0.9.59 (transitive third-party, crates.io)
    * version upgraded from 0.9.58
    * (unchanged features: [none])
  M parking_lot 0.11.1 (transitive third-party, crates.io)
    * version upgraded from 0.11.0
    * (unchanged features: default)
  M polyval 0.4.3 (transitive third-party, crates.io)
    * version upgraded from 0.4.1
    * (unchanged features: [none])

LEC dependency change summary:
target packages:
  A cpuid-bool 0.2.0 (transitive third-party, crates.io) (other versions: 0.1.2)
    * features: [none]
  M bcs 0.1.2 (direct third-party, crates.io)
    * version upgraded from 0.1.1
    * (unchanged features: [none])
  M crossbeam-epoch 0.9.1 (transitive third-party, crates.io)
    * version upgraded from 0.9.0
    * (unchanged features: alloc, lazy_static, std)
  M libc 0.2.81 (transitive third-party, crates.io)
    * added features: align
    * (unchanged features: default, std)
  M memoffset 0.6.1 (transitive third-party, crates.io)
    * version upgraded from 0.5.6
    * (unchanged features: default)
  M openssl-sys 0.9.59 (transitive third-party, crates.io)
    * version upgraded from 0.9.58
    * (unchanged features: [none])
  M parking_lot 0.11.1 (transitive third-party, crates.io)
    * version upgraded from 0.11.0
    * (unchanged features: default)
  M polyval 0.4.3 (transitive third-party, crates.io)
    * version upgraded from 0.4.1
    * (unchanged features: [none])
  M socket2 0.3.18 (transitive third-party, crates.io)
    * version upgraded from 0.3.15
    * (unchanged features: [none])

release binaries dependency change summary:
target packages:
  A cpuid-bool 0.2.0 (transitive third-party, crates.io) (other versions: 0.1.2)
    * features: [none]
  M bcs 0.1.2 (direct third-party, crates.io)
    * version upgraded from 0.1.1
    * (unchanged features: [none])
  M crossbeam-epoch 0.9.1 (transitive third-party, crates.io)
    * version upgraded from 0.9.0
    * (unchanged features: alloc, lazy_static, std)
  M libc 0.2.81 (transitive third-party, crates.io)
    * added features: align
    * (unchanged features: default, std)
  M memoffset 0.6.1 (transitive third-party, crates.io)
    * version upgraded from 0.5.6
    * (unchanged features: default)
  M openssl-sys 0.9.59 (transitive third-party, crates.io)
    * version upgraded from 0.9.58
    * (unchanged features: [none])
  M parking_lot 0.11.1 (transitive third-party, crates.io)
    * version upgraded from 0.11.0
    * (unchanged features: default)
  M polyval 0.4.3 (transitive third-party, crates.io)
    * version upgraded from 0.4.1
    * (unchanged features: [none])
  M socket2 0.3.18 (transitive third-party, crates.io)
    * version upgraded from 0.3.15
    * (unchanged features: [none])

LEC dependency change summary:
target packages:
  A cpuid-bool 0.2.0 (transitive third-party, crates.io) (other versions: 0.1.2)
    * features: [none]
  M bcs 0.1.2 (direct third-party, crates.io)
    * version upgraded from 0.1.1
    * (unchanged features: [none])
  M crossbeam-epoch 0.9.1 (transitive third-party, crates.io)
    * version upgraded from 0.9.0
    * (unchanged features: alloc, lazy_static, std)
  M libc 0.2.81 (transitive third-party, crates.io)
    * added features: align
    * (unchanged features: default, std)
  M memoffset 0.6.1 (transitive third-party, crates.io)
    * version upgraded from 0.5.6
    * (unchanged features: default)
  M openssl-sys 0.9.59 (transitive third-party, crates.io)
    * version upgraded from 0.9.58
    * (unchanged features: [none])
  M parking_lot 0.11.1 (transitive third-party, crates.io)
    * version upgraded from 0.11.0
    * (unchanged features: default)
  M polyval 0.4.3 (transitive third-party, crates.io)
    * version upgraded from 0.4.1
    * (unchanged features: [none])
  M socket2 0.3.18 (transitive third-party, crates.io)
    * version upgraded from 0.3.15
    * (unchanged features: [none])

release binaries dependency change summary:
target packages:
  A cpuid-bool 0.2.0 (transitive third-party, crates.io) (other versions: 0.1.2)
    * features: [none]
  M bcs 0.1.2 (direct third-party, crates.io)
    * version upgraded from 0.1.1
    * (unchanged features: [none])
  M crossbeam-epoch 0.9.1 (transitive third-party, crates.io)
    * version upgraded from 0.9.0
    * (unchanged features: alloc, lazy_static, std)
  M libc 0.2.81 (transitive third-party, crates.io)
    * added features: align
    * (unchanged features: default, std)
  M memoffset 0.6.1 (transitive third-party, crates.io)
    * version upgraded from 0.5.6
    * (unchanged features: default)
  M openssl-sys 0.9.59 (transitive third-party, crates.io)
    * version upgraded from 0.9.58
    * (unchanged features: [none])
  M parking_lot 0.11.1 (transitive third-party, crates.io)
    * version upgraded from 0.11.0
    * (unchanged features: default)
  M polyval 0.4.3 (transitive third-party, crates.io)
    * version upgraded from 0.4.1
    * (unchanged features: [none])
  M socket2 0.3.18 (transitive third-party, crates.io)
    * version upgraded from 0.3.15
    * (unchanged features: [none])

Now that #7071 has landed, @yanivmo can you rebase this and then we can approve and land it?

Now that #7071 has landed, @yanivmo can you rebase this and then we can approve and land it?

Now that #7071 has landed, @yanivmo can you rebase this and then we can approve and land it?

Rebased.

Now that #7071 has landed, @yanivmo can you rebase this and then we can approve and land it?

Rebased.

We may need one more reviewer, but I will try landing it.

We may need one more reviewer, but I will try landing it.

/land

/land

:broken_heart: Test Failed - commit-workflow

:broken_heart: Test Failed - commit-workflow

/land

/land

:exclamation: failed to update PR in-place. When this PR is merged Github will improperly mark it as "Closed" instead of "Merged".
In the future make sure that that "Allow edits from maintainers" is enabled, allowing Bors to update the PR in-place before merging and convince Github to mark the PR as "Merged".

:exclamation: failed to update PR in-place. When this PR is merged Github will improperly mark it as "Closed" instead of "Merged".
In the future make sure that that "Allow edits from maintainers" is enabled, allowing Bors to update the PR in-place before merging and convince Github to mark the PR as "Merged".


Fixed sourcemap url

Sourcemaps are generated with path not recognized by the browser.
This PR fix the path.

Good catch! I solved this problem in another way. https://github.com/babel/metalsmith-babel/commit/902a1474f9abd57e0ef2520c18c464880b87ea87

Thanks! The important thing was fix the issue ;) Your fix is perfect.

Could you bump the version and push the fix to npm?

I'll publish the next version including this fix. Note that the next version won't support Node v0.x anymore. Please upgrade to Node v4.1.1 if you haven't done yet.

Thanks again, I've already moved to node 4.x.

https://github.com/babel/metalsmith-babel/commit/23f5674351bddc47d8d7a0d2d52733492880d688


Only works once before having to restart VSCode

I love this extension and use it daily, but all of a sudden it only works once before I have to restart VSCode. Not really sure why, I've tried disabling all other extensions and the problem persists.

I have this issue as well, it started happening few days ago.
Visual Studio Code version: 1.41.1, es7-javascript-react-snippets version 2.5.0

I have this issue as well, it started happening few days ago. Maybe latest vscode update is causing trouble?
Visual Studio Code version: 1.41.1, es7-javascript-react-snippets version 2.5.0

I rollback vscode version to 1.40.1,and it works

Looks like issue in VSCode unfortunately. I search for issue but for now, I recommend using shortcut to trigger search menu (CMD + Shift + R on Mac).

CTRL + Alt + R for Windows

@gjones604 Could you confirm this bug still exists in newest version of VSCode?

Yes still an issue on 1.42.1

Seems to be fixed now. Thanks!

@gjones604 I did nothing actually :P there was a bug inside VSCode :)

@dsznajder Did you manage to resolve this issue or did you close it because its vscode bug?

@nparoski I did not meet this on my end. Also, if you look on previous comment, someone wrote that it's resolved now. I recommend you to update VSCode to newest version.

@dsznajder Whoops sorry i overlooked that comment, thank you!


Some minor improvements, mostly to ArgumentTypes

This is meant to remove some inconsistencies I found, or improve the wording where I thought neccassary. I didn't look at most of the stuff yet, but probably won't have the time to do so soon. Other stuff I looked at was fine imho.
This is more of a suggestion of how you could apply changes. If you don't like something, feel free to close the pull request and make a commit of your own to your branch. Of course, everything is open for discussion, too.
I mostly wanted to avoid cluttering your pull requests with inline comments ;)

Thank you very much! :)
I merged them and edited them slightly.


Revisit and improve/simplify Manifest/Import logic

So far this has been a bit of a bug farm, need to revisit to see if we can improve the manifest/import logic
Issues so far:

Easy to forget to add new services (Logger<>, IApplicationLifetime)
Generic services don't work via delegate (so Logger<> doesn't actually chain)

cc @lodejard @davidfowl

Adding more problems:

Flowing more services requires combining manifests

This is a huge wart we need to talk about.
/cc @glennc @muratg

@davidfowl adding this to the agenda of "tactical items" discussion.

Summary of proposed changes:

Introduce interface which can modify the app during hosting

public interface IStartupFilter
  void Configure(IApplicationBuilder app, Action<IApplicationBuilder> next)

Call ConfigureServices early and resolve all hosting services other than IStartupLoader/IHostingEngine (which are not replaceable any longer, ini config swapping is CUT)

Add new helper class

public class StartupMethods {
  Func<IServiceCollection, IServiceProvider> ConfigureServices { get; set; }
  Action<IpplicationBuilder> Configure { get; set; }
}
```

- Rename IServiceManifest to something obtuse (IRuntimeExportedSerivices??), stop using manifest hosting now that we will have auto request scope, and directly populate app DI container with the old hosting services (IHttpContextAccessor, IApplicationLifetime, IHostingEnvironment, etc.)

- Kill UseServices/UseRequestServices/RequestContainer

Depends on https://github.com/aspnet/Hosting/issues/189


WebUI - Error displaying transactions and channel balances

After upgrading to 1.8.0 on my CLN only node I logged into the WebUI for the first time to be greeted with An error occured: Unknown error in the Transactions panel. Also all of the channel balances in the Lightning panel are zero. I noticed #3182 saying the current cln-grpc is experimental, could that be the reason? Is the WebUI not recommended for CLN nodes yet?

Hi @Satswalker
Can you test with 1.10.0 again? The issues should be mostly resolved.


API response objects shouldn't use arrays to represent structured data

https://cloud.google.com/nodejs/docs/reference/pubsub/0.19.x/global
Many response types are arrays rather than objects. For example: CreateTopicResponse is an array of size 2 where the first element is a Topic and the second element is "The full API response"
These should be members of an object rather than elements of array.

We have an issue for this, discussing what to do for all of our libraries: https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2556

👋 We're going to track this up at the master issue for now, and take this on as part of a larger all-up effort across all libraries in Q4.


Opt into debugSessionOptions compact flag

Hi VS Code dev here 👋
As mentioned in microsoft/vscode#101429
We have change the noCompact flag to be compact flag and thus the default value is to not compact sessions. So this is opt-in. And we have changed that the name of the child session is displayed.
What I suggest python does:

Opts-into this behavior by passing compact: true to the debugSessionOptions in startDebugging
Improve the names of child sessions: for example to be NAME_OF_CONFIG + process ID

Let me know what you think, thanks!
fyi @int19h

The new behavior wrt names creates an unwanted difference between single-proc and multiproc sessions for the same scenario. From user's perspective, there's no value to seeing "Subprocess ..." in the tree, if the tree is compacted anyway - it's a distraction.
Nor can we just use parent process name for the child process to hack around it, because the debugger doesn't know in advance whether there's going to be only one such process (that would be collapsed), or multiple (that wouldn't). So if we always re-use the name, it would be very confusing in scenarios with no compacting, showing a tree of identically named processes.
Given that we're not going to opt in until https://github.com/microsoft/vscode/issues/101140 in any case - since it would be a regression for our users otherwise - perhaps the naming logic can also be tied to that? So the current behavior for names would still be the default, but if the controlling session is explicitly designated to be the parent one, then in addition to Stop/Disconnect behavior, it also applies to session names?


Refactoring labels

Add Kubernetes recommanded labels https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/
Ex:
---
# Source: trickster/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: trickster
    app.kubernetes.io/component: trickster-infra
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trickster
    app.kubernetes.io/part-of: trickster
    app.kubernetes.io/version: "1.5.4"
    helm.sh/chart: trickster-1.5.4
    tricksterproxy.io/version: "1.1"
  name: RELEASE-NAME-trickster
data:
  trickster.conf: |-
    [main]

    [frontend]
    listen_port = 8480
    connections_limit = 0

    [origins]

      [origins.default]
      origin_type = "prometheus"
      origin_url = "http://prometheus:9090"

    [metrics]
    listen_port = 8481
---
# Source: trickster/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: RELEASE-NAME-trickster
  labels:
    app: trickster
    app.kubernetes.io/component: trickster-infra
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trickster
    app.kubernetes.io/part-of: trickster
    app.kubernetes.io/version: "1.5.4"
    helm.sh/chart: trickster-1.5.4
    tricksterproxy.io/version: "1.1"
  name: RELEASE-NAME-trickster
spec:
  ports:
    - name: http
      port: 8480
      protocol: TCP
      targetPort: http
    - name: http-metrics
      port: 8481
      protocol: TCP
      targetPort: metrics
  selector:
    app: trickster
    app.kubernetes.io/component: trickster-infra
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trickster
    app.kubernetes.io/part-of: trickster
    app.kubernetes.io/version: "1.5.4"
    helm.sh/chart: trickster-1.5.4
    tricksterproxy.io/version: "1.1"
  type: "ClusterIP"
---
# Source: trickster/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: trickster
    app.kubernetes.io/component: trickster-infra
    app.kubernetes.io/instance: RELEASE-NAME
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: trickster
    app.kubernetes.io/part-of: trickster
    app.kubernetes.io/version: "1.5.4"
    helm.sh/chart: trickster-1.5.4
    tricksterproxy.io/version: "1.1"
  name: RELEASE-NAME-trickster
spec:
  selector:
    matchLabels:
      app: trickster
      app.kubernetes.io/name: trickster
      app.kubernetes.io/instance: RELEASE-NAME
  replicas: 1
  template:
    metadata:
      annotations:
        checksum/trickster-cfg: dd0e638923c8f32c6fb65904e0e41455a48c4dee1d1a00d95acc156aa3b16f63
      labels:
        app: trickster
        app.kubernetes.io/component: trickster-infra
        app.kubernetes.io/instance: RELEASE-NAME
        app.kubernetes.io/managed-by: Helm
        app.kubernetes.io/name: trickster
        app.kubernetes.io/part-of: trickster
        app.kubernetes.io/version: "1.5.4"
        helm.sh/chart: trickster-1.5.4
        tricksterproxy.io/version: "1.1"
    spec:
      containers:
        - name: trickster
          image: "tricksterproxy/trickster:1.1"
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: cfg-volume
              mountPath: /etc/trickster
          ports:
            - name: http
              containerPort: 8480
              protocol: TCP
            - name: metrics
              containerPort: 8481
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /trickster/ping
              port: http
          readinessProbe:
            httpGet:
              path: /trickster/ping
              port: http
          resources:
            {}
      volumes:
        - name: cfg-volume
          configMap:
            name: RELEASE-NAME-trickster
            items:
              - key: trickster.conf
                path: trickster.conf
        - name: cache-volume-generic
          emptyDir: {}

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

hey @nlamirault thanks for this. The linter is returning the following error:
63

Sure enough, when I curl this URL from the terminal, I get the same 404.

@nlamirault I updated the github actions version for the linter, which corrected the API location in the linter, so all of the tests are passing now. I will take a closer look at the content of the PR over the next 24 hours and let you know if there is any feedback, or otherwise will merge it and cut a new chart release. Thank you for your contribution, we really appreciate it!


End-to-end encryption (e2ee) settings

the current releasae detects if e2ee can be used but we need to have a flag in the settings.json file to be able to turn it on off .
..
  "e2eeSupport" : true
..

Implemented, Closing the issue


refactor(EventBuilder): Moved decision service and bucketing from EventBuilder to Optimizely

Summary

Moved decision service and bucketing from EventBuilder to Optimizely.
Pulled eventTag stuff into another method.
Revised activate & track methods to validate inputs.
Revised test cases of Optimizely & EventBuilder.

There are too many changes in this PR, still reviewing it.

build

Coverage increased (+0.01%) to 97.55% when pulling ceba1196809d10ba7d2371c8ad58bd4d423e6735 on arafay/refactor-event-builder into e5af71207184637472493e35ea95824f81033488 on master.


Incorrect logs parsing

Heyo,
I've been using v0.0.15 of this chart and everything was working ok - both logs and metrics.
After upgrade (don't remember exact version (>v0.1.x) I started receiving strange logs.
Logs look now like that:
<time> <output stream> F <log_line>
2023-08-29T19:19:00.559181246Z stdout F {"jsonLogKey": "value"}

which breaks json parsing in Loki.
Tested with the latest version (0.1.15) and problem still exists.

Glad things are working for you!
We're talking about the default parsing format in #100 . I'm going to close this issue in favor of that one.


TLSRoute promotion to standard

What would you like to be added:
This is an umbrella issue that gathers all the issues that need to be addressed in order to promote TLSRoute to standard.
As an additional and potentially useful resource, the following is the original google docs on the Gateway API TLS use cases: https://docs.google.com/document/d/17sctu2uMJtHmJTGtBi_awGB0YzoCLodtR6rUNmKMCs8/edit#heading=h.cxuq8vo8pcxm
### API improvement
- [ ] https://github.com/kubernetes-sigs/gateway-api/issues/2111

### Documentation
- [ ] #2643
- [ ] #1474
- [ ] https://github.com/kubernetes-sigs/gateway-api/issues/623

### Conformance
- [ ] https://github.com/kubernetes-sigs/gateway-api/issues/1579
- [ ] https://github.com/kubernetes-sigs/gateway-api/issues/2153

@mlavacca we probably need to address #2263 as well.  I think it was merged in error.  cc @robscott @shaneutt @youngnick @kate-osborn

/remove-lifecycle rotten
/remove-lifecycle stale
We have been discussing this issue in community meetings, and I volunteered to open a Discussion, which will reference this issue.


Use experimental_ref when using tf.Variable as key in Dicts

We can't put variables in a set/dictionary as variable.__hash__() is no longer available starting Tensorflow 2.0. This caused problems in the utilities._merge_leaf_components function. This PR fixes the issue and adds a test.

@awav tests fail because of wrong importing of positive transform in changepoint.py, which is a file I did not touch in this PR. I fixed the bug in #1133 , please merge that one first.


Update bundle, cloudwatch, sdk-core, ses, sns, ... to 2.25.50

About this PR
📦 Updates

software.amazon.awssdk:bundle
software.amazon.awssdk:cloudwatch
software.amazon.awssdk:sdk-core
software.amazon.awssdk:ses
software.amazon.awssdk:sns
software.amazon.awssdk:sqs
software.amazon.awssdk:ssm

from 2.25.15 to 2.25.50
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #3203.


ti-pruss-firmware: Update to <IP_ADDRESS>

This is supposed to fix remaining start-up issues, e.g. https://github.com/siemens/meta-iot2050/issues/108

Basic tests passed.


Twitter Links Not Loading with AnyLinkPreview.getMetadata

final url = await reader.readValue(Formats.uri);

Metadata? metadata = url == null
                ? null
                : await AnyLinkPreview.getMetadata(link: url.uri.toString());

flutter: AnyLinkPreview - Error in https://twitter.com/stats_feed/status/1705225138495513032?s=20 response (ClientException: Redirect loop detected, uri=/stats_feed/status/1705225138495513032?s=20)
is always returning null for Twitter cards. Is this expected?
other websites works.
Twitter links work with this lib: https://pub.dev/packages/ogp_data_extract
Might it be useful to merge their functionality in?

Hi,
I can see the above-mentioned URL is working fine.

However, I suggest re-testing this in the 3.0.2 version & reopening the ticket if the issue persists.
Thanks-you!