HDFS-14509 DN throws InvalidToken due to inequality of password when upgrade NN 2.x to 3.x

reference to jira

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
77
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
21
Maven dependency ordering for branch

+1
mvninstall
1172
trunk passed

+1
compile
193
trunk passed

+1
checkstyle
53
trunk passed

+1
mvnsite
121
trunk passed

+1
shadedclient
884
branch has no errors when building and testing our client artifacts.

+1
javadoc
82
trunk passed

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

+1
findbugs
304
trunk passed

_ Patch Compile Tests _

0
mvndep
11
Maven dependency ordering for patch

+1
mvninstall
103
the patch passed

+1
compile
200
the patch passed

-1
javac
200
hadoop-hdfs-project generated 1 new + 551 unchanged - 1 fixed = 552 total (was 552)

-0
checkstyle
45
hadoop-hdfs-project: The patch generated 1 new + 22 unchanged - 0 fixed = 23 total (was 22)

+1
mvnsite
110
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
779
patch has no errors when building and testing our client artifacts.

+1
javadoc
83
the patch passed

+1
findbugs
331
the patch passed

_ Other Tests _

+1
unit
124
hadoop-hdfs-client in the patch passed.

-1
unit
6361
hadoop-hdfs in the patch failed.

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

11102

Reason
Tests

Failed junit tests
hadoop.hdfs.tools.TestDFSZKFailoverController

hadoop.hdfs.server.namenode.ha.TestDNFencingWithReplication

hadoop.hdfs.server.namenode.TestNamenodeCapacityReport

hadoop.hdfs.security.token.block.TestBlockToken

hadoop.hdfs.server.namenode.ha.TestPipelinesFailover

hadoop.hdfs.server.namenode.ha.TestFailureToReadEdits

hadoop.hdfs.server.datanode.TestDirectoryScanner

hadoop.hdfs.server.namenode.ha.TestConsistentReadsObserver

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 44c45f378719 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 4e66cb9

Default Java
1.8.0_212

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/testReport/

Max. process+thread count
2776 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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
45
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
10
Maven dependency ordering for branch

+1
mvninstall
1110
trunk passed

+1
compile
217
trunk passed

+1
checkstyle
51
trunk passed

+1
mvnsite
105
trunk passed

+1
shadedclient
785
branch has no errors when building and testing our client artifacts.

+1
javadoc
73
trunk passed

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

+1
findbugs
272
trunk passed

_ Patch Compile Tests _

0
mvndep
11
Maven dependency ordering for patch

+1
mvninstall
97
the patch passed

+1
compile
205
the patch passed

-1
javac
205
hadoop-hdfs-project generated 1 new + 551 unchanged - 1 fixed = 552 total (was 552)

-0
checkstyle
44
hadoop-hdfs-project: The patch generated 1 new + 23 unchanged - 0 fixed = 24 total (was 23)

+1
mvnsite
103
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
677
patch has no errors when building and testing our client artifacts.

+1
javadoc
72
the patch passed

+1
findbugs
298
the patch passed

_ Other Tests _

+1
unit
121
hadoop-hdfs-client in the patch passed.

-1
unit
5083
hadoop-hdfs in the patch failed.

-1
asflicense
61
The patch generated 5 ASF License warnings.

9468

Reason
Tests

Failed junit tests
hadoop.hdfs.security.token.block.TestBlockToken

hadoop.hdfs.server.namenode.TestGetContentSummaryWithPermission

hadoop.hdfs.server.namenode.TestParallelImageWrite

hadoop.hdfs.server.namenode.TestEditLog

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux ad9602eb8be1 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / aebac6d

Default Java
1.8.0_212

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/testReport/

asflicense
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
4347 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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
45
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
10
Maven dependency ordering for branch

+1
mvninstall
1179
trunk passed

+1
compile
204
trunk passed

+1
checkstyle
46
trunk passed

+1
mvnsite
112
trunk passed

+1
shadedclient
784
branch has no errors when building and testing our client artifacts.

+1
javadoc
76
trunk passed

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

+1
findbugs
289
trunk passed

_ Patch Compile Tests _

0
mvndep
11
Maven dependency ordering for patch

+1
mvninstall
105
the patch passed

+1
compile
200
the patch passed

-1
javac
200
hadoop-hdfs-project generated 1 new + 551 unchanged - 1 fixed = 552 total (was 552)

-0
checkstyle
40
hadoop-hdfs-project: The patch generated 1 new + 22 unchanged - 0 fixed = 23 total (was 22)

+1
mvnsite
104
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
698
patch has no errors when building and testing our client artifacts.

+1
javadoc
79
the patch passed

+1
findbugs
316
the patch passed

_ Other Tests _

+1
unit
121
hadoop-hdfs-client in the patch passed.

-1
unit
4856
hadoop-hdfs in the patch failed.

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

9334

Reason
Tests

Failed junit tests
hadoop.hdfs.server.datanode.TestLargeBlockReport

hadoop.hdfs.security.token.block.TestBlockToken

hadoop.hdfs.server.namenode.ha.TestHAAppend

hadoop.hdfs.server.datanode.TestDirectoryScanner

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux a095fa27bd61 4.4.0-157-generic #185-Ubuntu SMP Tue Jul 23 09:17:01 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d086d05

Default Java
1.8.0_212

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/3/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/3/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/3/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/3/testReport/

Max. process+thread count
4146 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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
45
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
10
Maven dependency ordering for branch

+1
mvninstall
1090
trunk passed

+1
compile
206
trunk passed

+1
checkstyle
47
trunk passed

+1
mvnsite
107
trunk passed

+1
shadedclient
752
branch has no errors when building and testing our client artifacts.

+1
javadoc
77
trunk passed

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

+1
findbugs
280
trunk passed

_ Patch Compile Tests _

0
mvndep
10
Maven dependency ordering for patch

+1
mvninstall
97
the patch passed

+1
compile
181
the patch passed

-1
javac
181
hadoop-hdfs-project generated 1 new + 551 unchanged - 1 fixed = 552 total (was 552)

-0
checkstyle
42
hadoop-hdfs-project: The patch generated 1 new + 22 unchanged - 0 fixed = 23 total (was 22)

+1
mvnsite
92
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
669
patch has no errors when building and testing our client artifacts.

+1
javadoc
68
the patch passed

+1
findbugs
281
the patch passed

_ Other Tests _

+1
unit
104
hadoop-hdfs-client in the patch passed.

-1
unit
5974
hadoop-hdfs in the patch failed.

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

10190

Reason
Tests

Failed junit tests
hadoop.hdfs.TestDFSRename

hadoop.hdfs.server.namenode.ha.TestBootstrapAliasmap

hadoop.hdfs.TestDFSUpgradeFromImage

hadoop.hdfs.TestSafeModeWithStripedFile

hadoop.hdfs.TestAbandonBlock

hadoop.hdfs.server.datanode.TestLargeBlockReport

hadoop.hdfs.TestDecommissionWithStriped

hadoop.hdfs.server.namenode.TestAuditLogs

hadoop.hdfs.TestReplication

hadoop.hdfs.TestErasureCodingPoliciesWithRandomECPolicy

hadoop.hdfs.TestDFSStripedInputStream

hadoop.hdfs.tools.TestDFSAdminWithHA

hadoop.hdfs.server.balancer.TestBalancer

hadoop.hdfs.TestFileAppend2

hadoop.hdfs.TestBlockTokenWrappingQOP

hadoop.hdfs.server.namenode.TestNameEditsConfigs

hadoop.hdfs.TestEncryptionZonesWithKMS

hadoop.hdfs.server.diskbalancer.command.TestDiskBalancerCommand

hadoop.hdfs.server.namenode.snapshot.TestRenameWithSnapshots

hadoop.hdfs.server.namenode.TestAuditLoggerWithCommands

hadoop.hdfs.TestSetrepIncreasing

hadoop.hdfs.TestReconstructStripedFileWithRandomECPolicy

hadoop.hdfs.server.namenode.TestParallelImageWrite

hadoop.hdfs.server.diskbalancer.TestDiskBalancerWithMockMover

hadoop.hdfs.server.diskbalancer.TestDiskBalancer

hadoop.hdfs.server.balancer.TestBalancerRPCDelay

hadoop.hdfs.server.mover.TestMover

hadoop.hdfs.TestAclsEndToEnd

hadoop.hdfs.TestDFSPermission

hadoop.hdfs.server.blockmanagement.TestBlockManager

hadoop.hdfs.TestDistributedFileSystem

hadoop.hdfs.TestErasureCodingMultipleRacks

hadoop.hdfs.tools.offlineImageViewer.TestOfflineImageViewerWithStripedBlocks

hadoop.hdfs.server.namenode.TestNamenodeStorageDirectives

hadoop.hdfs.tools.TestECAdmin

hadoop.hdfs.server.datanode.TestNNHandlesCombinedBlockReport

hadoop.hdfs.server.blockmanagement.TestBlocksWithNotEnoughRacks

hadoop.hdfs.TestHFlush

hadoop.hdfs.TestDFSClientRetries

hadoop.hdfs.TestMultipleNNPortQOP

hadoop.hdfs.server.diskbalancer.TestDiskBalancerRPC

hadoop.hdfs.TestDFSStripedOutputStreamWithRandomECPolicy

hadoop.hdfs.server.datanode.TestDataNodeReconfiguration

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 4a3d9d394604 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 70b4617

Default Java
1.8.0_212

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/4/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/4/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/4/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/4/testReport/

Max. process+thread count
3865 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/4/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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
49
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
12
Maven dependency ordering for branch

+1
mvninstall
1229
trunk passed

+1
compile
222
trunk passed

+1
checkstyle
54
trunk passed

+1
mvnsite
117
trunk passed

+1
shadedclient
828
branch has no errors when building and testing our client artifacts.

+1
javadoc
82
trunk passed

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

+1
findbugs
328
trunk passed

_ Patch Compile Tests _

0
mvndep
9
Maven dependency ordering for patch

+1
mvninstall
107
the patch passed

+1
compile
208
the patch passed

-1
javac
208
hadoop-hdfs-project generated 1 new + 551 unchanged - 1 fixed = 552 total (was 552)

-0
checkstyle
48
hadoop-hdfs-project: The patch generated 1 new + 23 unchanged - 0 fixed = 24 total (was 23)

+1
mvnsite
109
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
717
patch has no errors when building and testing our client artifacts.

+1
javadoc
76
the patch passed

+1
findbugs
328
the patch passed

_ Other Tests _

+1
unit
118
hadoop-hdfs-client in the patch passed.

-1
unit
5341
hadoop-hdfs in the patch failed.

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

10030

Reason
Tests

Failed junit tests
hadoop.hdfs.TestMultipleNNPortQOP

hadoop.hdfs.TestReconstructStripedFileWithRandomECPolicy

hadoop.hdfs.server.datanode.TestLargeBlockReport

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 18ee53b09409 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 397a563

Default Java
1.8.0_212

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/5/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/5/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/5/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/5/testReport/

Max. process+thread count
4645 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/5/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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
53
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
9
Maven dependency ordering for branch

+1
mvninstall
1108
trunk passed

+1
compile
190
trunk passed

+1
checkstyle
44
trunk passed

+1
mvnsite
96
trunk passed

+1
shadedclient
751
branch has no errors when building and testing our client artifacts.

+1
javadoc
77
trunk passed

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

-1
findbugs
122
hadoop-hdfs-client in trunk failed.

_ Patch Compile Tests _

0
mvndep
9
Maven dependency ordering for patch

+1
mvninstall
104
the patch passed

+1
compile
198
the patch passed

-1
javac
198
hadoop-hdfs-project generated 1 new + 551 unchanged - 1 fixed = 552 total (was 552)

-0
checkstyle
43
hadoop-hdfs-project: The patch generated 1 new + 23 unchanged - 0 fixed = 24 total (was 23)

+1
mvnsite
96
the patch passed

-1
whitespace
0
The patch has 186 line(s) that end in whitespace. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-1
whitespace
1
The patch 600  line(s) with tabs.

+1
shadedclient
759
patch has no errors when building and testing our client artifacts.

+1
javadoc
68
the patch passed

+1
findbugs
277
the patch passed

_ Other Tests _

+1
unit
104
hadoop-hdfs-client in the patch passed.

-1
unit
5030
hadoop-hdfs in the patch failed.

-1
asflicense
32
The patch generated 1 ASF License warnings.

9372

Reason
Tests

Failed junit tests
hadoop.hdfs.security.token.block.TestBlockToken

hadoop.hdfs.server.datanode.fsdataset.impl.TestSpaceReservation

hadoop.hdfs.TestMultipleNNPortQOP

hadoop.hdfs.server.datanode.fsdataset.impl.TestLazyPersistFiles

hadoop.hdfs.server.datanode.fsdataset.impl.TestLazyWriter

hadoop.hdfs.server.blockmanagement.TestUnderReplicatedBlocks

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux e5709d3437bd 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / e356e4f

Default Java
1.8.0_222

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs-client.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

whitespace
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/whitespace-eol.txt

whitespace
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/whitespace-tabs.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/testReport/

asflicense
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
4011 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/6/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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
58
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

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

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

_ trunk Compile Tests _

0
mvndep
21
Maven dependency ordering for branch

+1
mvninstall
1310
trunk passed

+1
compile
244
trunk passed

+1
checkstyle
68
trunk passed

+1
mvnsite
141
trunk passed

+1
shadedclient
994
branch has no errors when building and testing our client artifacts.

+1
javadoc
121
trunk passed

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

+1
findbugs
320
trunk passed

_ Patch Compile Tests _

0
mvndep
14
Maven dependency ordering for patch

+1
mvninstall
119
the patch passed

+1
compile
211
the patch passed

-1
javac
211
hadoop-hdfs-project generated 1 new + 690 unchanged - 1 fixed = 691 total (was 691)

-0
checkstyle
55
hadoop-hdfs-project: The patch generated 1 new + 22 unchanged - 0 fixed = 23 total (was 22)

+1
mvnsite
117
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
788
patch has no errors when building and testing our client artifacts.

+1
javadoc
116
the patch passed

+1
findbugs
319
the patch passed

_ Other Tests _

+1
unit
124
hadoop-hdfs-client in the patch passed.

-1
unit
5224
hadoop-hdfs in the patch failed.

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

10410

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.TestRedudantBlocks

hadoop.hdfs.TestMultipleNNPortQOP

hadoop.hdfs.tools.TestDFSZKFailoverController

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1129

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / c0edc84

Default Java
1.8.0_222

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/diff-compile-javac-hadoop-hdfs-project.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/diff-checkstyle-hadoop-hdfs-project.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/testReport/

Max. process+thread count
4564 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-client hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1129/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

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

This message was automatically generated.


Documentation for proposed authn features

This patch contains the documentation portions of proposed authentication changes discussed in #13697, to get some feedback on what the end-result should look like.  To sum up the changes being proposed:

If the daemon is started with the -a/--authn flag, it requires clients to authenticate to it.  If not, it doesn't, preserving the previous behavior.

The daemon will offer support for HTTP Basic authentication if the daemon is started with either the --libsasl2 or --htpasswd options, using a "realm" name specified using the --realm option.

If the daemon is started with the --htpasswd option, it will attempt to run an "htpasswd" helper binary to check passwords using the specified htpasswd file.

If the daemon is started with the --libsasl2 option and built with support for it, it will call the SASL library to check passwords for the docker service.  The library can, in turn, be configured to ask saslauthd to check passwords using whatever facilities it's configured to use.

If the daemon is built with GSSAPI support, it will check the default keytab file, or one specified using the --keytab option, for acceptor creds, and if it finds them, will offer Negotiate authentication.

If the daemon is started with the -U/--local-auth flag, it will attempt to authenticate clients by asking the kernel to identify the client user.  On Linux systems, this is done by reading the client's UnixCredentials, and is only supported for "unix" connections.

If the daemon is started with the --certmap option, it will attempt to use specified Docker plugins to identify HTTPS clients by their client certificates.

If the daemon is started with the --authn-plugins option, it will also call out to authenticators implemented by the specified Docker plugins.

When a daemon responds to a client request with a 401 error code, the client will attempt to authenticate using whatever scheme the daemon offers as part of the error message and try again.

When attempting Basic authentication, the client will use values passed in as values for the --basicusername and --basicpassword options.  If either the password or both values are not specified on the command line, it will attempt to read the values to use from the $DOCKER_AUTHN_USERID and $DOCKER_AUTHN_PASSWORD variables in the environment.  If those are not set, and the client has a controlling terminal, it will prompt for the values.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "authn-docs" git@github.com:nalind/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Thanks @nalind, just had a quick glance; wondering if we should have a generic --authn-opt flag for the options, e.g. --authn-opt driver=basic --authn-opt user=foo --authn-opt pass=secret.
Using "opts" is used in other parts of docker as well (if different drivers/plugins are used), so that we don't overload docker with options that can only be used with a specific driver/plugin.
Again, just thinking out loud and without giving it a lot of thought

@thaJeztah In the client, that makes sense, and points to a way to pass in a Bearer token.  The daemon can offer more than one scheme at a time, allowing the client to select which to attempt based on what it can supply, so forcing a particular scheme using options shouldn't be necessary, but passing scheme-specific options (basic.realm) would make sense.  They might need to be namespaced by scheme, as is done for storage drivers, but that's easy enough to document.

Okay, revised to use --authn-opt for specifying most options, and adding some longer-form documentation in docs/extend.

I am wondering how will this integrate with Swarm? Will Swarm also have an auth plugin or will it simply forward requests to one of many Docker engines?

That would depend on whether or not that's a useful feature for Swarm.
My guess is having the daemons require clients to connect using TLS with client certificates would be it as far as the manager-daemon connections go.
If there's a use case for it, the manager could start requiring clients to authenticate to it, and since we're talking about regular HTTP authentication on the wire here, I'd expect the client changes here would be compatible with such a feature, if it were to be implemented.
That's all conjecture, of course.

Absorbed into #18514, so closing.


compiler/dart2js/analyze_test.dart is broken

$ python tools/test.py -m release -ax64 --checked --use-sdk --reset-browser-configuration dart2js/analyze_test
...
Malformed output from dartanalyzer:
No dart files found at: /usr/local/google/home/aam/dart-sdk1/sdk/tests/compiler/dart2js/path
Running analyzer took: 0:00:01.120994.

stderr:
Non-empty output from analyzer.

culprit seems to be https://github.com/dart-lang/sdk/commit/d935a7fd00f8727ff730dff2a0273999fa7faaa7

Thank you, Alex and Konstantin. I'll take a look at this. I think I need to addd a test which analyzes package:testing.


Not working (yet?) with the DallasTemperature library

I'm trying to use the chip with the DallasTemperature library, but it doesn't seem to work: https://wokwi.com/projects/351023152576332372
when connecting a logic analyzer to the DQ pin, and use PulseView's 1-Wire Network Layer analyzer, it shows some errors:

I'm trying to use the chip with the DallasTemperature library, but it doesn't seem to work: https://wokwi.com/projects/351023152576332372
when connecting a logic analyzer to the DQ pin, and use PulseView's 1-Wire Network Layer analyzer, it shows some errors:

@urish
The test program shows usage of the OneWire library and the sequence of commands that was used to test.
Can you show me what you have tried to use?
The repo has a capture that shows the test run and appears to be working as intended

@urish - one issue could be that the serial number is not of a Dallas DS18B20 but rather a sample valid OneWire address

@urish  ok, some update (still not sure who's wrong here...):
I noticed a couple of things:

in your capture, and the linked program, the library starts quickly. It seems that PulseView requires that some time elapses before the reset pulse is considered valid (although the software does not care and handles the signals correctly). When I added a delay of 1ms before sensors.begin(), the captures started showing up correctly.
It appears that after requesting conversion there is a pulse on the bus immediately. I'm still not sure what that is.

The debug code shows this :
[chip-ds18b20] ow_ctx: resetting state from ST_RESET_INIT
[chip-ds18b20] 38801062 sm_push_event< sm_read_byte (ctx: 0x134c0) next state=> ST_READ_RUNNING(0)
[chip-ds18b20] on_master_write_done_pin_chg: ctx->state after callback 5 (was set by us to 0)
[chip-ds18b20] 38801062 sm_push_event< sm_sig (ctx: 0x13470) next state=> ST_RESET_INIT(0)
[chip-ds18b20] 38811375 sm_push_event> (38811) sm_sig (ctx:0x13470) ST_RESET_INIT[EV_PIN_CHG]: on_reset_init_pin_chg( 0 ) -> 0x8
[chip-ds18b20] on_reset_init_pin_chg - ctx: 0x13470
[chip-ds18b20] 38811375 sm_push_event< sm_sig (ctx: 0x13470) next state=> ST_RESET_WAIT_RELEASE(1)
[chip-ds18b20] 38813937 sm_push_event> (2) sm_sig (ctx:0x13470) ST_RESET_WAIT_RELEASE[EV_PIN_CHG]: on_reset_wait_release_pin_chg( 1 ) -> 0x9
[chip-ds18b20] 38813937 sm_push_event< sm_sig (ctx: 0x13470) next state=> ST_RESET_WAIT_PRESENCE(2)
I am not sure why the master issues a reset pulse so quickly after the command but does not follow it up with another command.
I am also not sure why the master changes the bus back to 1.
I don't think the custom chip is strictly incorrect here.
However, the chip could benefit from some protection logic  - among the todo's I still have to c

closing this issue due to misbehaviour of DallasTemperature as well as making the chip more defensive

Thanks!


Motoko encrypted-notes-dapp-vetkd: Does not deploy

Does not deploy due to cannot resolve file paths

@jessiemongeon1, thanks for the report! can you elaborate what you mean with "old URLs"? What error do you see? I just tried to compile and deploy and run the dapp for both build environments (export BUILD_ENV=rust and export BUILD_ENV=motoko), and it worked for both, using dfx 0.23.0.

@fspreiss by URLs I mean file paths (I should have been clearer in the initial issue), I get the following error when trying to deploy:

@jessiemongeon1, which steps are you performing before you arrive at this error? Are you following the instructions of the README? At which step do you see the mentioned error? Note that the deployment instructions of the README are to a big part automated in the Makefile in the test-e2e target, so you could first try make clean to clean your environment, and then make test-e2e.

@jessiemongeon1, also note that the file you are seemingly missing is generated in Step 10 of the instructions in the README. Step 10 says: dfx generate "encrypted_notes_$BUILD_ENV": possibly you didn't have a BUILD_ENV set (see Step1 of the instructions), which could have caused Step10 to fail.

Yes, I followed the instructions in the README and set the BUILD_ENV variable as the README says. Running make clean and make test-e2e seems to have resolved the issue. Thanks!

Happy to hear! Let me know if you think we should adapt the README to recommend running, e.g., make clean at the beginning (e.g., if people face deployment issues).


DevEnv: Source mapping of ST to JS does not work from VSCode with Firefox

When ST is transpiled to JS, source maps are generated.
This enables you to set debug breakpoints in ST files using VSCode.
For Chrome and Edge, this works as expecten, but in Firefox, the breakpoints are ignored.
The "Debugger for Firefox" extension is installed in VSCode.
The workaround for Firefox is to copy the full ST source code from the src folder to the output website,
next to the generated JS code.
But it would be nicer if Firefox would just work like Crome and Edge.
I've tried setting mapping paths, but could not get it to work.

Fixed with commit 1ff9f66 : "Build: Enabled Firefox debugging with source maps for all browser projects".


release: bump to version 3.4.0

Updated Readme to show latest release of CDN

this problema was solved in another pr


Accept async middlewares

Description
Most Vite middlewares need to be async especially because many of Vite's own APIs that you would be calling like ssrLoadModule are async. However, middlewares.use does not accept async methods. This makes for a pretty awkward dance to handle promise rejections and worse means that many users will overlook error handling altogether resulting in server crashes
Also, it would make sense for Vite's errorMiddleware to be called in the .catch when invoking the promise as the rejection handler, but that's impossible for users to do as it's not exported. However, this could be done internally in Vite.
Suggested solution
Override middlewares.use to accept async implementations or add a middlewares.useAsync method
Alternative

have every consumer add a workaround for it instead of adding it directly in Vite. also expose the errorMiddleware or have every consumer wrap their implementation in a try/catch so that it can never throw and implement their own custom error handling
switch away from connect to another server implementation which has native async handling like koa

Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Perhaps we could patch connect so that it handles .catch()?
IIUC here and here could have a trailing .catch(err => {}) which would call next(err), and it should properly work again. Not sure if they still accept changes upstream though given the time.

Express 5 has added support for this:

Request middleware and handlers that return rejected promises are now handled by forwarding the rejected value as an Error to the error handling middleware. This means that using async functions as middleware and handlers are easier than ever. When an error is thrown in an async function or a rejected promise is awaited inside an async function, those errors will be passed to the error handler as if calling next(err).

I just tested and polka has support for it as well. If there's an unhandled error in an async handler then options.onError will be called. You can also see that its middleware returns a Promisable in its types.
Perhaps we should switch to polka 1.0.0-next.25 as SvelteKit has done since polka is both better maintained and supports async middleware.

Ah, there's a PR to switch to polka. So this would be addressed by https://github.com/vitejs/vite/pull/17569


BM3DCPU won't allow Profile.VERY_NOISY because of CUDA

from vstools import vs, initialize_clip, set_output
from vsdenoise import BM3DCPU, Profile

clip = vs.core.std.BlankClip(format=vs.YUV420P16)
clip = initialize_clip(clip)
clip = BM3DCPU.denoise(clip, profile=Profile.VERY_NOISY)
set_output(clip)

# Results in ValueError: Profile "VERY_NOISY" is not supported! (BM3DCuda)

It seems like final() only evaluates truthiness of elif not cuda but as far as I can tell the plugin is passed and core.lazy.bm3dcpu is truthy so the non-CUDA conditional branch is never taken.

BM3DCPU and BM3DCUDA have the same implementation/logic which doesn't allow for that preset

Then https://github.com/Jaded-Encoding-Thaumaturgy/vs-denoise/blob/b08faf3ee7ae909ca5e912b63c88d0bf39494d3d/vsdenoise/bm3d.py#L533 should just pass True instead of self.plugin. And the error message should be more clear about the classes which do and don't support it.


GPS functional tests

Summary
It's nice to have automated tests that check the validity of the GPS data coming from our sensor.
rel #39
Acceptance Criteria

[x] identify which information is critical to pod performance
[x] write functional tests to assert the validity of that info. Something that compares GPS data to a 3rd party source maybe*

are we in North America?
are we connected to any satellites?
if the comparison is too hard, we can brainstorm other options

[ ] CI?

Test summary documented on Google Drive: Albertaloop\1 - Technical Division\1 - Electrical Team\1 - Software Group\6 - Testing Documents\T_SWE_TESTING - GPS.gdoc
GPS will have to be replaced because this product is reliant on the Arduino Serial.Print() function, which stops working when any other interrupt source occurs.

Test summary documented on Google Drive: Albertaloop\1 - Technical Division\1 - Electrical Team\1 - Software Group\6 - Testing Documents\T_SWE_TESTING - GPS.gdoc
GPS will have to be replaced because this product is reliant on the Arduino Serial.Print() function, which stops working when any other interrupt source occurs.

Could you push your code and link to any resources you are using to debug this problem?

I added some more results for stationary GPS measurement outputs to the following file on our Google drive:
Albertaloop\1 - Technical Division\1 - Electrical Team\1 - Software Group\6 - Testing Documents\Restuls\GPS-2022-07-15.gdoc
We need to copy these results into a txt files and parse the input into a Python file so we can plot the lat-lon coordinates and calculated distance.


Golden Record / BPN Service Release 23.12 Security Acceptance Criteria

Release Security 23.12
Source in Catena-X Confluence and Expert Contacts here(Source only accessible for Catena-X Consortia members in current transition phase).

[ ] Threat Modelling Analysis results
Analysis completed (operations excluded):

List of risks generated or updated, rated & actions defined
Risks accepted or mitigation actions implemented and tested
no high threats acceptable

Artifact Repository:

risk register (decentral on Catena-X confluence)

Prime Contacts:

Security Team: SEC0

[ ] Static Application Security Testing (SAST)

code must be scanned weekly with Veracode tool
medium risks require mitigation statement
high and above not accepted

Best Practise:

Confirm relevant repository as early as possible to SEC team to enable regular, automated scans. Evidence required for Gate approval.

Artifact Repository:

Veracode UI
(+ GitHub Action)

Prime Contacts:

Security Team: SEC1

[ ] Dynamic Application Security Testing (DAST)
incl API testing (if applicable)

all findings assessed
high & very high findings mitigated
evidence by re-scan

Best Practise:

Confirm relevant repository as early as possible to SEC team to enable regular, automated scans. Evidence required for Gate approval.

Artifact Repository:

INVICTI tool

Prime Contacts:

Security Team: SEC3 SEC4

[ ] Secret scanning
Scan executed centrally by SEC team and ZERO valid findings
Artifact Repository:

Veracode or alternative tool
GitHub Secret Scanning
GitGuardian

Best Practise:

Confirm relevant repository as early as possible to SEC team to enable regular, automated scans. Evidence required for Gate approval.

Prime Contact:

Security Team: SEC1

[ ] Software Composition Analysis (SCA)
Dependencies must be scanned with Veracode tool with regards to vulnerability

high and above not accepted
FOSS whitelist policy has to be passed

Best Practise:

Confirm relevant repository as early as possible to SEC team to enable regular, automated scans. Evidence required for Gate approval.

Artifact Repository:

Veracode UI
(& GitHub Action)

Prime Contacts:

Security Team: SEC1

[ ] Container Scan conducted
All containers in GitHub Packages must be scanned

High / Critical findings not accepted

Best Practise:

Confirm relevant repository as early as possible to SEC team to enable regular, automated scans. Evidence required for Gate approval.

Artifact Repository:

Trivy
via nightly GitHub Action

Prime Contacts:

Security Team: SEC2

[ ] Infrastructure as Code
IaC code must be scanned.

Error findings not accepted

Best Practise:

Confirm relevant repository as early as possible to SEC team to enable regular, automated scans. Evidence required for Gate approval.

Artifact Repository:

KICS or alternative tool
via nightly GitHub Action

Prime Contacts:

Security Team: SEC2

Threat Modelling Analysis results were updated within last release 23.09 https://confluence.catena-x.net/x/Cm1HAw. No significant changes. Next update is planned in 24.03 with the upcoming breaking change of the generic endpoint and the implementation of the orchestrator. @kelaja

Static Application Security Testing (SAST): No high risks found can you check @PiotrStys

Dynamic Application Security Testing (DAST): The pen environment was setup for 21.12.2023 @PiotrStys can you check

Software Composition Analysis (SCA): No high findings @klaudiaZF @Gitleena

Container Scan conducted: No high findings @scherersebastian can you confirm

Infrastructure as Code: No high findings @scherersebastian please confirm

@rybtim, can you please provide the updated URL of the deployment?

@kelaja: Threat Modelling Analysis passed

@rybtim, can you please provide the updated URL of the deployment?

Please find below links for deployed Pen environment
https://argo.dev.demo.catena-x.net/applications/argocd/bpdm-pen?view=tree&resource=
https://business-partners-pen.dev.demo.catena-x.net/bridge/ui/swagger-ui/index.html
https://business-partners-pen.dev.demo.catena-x.net/companies/test-company/ui/swagger-ui/index.html
https://business-partners-pen.dev.demo.catena-x.net/pool/ui/swagger-ui/index.html

@SujitMBRDI, @rybtim
Sorry but this is not clear enough to me.
Are those URLs alternative deployments and is this enough to scan one of them?
I believe that so far we used the one below for assessments:
https://business-partners-pen.dev.demo.catena-x.net/pool
Does that seem to work for this QG as well?

Hi, can someone provide a link to project name in Veracode for SCA ?

@SujitMBRDI, @rybtim Sorry but this is not clear enough to me.
Are those URLs alternative deployments and is this enough to scan one of them? I believe that so far we used the one below for assessments: https://business-partners-pen.dev.demo.catena-x.net/pool
Does that seem to work for this QG as well?

The last time we had two scans: One for the pool and one for the test-company subpath. These two would need to be executed again:

Hi All,
SCA passed

IaC/ KICS passed.
Container trivys scans passed


Wrongly reading client trust store to validate JWT signature.

The logic at [1] to read the certificate of the Service provider from client trust store is wrong. We should be reading it from tenant's keystore.
[1] - https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/openidconnect/RequestObjectValidatorImpl.java#L211-L219

With https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/791 we have moved to DB backed Service Provider public certs completely. Therefore this issue won't be present.


Update to AsyncKeyedLock 6.1.1

Cheers, FYI you can now step into and debug AsyncKeyedLock via the NuGet package :)

Thanks Mark! Appreciate it! (And apologies for the slew of undocumented updates recently. Hopefully they were able to be discerned and weren't too disruptive.)


Issue138

Issue
#138
Intent
When fetch fail in FileUploader, it should be caught.
Implementation
Added .catch() to fetch call.
Checks

[x] Code is formatted correctly (npm run lint:fix).
[x] All unit tests are passing (npm test).

[x] All sasjs-tests are passing (instructions available here).

looks ok to me, branch needs updating though, and checks are failing


Some color in monitor tab

Is your feature request related to a problem? Please describe
Sometime a monitors fail, or don't work as expected. There is a column that indicate the last state, but when you have hundreds of monitors, it is a bit hard to find the one who fail.
Describe the solution you'd like
Put the line in red if for exemple there was no result (total : 0)
Put the line in orange if something seems wrong (like described in #2477)
Or maybe an icon to replace the "zZz" that would cath the eye ?
I know the problem is that, on the next tick thoses information could be lost, so maybe have the user to reset them manually by editing the item ? I know editing a monitors reset the status, so maybe the program could skipp any monitors with error until the user fixes them ?
Describe alternatives you've considered
reading one by one the lines or ordering by line.

I added icons just now as I'm not a big fan of highlighting full rows:

The green/red should be eye-catching enough I believe. What do you think?

Yeah it's fine ! Color is working, especially red and green since they are used everywhere for danger and "ok" indication.


[Bug]: Labeling gets stuck and needs to be rerun to get results

Describe the bug
While labeling a dataset, sometimes the labeler gets stuck. Restarting the labeling process fixes this.
To Reproduce
Label a 100 example dataset multiple times using gpt3.5
Expected behavior
Should not get stuck
Possible reason
This is possibly due to the timeout being too large when the request is sent to OpenAI and needs the request timeout to be lower to around 30s

Setting the default timeout for models as 30s fixes the timeout issue


install and setup requirements for source and rpm builds

This prevents the error I was seeing in which pbr_json couldn't be imported.  Also resolve issue 30 opened by gholms so we don't require argparse if python == 2.7.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

test this please

test this please


Add netbsd to conditional compilation for keepalive

Just a small tweak to allow netbsd targets to compile correctly

Thanks!

Woo!  Thanks for all the hard work on Rust and the ecosystem!


Change delete on storage locations to deactivate

Resolves #3104
Description

I extended the usage of the Discard gem to the Storage Location model and added to the UI to allow people to soft delete Storage Locations, given that the location has no inventory!
Following feedback in this PR, I moved the responsibility for ensuring we don't delete locations with inventory to a service object.
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?
I added some request specs and a system spec. I think we could be more stringent, but I also think this feels like the basics are covered. :)
If you want to test this manually, you should try deleting a Storage Location with items and one without, then reactivating them.
Screenshots

An example of the deactivate/reactivate buttons:

Flash error message:

I believe this is ready to review. I rebased and pushed to catch the branch up. Let me know if anything needs more work!

@edwinthinks Let me know if you think this covers what you expected!

@edwinthinks I think I addressed your comments? Does this feel good to merge?

@edwinthinks Thanks for noticing the spec failures, I think it's good now!


Lute/reification step1

I have changed the AppConfig setting, created a new test_reification.py file and I have made the first example test case passed by using the reify. Now:
Do I address all the examples of test_parsing that have been copied into test_reification as if they needed reification, therefore modifying all of them?
For the literals such as k_sn_u_a, it should now be displayed as k_sn_u(a), right?
Addressing issues #5 and #29

I have changed the AppConfig setting, created a new test_reification.py file and I have made the first example test case passed by using the reify. Now:
Do I address all the examples of test_parsing that have been copied into test_reification as if they needed reification, therefore modifying all of them?
For the literals such as k_sn_u_a, it should now be displayed as k_sn_u(a), right?

I think that what we are going to go with would be something like k(u(-a)), but there are some intermediate steps before that.
I added a couple of tests and everything looks good.
I will add another issue for the next step.
Can you merge the last changes in develop?

Addressing issue #29. Ready for merge.

Addressing issue #29. I think it is now ready for merge @jorgefandinno

It seems to me that it is now ready.
Is that correct?


fix: node version

ref: #52

@Shivansh-yadav13 I think this PR is misplaced.. (inside your repo instead of origin)

Moved to: https://github.com/node-casbin/typeorm-adapter/pull/53


Any plans to make mirage agnostic from ember?

@samselikoff It'll be great if it could be used independent of ember.
It's the best jsonapi mock tool i found, but unfortunately ember isn't in our stack :(
Thanks in advance!

@nicsefer more details available at https://github.com/samselikoff/ember-cli-mirage/issues/1233 Some folks are working on it 😀  (but it may be in rough shape) will close here for now

How is it all going? We want to use Mirage on a react project.

@QuantumInformation Hi there - not at this point in time! I'd say @cowboyd's fork is your best bet.

@QuantumInformation We're maintaining a cross-framework fork of mirage over at Bigtest https://github.com/bigtestjs/mirage

hows it all going?

@QuantumInformation Cowboy's fork still works, but we have started working on this. We have a version here that you can keep your eyes on. The current release there works in React and Vue apps but there's some more cleanup work to get it properly extracted and rework Ember CLI Mirage to consume it.
The current priority is to release Ember CLI Mirage 1.0, including taking care of any outstanding bugs. Then we'll be able to shift focus to the proper extraction.

awesome thanks!!!!
Kind regards
Nikos Katsikanis
On Mon, 15 Apr 2019 at 16:04, Sam Selikoff<EMAIL_ADDRESS>wrote:

@QuantumInformation https://github.com/QuantumInformation Cowboy's fork
still works, but we have started working on this. We have a version here
https://github.com/miragejs/server that you can keep your eyes on. The
current release there works in React and Vue apps but there's some more
cleanup work to get it properly extracted and rework Ember CLI Mirage to
consume it.
The current priority is to release Ember CLI Mirage 1.0, including taking
care of any outstanding bugs. Then we'll be able to shift focus to the
proper extraction.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/samselikoff/ember-cli-mirage/issues/1243#issuecomment-483290239,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANN9gn_FU9V0_78OoZjJaGkBHDq9UiQks5vhJUOgaJpZM4RHK-c
.


Update install-xcode.sh to adopt latest from strap/strap.sh

See https://github.com/MikeMcQuaid/strap/blob/master/bin/strap.sh

Closed by https://github.com/acourtneybrown/dotfiles/pull/93


Mean: Use latest payment streaming package

Hello!
I'm updating mean streaming proposals to use the latest version of @mean-dao/payment-streaming. There are a few breaking changes in it, mostly related to renaming

@welldan97 payment-streaming SDK dependency can be updated to stable v4.0.0 now.

Hi @abrzezinski94, we updated the our meanfi SDK package, and here I'm applying the changes for relevant meanfi integration. Can you review, please

Hi, @abrzezinski94!
Just wanted to check in on the pull request I submitted a few months ago. I was hoping to see if there's any progress or feedback on it.
Let me know if there's anything else I can provide or do to help move things along. Thanks a lot for your time, and looking forward to hearing from you!

@nramadas, @asktree , @SebastianBor I know you are very busy, yet can we push this through? There are just updates to mean streaming sdk, nothing more. We would need this updates for further prs

@nramadas, @asktree , @SebastianBor I know you are very busy, yet can we push this through? There are just updates to mean streaming sdk, nothing more. We would need this updates for further prs

Ah hello please resolve conflicts and ill merge it immediately

Thank you so much @abrzezinski94, that was fast


Use automatic chunking in from_zarr

Previously we would use whatever chunking was present in the zarr array.
However storage formats often store smaller chunks than are ideal for
compute frameworks, leading in too many tasks that are too small.
Now we just let da.from_array handle this.  It already has logic to
choose a good chunksize that both respects the alignment within the
zarr array and the chunk size in configuration (usually 128 MiB by
default)
cc @alimanfoo @sofroniewn @tlambert03

Libraries like pangeo-data/rechunker want to have exact control over the
chunk sizes so that they can reliably predict memory usage. I haven't
verified that the changes here impact rechunker or libraries like it (and
won't have time to near term), but this feels like the kind of thing that
might have a negative impact.
On Mon, Jul 20, 2020 at 9:49 AM Matthew Rocklin<EMAIL_ADDRESS>wrote:

@mrocklin commented on this pull request.
In dask/array/core.py
https://github.com/dask/dask/pull/6419#discussion_r457457761:

@@ -2841,7 +2841,7 @@ def from_array(

def from_zarr(

url, component=None, storage_options=None, chunks=None, name=None, **kwargs

url, component=None, storage_options=None, chunks="auto", name=None, **kwargs

We could. Can I ask for additional motivation though? We don't currently
do this for HDF5 or NetCDF or any other format. Why would we do this for
Zarr? Why do we care about the old behavior? I expect that adding docs on
this is just as likely to lead people astray as it is to help them.
As a reminder, the automatic chunking is decently smart and we haven't
ever gotten complaints about the choices that it makes, despite pretty
heavy usage. It will find a chunking that aligns with the existing chunking
in storage, but is mildly larger in other dimensions if necessary.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/6419#discussion_r457457761, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAOIULQN5OEGCJFNNHWELR4RKQXANCNFSM4O5N3PCQ
.

Libraries like pangeo-data/rechunker want to have exact control over the
chunk sizes so that they can reliably predict memory usage

They still have that exact control.  They can specify chunks manually just like before and in from_array.  The only thing that we've changed here is the default when the user doesn't provide any information.  The result is that users will get larger chunks if their zarr arrays are chunked too finely to be optimal for Dask.

but this feels like the kind of thing that might have a negative impact.

FWIW I would be surprised to see this change have a negative impact on a typical workflow.

I haven't verified that the changes here impact rechunker or libraries like it (and won't have time to near term),

Is there someone that we can ping from that project who might be able to weigh in here?

Maybe @rabernat could weigh in?

I agree that the proposed changes would be useful in many cases. But I would prefer to see a warning + deprecation cycle, rather than a sudden change in the default behavior. I have quite a bit of code that relies on the assumption that from_zarr will return the native zarr chunks.
There also may be performance impacts. By using larger chunks than the on-disk chunks, we leave it to zarr to figure out how to read those batches of chunks. This currently occurs in a serial / blocking fashion. Switching to async in zarr (see https://github.com/zarr-developers/zarr-python/issues/536), could speed that up a lot.

They can specify chunks manually just like before and in from_array

If you are reading an array directly from a url or path, you don't necessarily know the native chunks. In that case, you have to open up the array first with zarr, examine the metadata, and then call from_zarr. It would be nice to have some kind of option to force dask to use the native chunks without the user explicitly specifying what they are.
Downstream, it would be good to think about how xarray could use this feature effectively.

I have quite a bit of code that relies on the assumption that from_zarr will return the native zarr chunks.

If you have time I'd be curious to learn more about situations where this would break things.

There also may be performance impacts. By using larger chunks than the on-disk chunks, we leave it to zarr to figure out how to read those batches of chunks. This currently occurs in a serial / blocking fashion.

My guess is that in most of these situations there are several chunks still active.  Alternatively, if we wanted to ensure some concurrency then this is something that we could push up to the more general logic in from_array.  We could encourage dask array to use the chunksize in configuration (which we do now) unless there are very few chunks, in which case it should slim down chunk sizes.

If you are reading an array directly from a url or path, you don't necessarily know the native chunks. In that case, you have to open up the array first with zarr, examine the metadata, and then call from_zarr. It would be nice to have some kind of option to force dask to use the native chunks without the user explicitly specifying what they are.

This is also the case with HDF/NetCDF today.
In both of these cases I would prefer that we not have special logic just for Zarr, but instead focus on the upstream from_array function so that other formats (hdf, netcdf, tiledb, ...) benefit and we have consistent behavior across formats.

Have we tried this with a Zarr object (maybe from Pangeo)? Perhaps that would help identify relevant issues/alleviate concerns.

I have quite a bit of code that relies on the assumption that from_zarr will return the native zarr chunks.

Checking in here.  Would it be possible to learn more about these issues?  Recall that the heuristics in from_array do respect native storage chunk boundaries, they just sometimes include many of them in a single dask array chunk.
I don't think that we've ever run into an issue with this policy with HDF/NetCDF.
If we're going to block progress on this PR then I think it would be good to get more information on what exactly would cause the break.


a question about ffi

if ffi and jni are both used and based on same c library  will that be a problem?

That should be fine.


Initialize in hidden modal

Hi, i'm trying to initialize Fotorama in a Bootstrap 3 modal which will be used with fotorama.load(data) and then shown, so that i can reuse the modal and gallery multiple times on the page.
Unfortunately Fotorama doesn't seem to initialize when the element is hidden, it only works if i show the modal first, close it, initialize Fotorama, load the data, and then show it again.
Could it be fixed so that Fotorama can be initialized in a hidden element, too? Thanks!

I'd love to see this fixed too! Seems to be a possible duplicate of https://github.com/artpolikarpov/fotorama/issues/406

It is indeed, thanks for the notice. I'll close this one and will follow #406 - thanks again!


[SPARK-43604][SQL] Refactor INVALID_SQL_SYNTAX  for avoiding to embed error's text in source code

What changes were proposed in this pull request?
The pr aims to refactor INVALID_SQL_SYNTAX for avoiding to embed error's text in source code.
Why are the changes needed?
The changes improve the error framework.
Does this PR introduce any user-facing change?
No.
How was this patch tested?

Update UT.
Pass GA

Merged to master.


Code redundance

Perhaps instead of a lot of .setAttributes, it would be better to have a function that mapped an object to the element with .setAttribute?
It could be used like so:
let newText = genProperties(document.createElementNS(xlmns, "text"), (() => {
    "x": x, "y": y,

    "font-size": size,
    "fill": this.cc,

    // ...etc
}).bind(this)());

(There's probably a better way than (() => { ... }).bind(this)())

Hey @ProgrammingParadox!
Great recommendation! It's been a while since I've messed with this library, but that is a very good idea.
To be perfectly honest with you, I still have a lot to learn about JavaScript. For example I have not used arrow functions yet, although I see them used everywhere. I also have a lot of libraries in JavaScript that I want to learn as well, such as babylon.js (that's next on my list).
I'm too busy with college to do much of anything in my free time, but if I get the chance I'll upgrade this library.
Thanks!


Bounding boxes on the edges of tiles

While running Deep Forest on satellite data, using predict_tile,  a lot of false bounding boxes were created on the edge of the tiles.
Why does this happen? Is there a way to get a result without this occurrence?

I've heard of this as well in unique cases. Can you paste a much larger image to see! Please do not ignore the issue template, there is no way to guess at your code, version, setup date, etc. Issues without this information will be closed in the future.

Closing due to inactivity. Feel free to reopen if there are additional occurrences of this. I suspect that part of this comes from setting the overlap to too small a value (possibly 0).


Homebridge

Hi, any chance you can make this available as a plugin for Homebridge so I can use it in Apple Homekit?
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Use Home Assistant and you can export devices for HomeKit. I use both Home-bridge, HA and Scrypted (for cameras). HA sometimes has the better plugin.


prevent redfish password from being logged into charm unit logs

Current I see the password gets logged as plaintext to the charm unit logs (and therefore juju debug-log)
2024-02-28 10:58:18 INFO unit.hardware-observer/5.juju-log server.go:325 Setting redfish-password to: XXXXXXXXXX

also it would be great to not have it logged in plaintext in /etc/hardware-exporter-config.yaml

The second part of the issue the raise in #210


init directory sync resources

init directory sync resources

Would you like me to build the branch and test it?

You can test ist with this image:
samply/share-client:gbn-pr-196

I cannot launch the connector. Whenever I access the GUI I get oops there is a bug somewhere. I'm attaching docker logs
logs.txt

logs.txt
Okay, now I can run the Job but the measure and the library resources are not initialized.


after updated to version 2.2 i get an error

After updated to version 2.2 i get the error message below:
An error has occurred. This application may no longer respond until reloaded.
After hitting reload, the message directly appear again, settings can't be saved.
I'm running HA
Home Assistant 2023.9.3
Supervisor 2023.09.2
Frontend 20230911.0 - latest
I restarted HA, and the addon nothing seems to help, what could be wrong ?

Yes, previous version was running fine. Log file is without error's
because off the default settings, it is going to backup imideatly that isn't fine. I have a prety large media folder because off camera recordings wish shouldn't be uploaded.
Please alter that also.

Same issue after applying update. Addon was working fine before. After the update, the UI is broken without any error on the log.

after uninstalling and reinstalling it looks like it is working.

Thanks @ageurtse. Just to make sure, for those that haven't done so please try a hard refresh see if that helps

@Edenglish92, I have a vague recollection when I started testing the addon a while back that I had this issue and if memory serves, a hard refresh fixed it - might be an easier fix the re installing the addon

@Edenglish92, I have a vague recollection when I started testing the addon a while back that I had this issue and if memory serves, a hard refresh fixed it - might be an easier fix the re installing the addon

What is a "hard refresh" please ? So I can test

@Edenglish92, I have a vague recollection when I started testing the addon a while back that I had this issue and if memory serves, a hard refresh fixed it - might be an easier fix the re installing the addon

What is a "hard refresh" please? So I can test

Hard refresh of the page in your browser, usually Ctrl+F5

It works after a second installation... I did not change anything so I cannot explain why.
My history:

2.1.2 upgrade to 2.2 with UI Broken (nothing on log)
revert to backup 2.1.2: working OK
re-installation 2.2: working OK

It works after a second installation... I did not change anything so I cannot explain why. My history:

2.1.2 upgrade to 2.2 with broken UI (nothing on log)
revert to backup 2.1.2: working OK
re-installation 2.2: working OK

PS: the configuration did not go well (migration of the config on HA to config on the addon). I had to reconfigure everything.

@lavinir issue still present on mobile App... the UI is broken on my mobile HA App (show in sidebar integration) but it works on my PC or using a browser on my mobile.

after installation, require to clear the browser cache and reconfigure everything.  And also clear the application cache of the mobile app...

Same got error. I just uninstalled, re-installed and reconfigured.

after installation, require to clear the browser cache and reconfigure everything. And also clear the application cache of the mobile app...

Thanks! I confirm it did solve my issue on the mobile app.


[Bug]: Sound doesn't turn stops even if the user turns it off

Give a brief about the bug ✍
In the game screen, user cannot turn the sound off.
What is the expected behavior? 🤔
When user presses on the turn-off button, it should stop the sound of the game along with the BG music. Currently it only stops the BG music.
Provide step by step information reproduce the bug 📄
During the game, if the button looks like

the music stops, but the sound does not.
And when it looks like

Both BG music and sound plays
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

@ayush-t02  may I know why my PR was not merged? If there was some error, if I can improve upon it, else I will try to tackle that problem in the future.


CVE-2021-44228 - Log4shell

Since I don't see anything about the CVE, I'm going to open an issue.
According to a quick search, Log4j is used by Serposcope scraper: https://github.com/serphacker/serposcope/blob/master/scraper/pom.xml#L39-L54
Can anyone confirm this? I don't have enough knowledge in Java...
What is the plan to fix it?

This issue has been cloned from: https://github.com/serphacker/serposcope/issues/246

It's just an exclusion tag that need not to care.


AS3 declaration results in errors when binding an HTTP irule on a Virtual Server with no HTTP profile set, dryrun exits with no errors

Environment

Application Services Version: 3.53.0
BIG-IP Version: <IP_ADDRESS> (Hotfix 0.87.5)

Summary
I have an AS3 tenant declaration. The Virtual Servers are being deployed as TCP loadbalancers with class "Service_TCP" with a "security-fastL4" profile. I accidently added an iRule that needs an HTTP profile set. The declaration failed properly saying that the VS needs an HTTP or FastHTTP profile being set.
Steps To Reproduce
Steps to reproduce the behavior:

Submit the following declaration:

{
    "$schema": "https://raw.githubusercontent.com/F5Networks/f5-appsvcs-extension/main/schema/latest/as3-schema.json",
    "class": "AS3",
    "action": "deploy",
    "persist": true,
    "declaration": {
        "class": "ADC",
        "schemaVersion": "3.53.0",
        "mytenant": {
            "class": "Tenant",
            "vs_name": {
                "class": "Application",
                "template": "generic",
                "vs_name": {
                    "class": "Service_TCP",
                    "remark": "fqdn",
                    "virtualAddresses": [
                        "<IP_ADDRESS>"
                    ],
                    "virtualPort": 1234,
                    "redirect80": false,
                    "snat": "auto",
                    "profileL4": {
                        "bigip": "/Common/security-fastL4"
                    },
                    "allowVlans": [
                        {
                        "bigip": "/Common/interface"
                        }
                    ],
                    "pool": {
                        "use": "pool_name"
                    },
                    "persistenceMethods": [
                        "destination-address"
                    ],
                    "iRules": [
                        {
                    "bigip": "/Common/my_irule"
                    }
                    ]
                },
                "pool_name": {
                    "class": "Pool",
                    "loadBalancingMode": "round-robin",
                    "monitors": [
                    {
                        "use": "my_monitor"
                    }
                    ],
                    "minimumMonitors": 1,
                    "members": [
                        {
                            "shareNodes": true,
                            "remark": "node",
                            "servicePort": 1234,
                            "serverAddresses": [
                            "<IP_ADDRESS>"
                            ]
                        }
                    ]
                }
            }
        }
    }
}

when HTTP_REQUEST priority 100 {
    # Remove untrusted HTTP X-Forwarded headers
    # from HTTP requests and set our own:
    #
    # - X-Forwarded-For
    # - X-Forwarded-Host
    # - X-Forwarded-Port
    # - X-Forwarded-Proto
    # - X-Real-IP
    #
    #  X-Forwarded headers clean-up
    #
    HTTP::header remove X-Forwarded-For
    HTTP::header remove X-Forwarded-Host
    HTTP::header remove X-Forwarded-Port
    HTTP::header remove X-Forwarded-Proto
}

Observe the following error response:

Posting declaration
Waiting for task id "00893406-304e-476f-a487-6f561dbdfdbb" to finish.
ERROR: AS3 declaration failed: 422
[
  {
    "code": 422,
    "message": "declaration failed",
    "response": "01071912:3: HTTP_REQUEST event in rule (/Common/my_irule) requires an associated HTTP or FASTHTTP profile on the virtual-server (/mytenant/vs_name).",
    "host": "localhost",
    "tenant": "mytenant",
    "runTime": 1645,
    "declarationId": "autogen_ee1a6e2c-f71b-4698-ae63-5fbeb958caf8"
  }
]

Expected Behavior
I expected that in the dry run a error message says that the VS needs a proper profile when binding an iRule that is being used for HTTP packet handling.
Actual Behavior
The dry run didn't report any errors:
Dry-run enabled
Posting declaration
Waiting for task id "f00f2179-8165-4afd-ab08-c35273c7a1bd" to finish.

please can you open a Service Request for this issue. Thank you Mark

This is the response I got from the support team:

in this specific case we don't expect complains from AS3. Dry-run checks if AS3 declaration is syntactically correct
the error you are facing is from mcpd which checks if the config is valid. ( we cannot have irule without http profile)
So in other words is expected not to see complains from dry-run.

I replied this

I would expect that the dry-run throws errors when an HTTP profile is needed when binding an iRule with "when HTTP_REQUEST..." and so on. So what does the dry-run really do? IMHO I cannot rely on the dry-run feature behaving like that.

I got this answer

The error that you are facing is from mcpd which checks if the config is valid. A dry run is an action that sends a declaration through validation checks without deploying the configuration to the target device. It's useful for debugging and testing declarations. In other words, dry-run checking the declaration, not the configuration for configurations mismatches mcpd is used.

I have to keep this in mind and rethink a bit about the behavior of the dry-run feature. What do you think about the response from support team?

I am not big fan of AS3 and the whole stuff around Next/CM but in this case the response from support team is IMHO valid. We do automate imperatively and had the same challenge as you and it might be tricky to pre-verify irule content against virtual server configuration. It is not only about http profile vs "when HTTP_REQUEST" but you have much more types (stateless, L4, ..) which support or not support various types of iRule events.
Simply, I would say this outcome is fine.

I would say this issue is "solved".


[Feature] Set brush areas programmatically

What problem does this feature solve?
The same way we can use the dispatchAction method for actions like cleaning the areas:
echartInstance?.dispatchAction({
        type: 'brush',
        command: 'clear',
        areas: [],
      });

Could be interesting to be able to brush areas programmatically from a range of values, something like:

echartInstance?.dispatchAction({
        type: 'brush',
        command: 'lineX',
        areas: [
           // Area ranges
         ],
      });

What does the proposed API look like?
Not enough knowledge about the API.

Do you want to start brushing or clear the brushing area? The doc is at https://echarts.apache.org/en/api.html#action.brush.brush