HBASE-28175: Deep copy RpcLogDetails' param field

The RpcLogDetails class represents a slow (or large) log event which will later be consumed by the SlowLogQueueService.
Right now the RpcLogDetails' param field points to the slow call's Message, and this Message is backed by a CodedInputStream which may be overwritten before the given log is consumed. This overwriting of the Message may result in slow query payloads for which the metadata derived post-consumption is inaccurate.
To solve this bug we need to deep copy the Message in the RpcLogDetails constructor. I have this bug reproduced in a QA environment and have confirmed that this resolves the issue.
cc @bbeaudreault @hgromer @eab148 @bozzkar

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 36s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 48s
master passed

+1 :green_heart:
compile
3m 29s
master passed

+1 :green_heart:
checkstyle
1m  1s
master passed

+1 :green_heart:
spotless
0m 58s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 45s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m  9s
Maven dependency ordering for patch

-1 :x:
mvninstall
0m 58s
root in the patch failed.

-1 :x:
compile
0m 13s
hbase-client in the patch failed.

-0 :warning:
javac
0m 13s
hbase-client in the patch failed.

-0 :warning:
checkstyle
0m  9s
The patch fails to run checkstyle in hbase-client

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
hadoopcheck
1m  1s
The patch causes 14 errors with Hadoop v3.2.4.

-1 :x:
hadoopcheck
2m 12s
The patch causes 14 errors with Hadoop v3.3.6.

-1 :x:
spotless
0m 16s
patch has 11 errors when running spotless:check, run spotless:apply to fix.

-1 :x:
spotbugs
0m 11s
hbase-client in the patch failed.

_ Other Tests _

+1 :green_heart:
asflicense
0m 16s
The patch does not generate ASF License warnings.

24m 22s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux fd51dc4327db 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / e473346e9b

Default Java
Eclipse Adoptium-11.0.17+8

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-mvninstall-root.txt

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-compile-hbase-client.txt

javac
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-compile-hbase-client.txt

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/buildtool-patch-checkstyle-hbase-client.txt

hadoopcheck
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-javac-3.2.4.txt

hadoopcheck
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-javac-3.3.6.txt

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-spotless.txt

spotbugs
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-general-check/output/patch-spotbugs-hbase-client.txt

Max. process+thread count
78 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

It would be difficult to reliably reproduce the overwriting of the input buffer in a unit test, but maybe it's possible. We could probably write a unit test which confirms the copied nature of the message here

Nice, I like that idea! I'm headed out on vacation tonight, but will add that test when I return later next week

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 23s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 29s
master passed

+1 :green_heart:
compile
0m 50s
master passed

+1 :green_heart:
shadedjars
5m  8s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 34s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

-1 :x:
mvninstall
0m 37s
root in the patch failed.

-1 :x:
compile
0m 11s
hbase-client in the patch failed.

-0 :warning:
javac
0m 11s
hbase-client in the patch failed.

-1 :x:
shadedjars
2m  5s
patch has 14 errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m  9s
hbase-client in the patch failed.

_ Other Tests _

-1 :x:
unit
0m 11s
hbase-client in the patch failed.

-1 :x:
unit
217m 40s
hbase-server in the patch failed.

236m  9s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux f68847a318a6 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / e473346e9b

Default Java
Temurin-1.8.0_352-b08

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-mvninstall-root.txt

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-compile-hbase-client.txt

javac
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-compile-hbase-client.txt

shadedjars
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-shadedjars.txt

javadoc
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-javadoc-hbase-client.txt

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-client.txt

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/testReport/

Max. process+thread count
4631 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/1/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

An alternative approach here might be to find a way to call ByteBuffer.retain() when creating the SlowLogParams, and then ByteBuffer.release() when consuming in SlowLogService. That might be a little tricker, but would probably be better in terms of GC and time spent copying. It sort of depends on the rate of slow logs.
Looking briefly at it, I think we could possibly utilize the method @Apache9 added to RpcCall in HBASE-22539 -- retainByWAL when enqueueing a RpcLogDetails, and then call releaseByWAL in SlowLogQueueService.consumeEventFromDisruptor. Obviously we'd need to rename the methods in that case. What do you think of that Duo? It seems like the exact same problem

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 14s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 30s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 18s
master passed

+1 :green_heart:
compile
3m  2s
master passed

+1 :green_heart:
checkstyle
0m 53s
master passed

+1 :green_heart:
spotless
0m 43s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 15s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 34s
the patch passed

+1 :green_heart:
compile
3m  4s
the patch passed

+1 :green_heart:
javac
3m  4s
the patch passed

+1 :green_heart:
checkstyle
0m 49s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
9m 10s
Patch does not cause any errors with Hadoop 3.2.4 3.3.6.

+1 :green_heart:
spotless
0m 40s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 27s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 20s
The patch does not generate ASF License warnings.

36m  7s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/artifact/yetus-general-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 47619e1cd44e 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / e473346e9b

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
79 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 48s
master passed

+1 :green_heart:
compile
1m  0s
master passed

+1 :green_heart:
shadedjars
5m 10s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 37s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 34s
the patch passed

+1 :green_heart:
compile
0m 59s
the patch passed

+1 :green_heart:
javac
0m 59s
the patch passed

+1 :green_heart:
shadedjars
5m  7s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 36s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 25s
hbase-client in the patch passed.

+1 :green_heart:
unit
210m 29s
hbase-server in the patch passed.

235m 44s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 87dadb24d42f 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / e473346e9b

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/testReport/

Max. process+thread count
4339 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 42s
master passed

+1 :green_heart:
compile
1m  8s
master passed

+1 :green_heart:
shadedjars
6m 13s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 46s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 48s
the patch passed

+1 :green_heart:
compile
1m  9s
the patch passed

+1 :green_heart:
javac
1m  9s
the patch passed

+1 :green_heart:
shadedjars
5m 33s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 36s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 26s
hbase-client in the patch passed.

+1 :green_heart:
unit
236m 53s
hbase-server in the patch passed.

264m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9285816f8bf9 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / e473346e9b

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/testReport/

Max. process+thread count
4623 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/2/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 33s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 55s
master passed

+1 :green_heart:
compile
3m 35s
master passed

+1 :green_heart:
checkstyle
0m 58s
master passed

+1 :green_heart:
spotless
0m 48s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 43s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 10s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 11s
the patch passed

+1 :green_heart:
compile
3m 50s
the patch passed

+1 :green_heart:
javac
3m 50s
the patch passed

+1 :green_heart:
checkstyle
1m  4s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m 34s
Patch does not cause any errors with Hadoop 3.2.4 3.3.6.

+1 :green_heart:
spotless
0m 43s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 52s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 17s
The patch does not generate ASF License warnings.

45m 10s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/3/artifact/yetus-general-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 58af5a70956e 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fa4c8960e5

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
79 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/3/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 25s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 31s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 31s
master passed

+1 :green_heart:
compile
0m 51s
master passed

+1 :green_heart:
shadedjars
5m 17s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 34s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 18s
the patch passed

+1 :green_heart:
compile
0m 52s
the patch passed

+1 :green_heart:
javac
0m 52s
the patch passed

+1 :green_heart:
shadedjars
5m 14s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 33s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 20s
hbase-client in the patch passed.

-1 :x:
unit
220m 30s
hbase-server in the patch failed.

245m 20s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 5a3eed9f7fff 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fa4c8960e5

Default Java
Temurin-1.8.0_352-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/3/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/3/testReport/

Max. process+thread count
4651 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/3/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 13s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 52s
master passed

+1 :green_heart:
compile
3m  4s
master passed

+1 :green_heart:
checkstyle
0m 52s
master passed

+1 :green_heart:
spotless
0m 48s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 14s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 38s
the patch passed

+1 :green_heart:
compile
3m  3s
the patch passed

+1 :green_heart:
javac
3m  3s
the patch passed

+1 :green_heart:
checkstyle
0m 52s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
9m 20s
Patch does not cause any errors with Hadoop 3.2.4 3.3.6.

+1 :green_heart:
spotless
0m 41s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 30s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 20s
The patch does not generate ASF License warnings.

35m 48s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/4/artifact/yetus-general-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux db9b52e9b554 5.4.0-153-generic #170-Ubuntu SMP Fri Jun 16 13:43:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fa4c8960e5

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
81 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/4/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 31s
master passed

+1 :green_heart:
compile
0m 52s
master passed

+1 :green_heart:
shadedjars
5m 20s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 36s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 21s
the patch passed

+1 :green_heart:
compile
0m 52s
the patch passed

+1 :green_heart:
javac
0m 52s
the patch passed

+1 :green_heart:
shadedjars
5m 17s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 34s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-client in the patch passed.

-1 :x:
unit
252m 43s
hbase-server in the patch failed.

277m 45s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux db9612da685f 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fa4c8960e5

Default Java
Temurin-1.8.0_352-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/4/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/4/testReport/

Max. process+thread count
4655 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/4/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

The test failures above are unrelated. I believe this is ready for review

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 22s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 25s
master passed

+1 :green_heart:
compile
3m 47s
master passed

+1 :green_heart:
checkstyle
1m  0s
master passed

+1 :green_heart:
spotless
0m 54s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 24s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 36s
the patch passed

+1 :green_heart:
compile
3m  4s
the patch passed

+1 :green_heart:
javac
3m  4s
the patch passed

+1 :green_heart:
checkstyle
0m 51s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
9m 29s
Patch does not cause any errors with Hadoop 3.2.4 3.3.6.

+1 :green_heart:
spotless
0m 40s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 28s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 19s
The patch does not generate ASF License warnings.

38m  0s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/artifact/yetus-general-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux e3c55345ebbf 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 027a119bcf

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
79 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 23s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 57s
master passed

+1 :green_heart:
compile
1m  0s
master passed

+1 :green_heart:
shadedjars
5m 16s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 38s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 35s
the patch passed

+1 :green_heart:
compile
0m 59s
the patch passed

+1 :green_heart:
javac
0m 59s
the patch passed

+1 :green_heart:
shadedjars
5m 11s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 35s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 32s
hbase-client in the patch passed.

-1 :x:
unit
217m 50s
hbase-server in the patch failed.

243m 49s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 13ca381dc291 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 027a119bcf

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/testReport/

Max. process+thread count
4609 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 30s
master passed

+1 :green_heart:
compile
0m 52s
master passed

+1 :green_heart:
shadedjars
5m 18s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 34s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 18s
the patch passed

+1 :green_heart:
compile
0m 52s
the patch passed

+1 :green_heart:
javac
0m 52s
the patch passed

+1 :green_heart:
shadedjars
5m 15s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 34s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-client in the patch passed.

+1 :green_heart:
unit
221m 30s
hbase-server in the patch passed.

246m 32s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

JIRA Issue
HBASE-28175

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 37d0d0ab1e4d 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 027a119bcf

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/testReport/

Max. process+thread count
5030 (vs. ulimit of 30000)

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

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5481/5/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.


Lack of devirtualisation on Bindable.Value

We are losing a considerable amount of performance due to Bindable<T>.Value being virtual. Making BindableInt override + seal works however I'd rather push towards improving the bindable structure further instead since this sounds quite limiting.
Current:

Method
Mean
Error
StdDev
Allocated

BenchmarkGetValue
16.25 us
0.010 us
0.009 us
-

With a sealed override:

Method
Mean
Error
StdDev
Allocated

BenchmarkGetValue
2.871 us
0.0231 us
0.0193 us
-

With referencing the field directly:

Method
Mean
Error
StdDev
Allocated

BenchmarkGetValue
2.837 us
0.0548 us
0.0539 us
-

I think there's quite a few scenarios we need to use sealed, too.

The bindable interfaces are also troublesome, since every interface method access is a virtual call regardless of whether we devirtualise Value. Perhaps a ReadOnlyBindable class is something to consider.

I tried your benchmark on my machine with .NET 6, but also Dynamic PGO enabled:

Method
Job
Mean
Error
StdDev
Median

BenchmarkNormalClass
Default mode
2.400 μs
0.0139 μs
0.0123 μs
2.402 μs

BenchmarkNormalClass
Dynamic PGO
2.422 μs
0.0102 μs
0.0096 μs
2.422 μs

BenchmarkNormalClassAsInterface
Default mode
18.929 μs
0.0435 μs
0.0386 μs
18.923 μs

BenchmarkNormalClassAsInterface
Dynamic PGO
5.174 μs
0.0041 μs
0.0037 μs
5.174 μs

BenchmarkClassWithVirtual
Default mode
14.211 μs
0.0287 μs
0.0255 μs
14.207 μs

BenchmarkClassWithVirtual
Dynamic PGO
5.089 μs
0.1001 μs
0.1644 μs
5.167 μs

BenchmarkClassWithVirtualAsInterface
Default mode
18.884 μs
0.0326 μs
0.0272 μs
18.880 μs

BenchmarkClassWithVirtualAsInterface
Dynamic PGO
5.110 μs
0.0997 μs
0.1430 μs
5.166 μs

BenchmarkSealedClass
Default mode
2.399 μs
0.0140 μs
0.0131 μs
2.396 μs

BenchmarkSealedClass
Dynamic PGO
2.419 μs
0.0055 μs
0.0046 μs
2.421 μs

BenchmarkSealedClassAsBase
Default mode
14.271 μs
0.0366 μs
0.0342 μs
14.291 μs

BenchmarkSealedClassAsBase
Dynamic PGO
5.125 μs
0.1056 μs
0.1335 μs
5.178 μs

BenchmarkSealedClassAsInterface
Default mode
18.998 μs
0.0197 μs
0.0164 μs
19.004 μs

BenchmarkSealedClassAsInterface
Dynamic PGO
4.769 μs
0.0048 μs
0.0037 μs
4.769 μs

BenchmarkStruct
Default mode
2.417 μs
0.0165 μs
0.0154 μs
2.420 μs

BenchmarkStruct
Dynamic PGO
2.413 μs
0.0093 μs
0.0082 μs
2.416 μs

BenchmarkStructAsInterface
Default mode
32.995 μs
0.0312 μs
0.0291 μs
32.990 μs

BenchmarkStructAsInterface
Dynamic PGO
4.775 μs
0.0244 μs
0.0216 μs
4.770 μs

According to the post Dynamic PGO can also cause regressions in some cases, but this is supposed to be fixed in .NET 7

Good to know. I believe in general we can turn on Dynamic PGO with .NET 6 already, did some rough benchmarks as such a while back.
Will need to see if there are runtimeconfig flags for it, or if we'd need to wait for it to be turned on by default.

Runtime configs are planned for .NET 7

Since the project was upgraded to .NET 8.0, maybe revisiting this is a good idea

Dynamic PGO is enabled by default in .NET 8.


Panic on wait:1m

$ ta 2 modify wait:1m
thread 'main' panicked at 'unconsumed argument input 1m', cli/src/argparse/args/arg_matching.rs:18:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ ta 2 modify wait:1min
modified task 2 - Check wait works

Ah, that's a bug in the error handling.  That should not be treated as a wait:.. modification, since m is not a valid unit.


Wait / check for scope/collection creation/ready?

It's possible that collections are not ready immediately after creation.
Add some code to check to make sure collection (and scope) is ready, before continuing?
Or investigate if there's an HTTP API endpoint to check for scope/collection readiness?

Perhaps use Polly for this? https://github.com/App-vNext/Polly

Per discussion with a Couchbase engineer, just about everything in Couchbase is async (which makes sense). Additionally, the index service needs time to discover the new collection. So, what probably needs to be done is either:

Create.Collection(...) should wait/poll to see if collection exists
Create.Index(...) should retry/wait/poll to see if collection exists

One, or the other, or both, that is the question.
And the same should apply for Create.Scope(...) too, probably.
It might also be a good idea to add another fluent method to opt out of polling/waiting, which by default WILL poll, but can be changed. Maybe something like .Wait(bool) or .Verify(bool) which defaults to true if not explicitly set.

This seems to be working now; no intermittent failures (yet)


Add search.catalog and document-types endpoints

This replaces an open pull request: https://github.com/Mendeley/mendeley-javascript-sdk/pull/98.
In the absence of the other PR's author I have decided to complete the previously requested PR changes and add paginationFilter to search.catalog endpoint.
@customcommander can you have a look at this next week? Thanks!

LGTM, Would be nice to have another review.

@lazlojuly @charliehw Will merge today if no one else objects.

@lazlojuly Could you address @paulwib comments if needed and see if we can close the previous PR? Thanks.

@customcommander and @paulwib
I have adjusted how endpoint factories are used in the main api.js file so
utilities module can be passed in as a function argument -> making it easy to mock.
With this approach, I do not need the ugly dependency injector tools (proxyquire, proxy-loader etc.) anymore.
This change is contained in my last commit.

@paulwib This seems fine to me. Ok to merge?

@paulwib @customcommander we are now live with this fork. Can we merge this in so we can go back to using the Mendeley SDK?

@lazlojuly looks like it has a minor conflict, can you resolve that then will merge.

@paulwib resolved.


Remove need for double query in template tags

https://github.com/praekelt/molo.commenting/pull/5 introduces a second queryset to limit the amount of comments returned. Chances are this can be done better somehow.

One to review tomorrow morning, landing so we can get the B'Wise stuff working again.


Question on versions of tasmota versions included with latest tuya-convert

I noticed last night when I redid my Raspberry pi that tuya-convert is Currently including a Tasmota v<IP_ADDRESS>.  And you can update to a current version when completed.  According to the Tasmota site, the current released version is 6.7.1, and the 7.x is the develop branch.
Is this switch done because tuya-convert feels the develop branch is complete enough to become the main release?  Or is there some other reason?
Note, the 4 I did today work just fine on the 7.0 install, and I would not have even noticed had the web screen not switched to black.

Tasmota v<IP_ADDRESS> was included via #376
@meingraham explains in this comment how the development branch is stable and preferred over master, which has bugs that are resolved in development. experimental is the unstable branch in the Tasmota project.
Similarly, tuya-convert development branch is more or less stable. Merge to master is done after a batch of PRs has been tested and no regressions become apparent.


Tragic server crash on join

java.lang.NoClassDefFoundError: net/minecraft/class_742
	at ram.talia.hexal.fabric.cc.CCPlayerLinkstore.<init>(CCPlayerLinkstore.kt:25) ~[hexal-fabric-1.18.2-0.1.4.jar:?]
	at dev.onyxstudios.cca._generated_.GeneratedComponentContainer_EntityImpl_class_3222_1356f9d8.<init>(Unknown Source) ~[?:?]

Full crash report: https://mclo.gs/FYJX97p
Happens every time I join my server, only the server crashes. Does not happen when joining single player on the client. Identical mod (& mod config) setups on both. Same fabric loader version too.

Alright, this should be fixed in v0.1.5, thanks for sending the bug report


[ADAM-807] workaround for ktoso/maven-git-commit-id-plugin#61

Fixes #807

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/ADAM-prb/887/
Test PASSed.

Thanks @heuermh! I've merged this manually as b987dcc67b839c91eff81af2448291b547924ba4.


Feature Request : Redirect to website when click on "Close" on default Password Change confirmation page

When a user successfully change their email, this page appears :

I believe a nice thing would be to redirect to the website when clicked on "Close"
Or maybe my browser do not do the expected thing here ? Should it close the page ?
Maybe it is only a Firefox error :

"Scripts may not close windows that were not opened by script."
Edit : same behavior on brave :

I believe simply closing the page is totally good as well

For now there are no plans to introduce extra configurations to the default confirmation pages.
But you can define your own custom confirmation pages by changing the "Action URL" in the Admin UI > Settings > Mail Settings > {template}.


feat: use API for GitHub latest release strategy

[x] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

Part of https://github.com/Homebrew/brew/pull/15260
This is just the API switch to make sure we don't have to scrape HTML anymore.

I'll do comparative runs to find out how many (and which/why).

@samford Thanks for doing these! For the bus factor of the project: can you try and get whatever scripts you're using to do this into a brew command so that they can be run by Not Just You?

I saw a couple that failed locally already because they strictly check for a href. Easy to fix those afterwards though once this is done, livechecks being broken only affect a small subset of people.

For the bus factor of the project: can you try and get whatever scripts you're using to do this into a brew command so that they can be run by Not Just You?

For what it's worth, when I do comparative runs there isn't any anything special about the process that precludes anyone from doing the same (i.e., no scripts or arcane knowledge). I've explained the process here and there over the years (Nanda picked it up during GSoC) but it's essentially just diffing multiple brew livecheck --json --verbose runs and looking for meaningful changes:

With my local brew repository on the master branch, I run brew livecheck --json --verbose with any affected formulae/taps and redirect the output to a JSON file (e.g., > 01.json).
Once that completes, I apply the changes I want to test (e.g., switching to a brew PR branch, etc.) and do the same run again but forward the output to a different JSON file (e.g., > 02.json). [It's best to do these two runs as close together (chronologically) as possible, to minimize upstream version changes (i.e., false positives that have to be verified on the master branch afterward).]
Diff the two JSON files however you like (I use Kaleidoscope), scroll through the differences, and keep track of any notable changes.

It's typically a manual process (as above) but, sometimes when I'm looking for specific changes, I might pop into irb, load the two JSON files, and do some comparisons programmatically. In those situations, it's usually just one-off, contextually-specific code that isn't worth saving in a script. It's unexciting work but it's necessary to be able to verify changes to livecheck's behavior (mostly related to strategies), catch bugs, identify breakages, etc.
It also may go without saying but it's important to make sure that any changes work properly before doing a JSON livecheck run, since the output isn't visible until the end. For example, I did some manual testing before doing the comparative run on this PR branch and I had to incorporate some fixes to make this work as intended. Even with that, there were some other errors that we'll need to address (but it won't require a full re-run in this case).

As this PR currently stands, it will break ~104 existing checks out of 650 (across both formulae and casks).
Most of these fail because they use a livecheck block with a modified version of the existing GithubLatest default regex, which is intended for an HTML context. Fixing these should be pretty simple, though.
There are a few that fail with an error like undefined method `scan' for #<Array:0x00000001098b7f90> (also some for match), which will require some changes to the strategy's logic. I'll look into the issues and suggest changes as part of review.
I've added lists below for reference (I'll try to update this later to use the full name where there are cask name conflicts):
Working -> Different version

List
```
obs-websocket (5.0.1 -> 4.9.1; newest version is 5.0.1; "latest" release is 4.9.1 but description contains a link to 5.0.1 that the existing check matches; need to check all recent releases to identify the highest version)
```

Working -> Unable to get versions

List
```
accord
appium
atari800
augeas
autopsy
azure-cli
bonitastudiocommunity
btcpayserver-vault
camera-live
cataclysm
chamber
chrysalis
clang-format
clojurescript
elk
firefly
flowgrind
genders
gnupg-pkcs11-scd
gopls
gperftools
heimdal
hydrus-network
icarus-verilog
irrtoolset
javacc
josm
jsonschema2pojo
jupyterlab
koka
kona
lbry
libuninameslist
mambaforge
mame
manyverse
mbedtls
miniforge
mp3unicode
mydumper
n1ghtshade
nushell
only-switch
onlyoffice
openimageio
openmsx
openrocket
outline-manager
pingnoo
pkcs11-helper
plover
proftpd
qldds
redpen
ricochet
ricochet-refresh
sapling
sdl2
sdl2_image
sdl2_mixer
sleuthkit
swift
synergy-core
time-to-leave
tmux
turtl
ubports-installer
utm
uuu
vcpkg
vespa-cli
vgmstream
vidcutter
vimediamanager
vlmcsd
wal2json
waterfox-classic
webots
wla-dx
wolfssl
yaws
z3
zesarux
```

Working -> undefined method `scan' for #<Array:0x00000001098b7f90>

List
```
arabica
desmume
expat
flame
gauche
gnustep-make
minio
minio-mc
processing
processing3
semeru-jdk11-open
semeru-jdk8-open
temurin19
vine-server
wezterm
```

Working -> undefined method `match' for #<Array:0x000000010903be70>

List
```
fvim
home-assistant
semeru-jdk17-open
sequel-ace
```

Working -> Not Found

List
```
extraterm
```

Thanks @samford!

It's typically a manual process (as above) but, sometimes when I'm looking for specific changes, I might pop into irb, load the two JSON files, and do some comparisons programmatically.

Turning this into a script or documentation would be very valuable!

Since there were no real complaints I enabled automerge

I didn't have as much time today as I wanted, so I'm still working on code changes (hoping to get them out tomorrow but it might be Thursday). In the interim time, one of the things we need to address before merging this or the GithubRelease PR is how to handle the GitHub token situation. As mentioned before, the limit without a token is 50 requests per hour (5,000 per hour with a token). At present, there are ~279 GithubLatest livecheck blocks in homebrew/core and ~360 in homebrew/cask, so a token is necessary to be able to complete a full tap run of either.
There was a previous idea in the other PR to simply fail if HOMEBREW_GITHUB_API_TOKEN isn't set but I think we can be a little more sophisticated about it. Naively failing fast if HOMEBREW_GITHUB_API_TOKEN isn't set is very easy but it would be a bad experience for some (e.g., first time livecheck users, those who use livecheck sparingly, those who use it in a way that doesn't involve GitHub API requests, etc.).
Warning on larger runs makes sense, as it would allow some basic livecheck usage without a token. We're going to need to keep track of the rate limit response headers and adapt livecheck's behavior to it anyway (i.e., to skip API checks [that are guaranteed to fail] between when the rate limit is exhausted and reset), so assumedly we would display an error when a check fails due to the rate limit. The error message would inform users doing smaller runs without preventing them from using livecheck, so that may be a good balance. [The error message would need to be short, so we may need to add something to the documentation that we can link to (that explains how to resolve the issue, similar to how our manpage explains HOMEBREW_GITHUB_API_TOKEN).]
Extending that idea, we could identify the number of formulae/casks in a run that will use the GitHub API and fail if it's at or above a simple threshold (e.g., 50 without a token, 5,000 with). This wouldn't factor in how much of the rate limit is left (that would require a request to https://api.github.com/rate_limit) but that's probably fine under normal circumstances. We could potentially check the rate limit for large runs (e.g., if there are more than 1,000 API checks in a run) to make sure API checks won't fail in the middle of the run but we can save that for later (i.e., it mostly applies to maintainers and enthusiastic contributors).
In general, we need to keep in mind that livecheck is also used in other parts of Homebrew (brew bump, cask audits, test-bot, etc.), so it's worth looking into how this issue may affect those areas as well. For example, if livecheck uses the same token on CI that's used for making API requests that are necessary for CI to function, then that may push us towards exhausting the rate limit and causing CI to fail. [If possible, it would be a good idea to use a separate token for livecheck on CI to avoid that possibility.]

Yeah nah, I don't want to rewrite the way brew deals with rate limits in case someone doesn't have a token set. If we get actual complaints we can always revisit it, but you're currently proposing a shitton of work in unrelated parts of brew for the benefit of avoiding something that will make the brew UX better for users if they do it. I'd rather drop the change request.

Yeah nah, I don't want to rewrite the way brew deals with rate limits in case someone doesn't have a token set.

Agreed.

If we get actual complaints we can always revisit it, but you're currently proposing a shitton of work in unrelated parts of brew for the benefit of avoiding something that will make the brew UX better for users if they do it.

Agreed.

I'd rather drop the change request.

Please don't. @samford I'd love you to show a little more flexibility here. I think what you're asking of @SMillerDev here is a little unreasonable. I'm also in the camp of "let's get to something with no known problems and, if we hit rate limit issues in CI, let's revert or fix forward" rather than blocking this PR on problems that may not actually manifest.

I looked at GitHub::API and saw that it contains RateLimitExceededError, so I ran livecheck without a token and we do get a RateLimitExceededError when we hit the rate limit (I initially assumed that livecheck would fail with an opaque Unable to get versions error without any indication of why). Due to this, we automatically get an okay error message (though the token doesn't need any special permissions for livecheck purposes):
Error: firefly: GitHub API Error: API rate limit exceeded for XXX.XXX.XXX.XXX. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
Try again in 58 minutes 30 seconds, or:
Create a GitHub personal access token:
https://github.com/settings/tokens/new?scopes=gist,repo,workflow&description=Homebrew
echo 'export HOMEBREW_GITHUB_API_TOKEN=your_token_here' >> ~/.zshrc

This is fine for --debug runs but we need something brief for normal and --json runs (e.g., "GitHub API rate limit exceeded"). This would probably involve catching the error somewhere and overriding the message for non-debug runs. I can work on this and either push a commit or add a suggestion to handle it.

Of the previously-mentioned requests, the only one I don't think we can reasonably defer is preventing GitHub API requests once the rate limit is exhausted. This is basic behavior when using any API with a rate limit and the related GitHub documentation specifically states, "If you are rate limited, you should not try your request until after the time specified by the x-ratelimit-reset time."
I haven't looked into how we may address that, so I'm not sure whether we can modify the GitHub class to keep track of the rate limit reset time or if we need to handle this in livecheck.

I'll have some time to work on reviewing the changes tomorrow (Thursday). However, before I dig further into reviewing this, it's worth mentioning that the GitHub API isn't the only way of moving GithubLatest away from matching tag URLs in the HTML content of the "latest" page.
I have a local branch where I've modified GithubLatest to use HeaderMatch#find_versions internally to pull the tag name from the Location header and then extract the version using the regex (we already do this for a few weird cask checks). With this approach, we wouldn't have to worry about a rate limit and the changes to the strategy are very simple and straightforward (it only modifies DEFAULT_REGEX and #find_versions).
I believe there are fewer than 10 GithubLatest livecheck blocks that check something other than the tag name (e.g., release name, description, date, etc.) but we can just handle those exceptions with PageMatch.
Thoughts on this alternative approach?

My thoughts are mostly: GitHub provides an API for exactly what we want why parse headers or html? To avoid a possible rate limit?
I just don't see any added value in your alternatives.

GitHub provides an API for exactly what we want why parse headers or html? To avoid a possible rate limit?

Yep, the rate limit has always been the primary reason we've avoided the GitHub API in livecheck. That and sometimes there are API incidents (making it temporarily inaccessible) while the website is still accessible during those outages. In all the time we've used GithubLatest, I don't think I've ever seen it fail because of a GitHub incident (and the alternative approach maintains that reliability).
My opinion has always been that the API would be nice (though not necessary) if we could reasonably use it but the rate limit was always too much of a deterrent to me. There may be some growing pains here but maybe it will mostly be fine if we continue to be careful to only use GithubLatest when it's necessary. If it really blows stuff up or is too much of an ongoing pain, we can always revert and take a different approach.
Anyway, I figured I would mention the alternative, just in case.

If it's good with you, I'll push some commits for straightforward changes that won't benefit from discussion (e.g., updating the documentation comments, small changes to align this with other strategies, etc.), to save you from having to incorporate a bunch of suggestions. Anything that we may want to discuss (not a lot, I don't think) I'll create a review comment/suggestion for and I can push commits once we agree.
Does that sound good to you?

Yep, the rate limit has always been the primary reason we've avoided the GitHub API in livecheck. That and sometimes there are API incidents (making it temporarily inaccessible) while the website is still accessible during those outages.

In those cases you can use livecheck but not brew install so not sure it's a case we should be optimising for.

In all the time we've used GithubLatest, I don't think I've ever seen it fail because of a GitHub incident (and the alternative approach maintains that reliability).

But it did fail because they updated the website to lazyload downloads.

My opinion has always been that the API would be nice (though not necessary) if we could reasonably use it but the rate limit was always too much of a deterrent to me.

With the amount of github_latest formula, I think we'll be fine. But really the only way to see is to try.

If it's good with you, I'll push some commits for straightforward changes that won't benefit from discussion (e.g., updating the documentation comments, small changes to align this with other strategies, etc.), to save you from having to incorporate a bunch of suggestions. Anything that we may want to discuss (not a lot, I don't think) I'll create a review comment/suggestion for and I can push commits once we agree.

I think it would be nicer to add that to the github_releases PR since that way we can allow this change to test the waters for the releases one

But it did fail because they updated the website to lazyload downloads.

This only affected casks that were checking release assets and some of could be updated to simply check the tag instead. After dealing with the issue, we only have a handful where it's necessary to check release assets.
But yeah, I agree with this point. It wouldn't have been an issue if we were checking the GitHub API. I said at the time that checking the API is the easiest solution but wanted to look into other options before dealing with the rate limit.

But really the only way to see is to try.

👍

I think it would be nicer to add that to the github_releases PR since that way we can allow this change to test the waters for the releases one

I'm not sure I understand. If you're suggesting merging this as-is and doing follow-up changes in the GithubRelease PR, then sorry, that's a hard no. This isn't ready to merge as-is (e.g., at least one of the changes I want to see modifies the fundamental functionality of this) and there's no reason to merge it prematurely. Merging it before GithubReleases for testing purposes makes sense but we can do that when we're done with changes.
Merging this will immediately break ~100 existing livecheck blocks (~56 formulae, ~50 casks) [out of ~650 checks] and we should have draft [bulk] PRs ready in the related repositories that we can merge to prevent the breakages, otherwise it's going to be a mess. Some (maybe most) of the changes will be simple/straightforward but there may be others that take a little more work and there's no value in rushing to merge this PR. I'll take care of the related changes but I don't think there's any value in merging this before that's ready.
The change in this PR doesn't provide any immediate benefit but it does create issues, so we should take the time to do this right.

This isn't ready to merge as-is (e.g., at least one of the changes I want to see modifies the fundamental functionality of this)

Then that would be good as a suggestion because I don't see any fundamental changes that it still needs. It works and it works well in my tests.
You were previously only talking about trivial changes though, so I'm not sure where the fundamental problems come from and why you haven't mentioned them for over two weeks.

Concerns about array vs object are addressed, tag_name is checked first and the regex only takes the first match. I think we're good to go.


[github-actions] upload core dump only when crash happens

Currently when a test fails, the core dump uploading action would be executed. (Even when there's no core dump, the binaries and so libs would be uploaded, which is a waste.)
This PR uses env variables of github actions to only execute the uploading action when crash actually happens.

I've verified that the new approach works.

I've verified that the new approach works.

Also change this for other workflows?

Updated. Missed it before. Thanks!
@Moandor-y

Also change this for other workflows?

Updated. Missed it before. Thanks!
@Moandor-y

Testing.

Testing.

I've verified.

I've verified.


Error when writing to Redshift

Hi,
I am getting the following error when trying to write to Redshift from EMR/Spark. I am able to read from Redshift successfully. I am using Spark 2.2.0 on EMR and the databricks-redshift driver.
Appreciate any help to get this resolved quickly.
Caused by: java.lang.AbstractMethodError: org.apache.spark.sql.execution.datasources.OutputWriterFactory.getFileExtension(Lorg/apache/hadoop/mapreduce/TaskAttemptContext;)Ljava/lang/String
See details below.
Thanks!
**** DETAILS ****
17/12/01 01:25:43 WARN Utils$: The S3 bucket XXXXX does not have an object lifecycle configuration to ensure cleanup of temporary files. Consider configuring tempdir to point to a bucket with an object lifecycle policy that automatically deletes files after an expiration period. For more information, see https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html
[Stage 22:>                                                         (0 + 2) / 2]17/12/01 01:27:28 WARN TaskSetManager: Lost task 1.0 in stage 22.0 (TID 1234, ip-nnn-nnn-nnn.us-east-2.compute.internal, executor 11): org.apache.spark.SparkException: Task failed while writing rows
at org.apache.spark.sql.execution.datasources.FileFormatWriter$.org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask(FileFormatWriter.scala:272) at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1$$anonfun$apply$mcV$sp$1.apply(FileFormatWriter.scala:191) at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$write$1$$anonfun$apply$mcV$sp$1.apply(FileFormatWriter.scala:190)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:87)
at org.apache.spark.scheduler.Task.run(Task.scala:108)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:335)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.AbstractMethodError: org.apache.spark.sql.execution.datasources.OutputWriterFactory.getFileExtension(Lorg/apache/hadoop/mapreduce/TaskAttemptContext;)Ljava/lang/String; at org.apache.spark.sql.execution.datasources.FileFormatWriter$SingleDirectoryWriteTask.newOutputWriter(FileFormatWriter.scala:299)	at org.apache.spark.sql.execution.datasources.FileFormatWriter$SingleDirectoryWriteTask.execute(FileFormatWriter.scala:314)	at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask$3.apply(FileFormatWriter.scala:258) at org.apache.spark.sql.execution.datasources.FileFormatWriter$$anonfun$org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask$3.apply(FileFormatWriter.scala:256)
at org.apache.spark.util.Utils$.tryWithSafeFinallyAndFailureCallbacks(Utils.scala:1375) at org.apache.spark.sql.execution.datasources.FileFormatWriter$.org$apache$spark$sql$execution$datasources$FileFormatWriter$$executeTask(FileFormatWriter.scala:261)
... 8 more
17/12/01 01:59:12 ERROR TaskSetManager: Task 1 in stage 3.0 failed 4 times; aborting job
17/12/01 01:59:12 ERROR FileFormatWriter: Aborting job null.
This is while trying to do the demo at AWS Big Data blog:  Powering Amazon Redshift Analytics with Apache Spark and Amazon Machine Learning
(https://aws.amazon.com/blogs/big-data/powering-amazon-redshift-analytics-with-apache-spark-and-amazon-machine-learning/#more-1340).
My EMR cluster has Spark 2.2.0, and I invoked Spark as below:
========
spark-shell --jars spark-redshift_2.10-2.0.0.jar,/usr/share/aws/redshift/jdbc/RedshiftJDBC41.jar,minimal-json-0.9.4.jar,spark-avro_2.11-3.0.0.jar
Here is the code snippet used for writing..
val s3TempDir2 = "s3:///predict_flight_delay_with_Spark/output2/"
flightsDF.write
.format("com.databricks.spark.redshift")
.option("temporary_aws_access_key_id", awsAccessKey)
.option("temporary_aws_secret_access_key", awsSecretKey)
.option("temporary_aws_session_token", token)
.option("url", jdbcURL)
.option("dbtable", "ord_flights_new")
.option("aws_iam_role", "arn:aws:iam::xxxxxxxxx:role/RedShiftFullAccess")
.option("tempdir", s3TempDir2)
.mode(SaveMode.Overwrite)
.save()
============
print (firstFlightsDF)
[2702961,10,2,2017-01-10,6,AA,1700,13,0,89,1,599]
flightsDF.printSchema()
root
|-- id: long (nullable = true)
|-- day_of_month: integer (nullable = true)
|-- day_of_week: integer (nullable = true)
|-- fl_date: date (nullable = true)
|-- days_to_holiday: integer (nullable = true)
|-- unique_carrier: string (nullable = true)
|-- fl_num: string (nullable = true)
|-- dep_hour: string (nullable = true)
|-- dep_del15: integer (nullable = true)
|-- air_time: integer (nullable = true)
|-- flights: integer (nullable = true)
|-- distance: integer (nullable = true)
flightsDF: org.apache.spark.sql.DataFrame = [id: bigint, day_of_month: int ... 10 more fields]
firstFlightsDF: org.apache.spark.sql.Row = [2702961,10,2,2017-01-10,6,AA,1700,13,0,89,1,599]
=============

One additional question: I currently use normal s3 syntax.
s3TempDir2 = "s3:///predict_flight_delay_with_Spark/output2/
Should I be using s3n:///folder instead?
Note that my Redshift cluster version  is 1.0.1499.
Thanks!

You have an extra slash I'm s3

@HemanK - How did you get this working? I am struck with same error.

Were you able to fix this issue?

yes. I had mismatched versions of Jarfiles

I also got the
Caused by: java.lang.AbstractMethodError: org.apache.spark.sql.execution.datasources.OutputWriterFactory.getFileExtension(Lorg/apache/hadoop/mapreduce/TaskAttemptContext;)Ljava/lang/String;

error when trying to write to redshift from spark.
Would you mind sharing which jars ending up working for you? I ended up using s3n to manually save to tables to s3, and then manually create the table in redshift, then copied from s3 to get around this

I'll go ahead and post the solution that I came up with. Basically what I've discovered is that there are some compatibility issues using certain hadoop-aws jar to write to s3 with the s3a format. By switching to the s3n format you can combat this, the hadoop-aws 2.7.4 jar seems to be the consensus safest choice.
The aformentioned error also seems to be directly associated with an avro formatting problem.
I was able to write to redshift with all of the aforementioned combinations when using the following code to write.
df.write
    .format("com.databricks.spark.redshift")
    .option("url", "jdbc:redshift://yoururl$user=yourUser&password=your_password")
    .option("dbtable", "optionaldbname.tablename")
    .option("forward_spark_s3_credentials",true)
    .option("tempFormat", "CSV GZIP")  //default is avro, can also use CSV and CSV GZIP formats
    .option("tempdir", "s3n://myS3/path/to/bucket")
    .mode(SaveMode.Overwrite)
    .save()

Still interested in getting avro to work

@HemanK  - can you please let me know how did you resolve this issue?
I am getting smilar issue  - my jar versions are
spark-redshift_2.11-0.6.0.jar,
RedshiftJDBC42-<IP_ADDRESS>7.jar,
spark-avro_2.11-4.0.0.jar
not sure what i am missing here

Try using RedshiftJDBC41-<IP_ADDRESS>5.jar @daddalaramu

Same error --
I am reading the data from csv file and writing into redshift  - not sure if i have any issue in the below dataframe syntax
sourceDF.write
.format("com.databricks.spark.redshift")
.option("url", "jdbc:redshift://databasename:5439/biodrive?user=XXXXX&password=XXXXX")
.option("dbtable", "dev.sample")
.option("tempFormat", "CSV GZIP")
.option("tempdir", "s3://foldername/temp/")
.option("encryption", "true")
.option("temporary_aws_access_key_id", "XXXXXX")
.option("temporary_aws_secret_access_key", "XXXXX")
.option("temporary_aws_session_token", "YYYYYY")
.mode(SaveMode.Overwrite)
.save()

what if you just need the Redshift-S3 connection without any HDFS in place? I just need to write to Redshift from AWS Glue but keep getting hadoop security access permissions errors for the S3 spark temp directory i have defined, but i created the temp bucket with the same account!

In my case, using the current master-SNAPSHOT, adding tempFormat option fixed it:
.option("tempFormat", "CSV GZIP")

Has anyone been able to solve this in Spark 2.4.3? I am using the following jars and packages when running a local instance, and have no trouble reading from Redshift. I am getting the same error as above when writing however (even when switching to csv format).
spark = SparkSession.builder.master("local").appName("Test")
.config("spark.jars", 'RedshiftJDBC4-<IP_ADDRESS>1.jar,jets3t-0.9.0.jar,spark-avro_2.11-4.0.0.jar,hadoop-aws-2.7.4.jar')
.config("spark.jars.packages", 'com.databricks:spark-redshift_2.10:0.5.0,com.amazonaws:aws-java-sdk:1.10.34,org.apache.hadoop:hadoop-aws:2.7.4')
.getOrCreate()


CommitToSupport-catalogDisplayAndDownload

The PR hosts the code changes to support display and downloading of Catalog from player UI

UT SnapShots


Read the turnstile secret key from a file

Hi 👋
I want to use docker secrets to pass the turnstile secret key for this module. As it looks to me, the turnstile module only accepts the secret key, when it is added to the runtime config by hand. I made a small change to pass the path of a file (in my case the docker secret) containing the secret for turnstile. It would be awesome if you would add that functionality.
I hope this PR can help 💪 Also as I am new to Nuxt I'm not sure if I made some mistakes or could do some things better. So I'm always open for improvement hints.
Greetings from Germany ❤

I really appreciate the work you both are putting into this.
My own point of view is that the secret should be configured by the user setting an environment variable, rather than reading a file from disk. I'm willing to support reading a file from disk at build-time, however, if you really need it, though I personally can't see why - it seems it would be better to include the following in your .env file:
NUXT_TURNSTILE_SECRET_KEY=somesecretkey

Afaik it's not recommended to store secrets in environment variables. It's described in CWE-526.
TrendMicro did research on that. Diogo Mónica sums it up in a shorter article. I think these observations are the reason why Docker implemented secrets as files, they write:

Docker secrets do not set environment variables directly. This was a conscious decision, because environment variables can unintentionally be leaked between containers (for instance, if you use --link).

I see that in this context it might not be very necessary to support secret files, but to me it's better to follow the habit of doing it a safer way.

Hey, sorry for the incoming spam, but I am limited by https://github.com/orgs/community/discussions/8327 not being able to resolve my own review comments, so I'm going to comment under those which can be marked as resolved by someone with write access to this PR.


"Introduction to Computer Science and Programming using Python" unavailable

Not sure if this is recent, but is there an alternative to this anyone could recommend?

You're right. Very strange!
The MIT OCW version is here: https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-0001-introduction-to-computer-science-and-programming-in-python-fall-2016/
I don't know how it compares to the edX version. If edX doesn't restore their version quickly, we will need to add an alternate link into the curriculum.

The professors have blocked the old course and may reopen it in late august.

If you signed up prior to the course being blocked, you will still have access.
https://www.edx.org/course/introduction-computer-science-mitx-6-00-1x-11
Is the most recent revision of the course, but is currently inaccessible to new students.
https://courses.edx.org/courses/course-v1:MITx+6.00.1x_7+3T2015
Is the 2015 version of the course. I am not sure how out to date the content is. It should be accessible to anyone.

MIT's Introduction to Computer Science and Programming using Python runs on an yearly basis instead of the semester format that was offered previously.
Students who have completed the course between august 2017 and august 2018 will be able to view the final exam answers (if i recall correctly) due for release late august.
The course will then be opened again end august/early september for another year.

Its back to the 9 week instructor paced version starting with this new iteration.  The next 6.00.2x will start as 6.00.1x finishes.
Sign up for the new iteration of 6.00.1x is available here.
Anyone waiting now, who's Python isn't strong, could start by doing the first part of sololearn's course, which will make the first few 6.00.1x PSETs much more approachable.

I'm closing this as the course has been back up for some time now.

@hanjiexi It seems to be down again.

@buve Although it says not available when you open the course page, I clicked on the "Not Currently Available" button and it enrolled me in the course. I'm able to access the course materials. Perhaps this is just an edX bug?

@buve Although it says not available when you open the course page, I clicked on the "Not Currently Available" button and it enrolled me in the course. I'm able to access the course materials. Perhaps this is just an edX bug?

@hanjiexi It just bring me to the home page when I click on it. I'm guessing this is because you've already enrolled in the course before?

It's going to open again in January. I was reading the forum in the course before it finished.

I've created a new Firefox profile and it now lets me see the archived version. I think this is because of some privacy configurations and extensions. Thanks people.

Course just completed (end October 2018) and 6.00.2x is now running.
The next iteration of 6.00.1x will start in late January 2019.


Non-async functions/methods support

[x] Provide a non-async alternative methods relative to their respective async counter-part.
[x] Allow the library user to set a feature flag to want async, non-async, or both

4ae3feda174542955642f28e764eb2dfc34b9eca to<PHONE_NUMBER>08f0682a696a431c3054601c20d519 Fulfilled all those requirements


[WFCORE-4552] Upgrade Undertow to 2.0.24.Final

Jira: https://issues.jboss.org/browse/WFCORE-4552

The cause of the failures is https://issues.jboss.org/browse/UNDERTOW-1586
I'm fixing and it and I'll provide a new Undertow release

@fl4via thanks


Public data endpoints

We need to:

Potentially provide an endpoint for external users to download and find data generated by the consortium (beyond signposting to GISAID and ENA)
Improve accessions list for public data and show basic QC information

Weekly accession dump is now automated via the v3 MDV API

More to do on this but we can close for now


Disconnected without doing anything

Describe the bug
LiveKitRoom/VideoConference simply stuck at Disconnected without throwing errors in either server orclient side in NextJs 14
Server

Version: [^2.1.2]
Environment: localhost
NextJs 14 App Router

Client

SDK: livekit-client
Version: [^2.0.10]

To Reproduce
Steps to reproduce the behavior:

Create LIVEKIT_API_KEY, LIVEKIT_API_SECRET,NEXT_PUBLIC_LIVEKIT_URL as instructed by https://docs.livekit.io
Create TokenEndPoint Api Routes ,
Create a page which used fetch from api to get token and useeffect to save tokens
The API call works and send a readable token
The client side doesn't throw any error
The default video conference component simply show disconnected .
The example video conference component demo doesn't even show it's disconnected ?

Expected behavior
The room call should be running with proper token .
If token is incorrect / server refused the authorization then there would be a respond of unauthorized .
Screenshots
The token from server API

The client side render

The front end console log to see if token is indeed received

Additional context
The guide is made for nextjs 13 , so I guess issue can come from here . But in such cases , an error would have been detected by the client sdk or server sdk and showed up .

I have checked and added await but still doesn't work .

Make sure Your Api-keys are correct!!
it will work or re-create new keys

@Mohammedyaseen29 I checked if my keys were correct using the example app so I knew it's running . But it just suddenly run again so I don't know what happened . Probably an API choke happened for several days due to outdated packages .


altRepGroup support

For <mods:accessCondition> we're migrated to altRepGroup="…" to indicate the same thing in different languages. This could lead to »Widersprüchliche Rechteangaben in mods:accessCondition[@type=’use and reproduction’]« → amdSec_16. Is there support for altRepGroup?

At the moment our validation doesn't support the attribute altRegGroup in any element as we have not processed any records using it in a way relevant for the DDB yet.
The test amdSec_16 should only trigger if a record contains two different valid URIs for right statements in mods:accessCondition[@type='use and reproduction'] elements (element text or attribute href).
Please give us an example record and we will look into it.

Here an example: https://digi.ub.uni-heidelberg.de/diglitData/mets/schliemann1884.xml

We've discussed the altRepGroup attribute on our side but decided against supporting it.
The main reasons are, that it is hardly used in our context, can be used on many elements and the values are not controlled. This would complicate the DDB-METS/MODS Application Profile and our validations.
The example schliemann1884.xml does not trigger amdSec_16. The rule removes the deed... part of the license URIs before comparing.
If you have another example that causes a false positive on amdSec_16 we can look into it.


Error trying add new user

Hi @horeaporutiu ,
I tried to run the registerUser.js and I got an error because the connection.yaml is not a json file. So I modified the code, to solve this issue, but now I'm getting the following error:

Failed to register user userError: Common connection profile is missing this client's organization and certificate authority

The problem is occurring during the gateway connection, when the connection file information is being used.
My question is: Do I have to create a new certificate to the new user or this is not the real error cause?
It follows the registerUser code.
Thanks in advance.
`
const { FileSystemWallet, Gateway, X509WalletMixin } = require('fabric-network');
const fs = require('fs');
const path = require('path');
const yaml = require('js-yaml');

// capture network variables from config.json
const configPath = path.join(process.cwd(), 'config.json');
const configJSON = fs.readFileSync(configPath, 'utf8');
const config = JSON.parse(configJSON);
var connection_file = config.connection_file;
var appAdmin = config.appAdmin;
var orgMSPID = config.orgMSPID;
var userName = config.userName;
var gatewayDiscovery = config.gatewayDiscovery;

const ccpPath = path.join(process.cwd(), connection_file);
let fileContents = fs.readFileSync(ccpPath, 'utf8');
let connectionFile = yaml.safeLoad(fileContents);

async function main() {
    try {

        // Create a new file system based wallet for managing identities.
        const walletPath = path.join(process.cwd(), 'wallet');
        const wallet = new FileSystemWallet(walletPath);
        console.log(`Wallet path: ${walletPath}`);

        // Check to see if we've already enrolled the user.
        const userExists = await wallet.exists(userName);
        if (userExists) {
            console.log('An identity for the user "user1" already exists in the wallet');
            return;
        }

        // Check to see if we've already enrolled the admin user.
        const adminExists = await wallet.exists(appAdmin);
        if (!adminExists) {
            console.log('An identity for the admin user "admin" does not exist in the wallet');
            console.log('Run the enrollAdmin.js application before retrying');
            return;
        }

        // Create a new gateway for connecting to our peer node.
        const gateway = new Gateway();
        await gateway.connect(connectionFile, { wallet, identity: appAdmin, discovery: gatewayDiscovery });

        // Get the CA client object from the gateway for interacting with the CA.
        const ca = gateway.getClient().getCertificateAuthority();
        const adminIdentity = gateway.getCurrentIdentity();

        // Register the user, enroll the user, and import the new identity into the wallet.
        const secret = await ca.register({ affiliation: 'org1.department1', enrollmentID: userName, role: 'client' }, adminIdentity);
        const enrollment = await ca.enroll({ enrollmentID: userName, enrollmentSecret: secret });
        const userIdentity = X509WalletMixin.createIdentity(orgMSPID, enrollment.certificate, enrollment.key.toBytes());
        wallet.import(userName, userIdentity);
        console.log('Successfully registered and enrolled admin user ' + userName + ' and imported it into the wallet');

    } catch (error) {
        console.error('Failed to register user ' + userName + error);
        process.exit(1);
    }
}

main();

`

so i haven't tested this pattern for register user @guilhermelionzo
I will take out that part of the code. Usually what happens is that you enroll an admin for an org, and use reference that admin when you register other users for that org

that wasn't really a part of this code pattern, since i mostly just wanted to show raft, and creating a five ordering nodes

closing due to inactivity

Can this issue be addressed?, i am facing the exact issue while trying to register a user. What could be the issue?. should we updtae the connection profile?. I see all things are correct. Any insight will be highly helpful.

Ok, found the solution, we need to pass a caname in getCertificateAuthority() function, which solved the issue.


Community Chats

Hi guys,
I have been asking many requests to create Discord or Telegram chat, so you can discuss things related with the bot.
Unfortunately, I do not have much time to manage or chat because of personal reasons.
However, I definitely encourage you guys to create chats and share your idea about the bot.
Therefore, I created this issue for the chat invitation URLs.
You can simply submit the comment in this issue; thus, others can join your chats.
I will pin this issue.
Note that I will not join any chat. If you have any issue/suggestions, please submit to the Github.

Discord chat - https://discord.gg/Cqy35XnppA

Telegram chat - https://t.me/joinchat/mAz9w-R_-4E1MjBk

Hi guys . That's what ı want to see. Congrat.
I'd like to contrıbute the topıc.
İm a medical doctor and trader for decades.
Coins have many pain but with good algorıtm also gain.
Never do put optıon
Always call and wait

This is what I want to see . Simple but promising.
You know fbonacchı of course.
Custom configuration have to have some optıons .
First custom ema lines that we can configure . 5 Lines enough.
We can trigger with that .
İf price touch ema 144 call. 5 usd
Then look at last 50 candle stick.thıs can be 10-100 config
Eg longest one has %4 range . Make 2nd call that low. Then fallow fıbo. 3rd % 8 and 2 fold 10 usd . 4th 3*%4 and 15 usd.
Also custumıze to points . Eg tp 3rd in 2nd level. İf that bot have config optıons Like that many people want to use it.

Every call can to 1 -5 level higher. Thıs strategy have some pitfalls but ıf bot have config optıons more all of them can be managed.
Eg .longest candle stıck 5 percent example .bot make call at ema 144 5uad then 5 10 15 25 40 that's totally 80 percent drop. You can configure Like that . If drop wıthout any tp don't let more call after 3rd step . This is a simple açexample

Also we can trade 15 minute chart but trading start ema 144 in 4 hour chart or look biggest candlesrick in 4 hour chart

Sorry for my poor English .

我使用该项目交易已经超过6个月，为了更好的提高收益，我为binance-trading-bot创建了一个中文TG社群，欢迎各位加入讨论，分享自己的使用心得。
点击加入

Discord chat - https://discord.gg/Cqy35XnppA Feel free to join and share your profits/settings/questions

Hello, this link expired. Can you please share new one?

when is the new update?

https://t.me/+q0_BpsK4U-tjZjA8 Binance Grid Global Help Channel Chrisleekr

Is there new discord link? If so, please provide.

best settings please


[Event Request] Codeunit 5005271 "Create Delivery Reminder" - OnFilterDelivReminLedgerEntries

Hi, in Codeunit 5005271 "Create Delivery Reminder" we would like to add filters to the delivery reminder entries. To do so, we would need an event publisher like this:

publisher signature:

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Rethrow error on invalid site.url

#108
Definitely need a more descriptive error message. Am I on the right track with this?

@pathawks Great! I'd create your own custom error for this and output the values you have in your URI.join arguments in the error message.
Jekyll::FeedMetaTag::InvalidURLConfigurationError = Class.new(Jekyll::Errors::FatalException)

or something. Then
raise Jekyll::FeedMetaTag::InvalidURLConfigurationError, <<-EOS
One or both of `url` and `baseurl` are invalid in your configuration file. We were unable to create a valid URL with them:

    url = "#{url.inspect}"
    baseurl = "#{baseurl.inspect}"

Please correct them, or remove them from your configuration.
EOS

How does this look? 👀

If we could just use Jekyll's new URL filters, we'd all be a lot better off.

Now that we are using Jekyll's url filters, I think this is a Jekyll issue.


[WP] Added boundary condition lines to Gmsh file

This is work in progress to add boundary condition lines into Gmsh file aiming to be used for Elmer Coupling.

Hello Alejandro,
that already looks really good. Although this is still work in progress, I will merge it, so I can contribute to it (without pushing to your master).
Best regards,
Sebastian


Subquery check_internal_plan does not support LogicalPlan::Unnest

Describe the bug
The Error during planning: Unsupported operator in the subquery plan. error in
https://github.com/apache/datafusion-python/issues/850 is due to
datafusion/optimizer/src/analyzer/subquery.rs's check_internal_plan not handling LogicalPlan::Unnest
To Reproduce
Follow the steps in https://github.com/apache/datafusion-python/issues/850
Expected behavior
Datafusion should handle it
Additional context
No response

I can try to fix this but I don't know where the existing tests for check_inner_plan are.

@kosiew  I would recommend trying to write a SQL query (or rust dataframe example) that shows the same behavior
the sql tests are in https://github.com/apache/datafusion/blob/main/datafusion/sqllogictest/test_files/unnest.slt
The dataframe test are in: https://github.com/apache/datafusion/blob/main/datafusion/core/tests/dataframe/mod.rs

Thanks @alamb


fade text to background everywhere, set clear boundaries

set clear boundaries on what's a name and what's a value and where to align and trim and fade

generic fade rectangle function ready inside TextNode


Error Running Nestjs App with Prisma On Cpanel Shared Hosting

Bug description
Hello Prisma Community, I really had a problem when i want to run my nestjs+prisma app on cpanel, i am struggling with this many days without having any resource or any help in stack overflow or any platform, I am really build my app fastly using nest and prisma compare to other technologies.
But the problem is when i want to deploy my app on cpanel, i need to run npx prisma db push to generate files on node modules, to make my app running properly. but it shows me that error

How to reproduce

Expected behavior
npx prisma db push should generate prisma client files
Prisma information

Environment & setup

OS:  CPANEL (i think CENTOS OR DEBIAN)
Database: MYSQL DATABASE
Node.js version:  I AM WORKING WITH NEST JS APP

Prisma Version
4.3.1

Your application works successfully locally?
Where are you hosting your cpanel?
Have you tried hosting somewhere else?

yeah it is working perfectely untill i deploy it in cpanel, i am hosting this app in cpanel like hostinger, i hosted my app in digital ocean but so expensive , so i want to host it in cpanel. if some one succeffully do that in cpanel may help me in the step of generation the files, npx prisma db push or generate

i will try to add ram right?

this is the  complete log

The error message is telling you there is not enough memory to run the command. Something in cpanel is limiting the memory the process has, and it is not enough to run Prisma. This is almost never a problem (actually, you are the first one that reports this specific one!) so that environment needs to be really memory constrained.
There is unfortunately nothing we can do. Use any other hosting and see if this works.

thank you for your answer, i hope that the problem is on cpanel environment, i will see with other alternative

i test it on other cpanel, other platform, this is the same problem

If cpanel limits the memory of this script step too much, that is expected. Maybe try to find out how much resources are available in that situation.
Can you describe exactly your setup? Then we can try to reproduce this ourselves.

i contact the support also they offer me 12 go ram, but nothing happen

my cpanel is running on top of cloudlinux, why we do guide how you can run prisma in platform like cpanel, a lot of people using cpanel, but if we ignore them it will be a huge lost to prisma, because other platform dosn't store image, images losted every time the system boot but cpanel make a backup and you can control files as you want.

The process that is failing does definitely not have 12GB of RAM available. This should work with a few hundred Megabyte easily.

Can you describe exactly your setup? Then we can try to reproduce this ourselves.

i also try to add npx --max-old-space-size=8192 but didn't work

i also try different package manager like : pnpx and yarn and no one of them succeed
returncode: 1
stdout:

<EMAIL_ADDRESS>prisma
yarn prisma generate

yarn run v1.22.19
$ yarn prisma generate  generate
$ yarn prisma generate  generate generate
$ yarn prisma generate  generate generate generate
$ yarn prisma generate  generate generate generate generate
$ yarn prisma generate  generate generate generate generate generate
$ yarn prisma generate  generate generate generate generate generate generate
$ yarn prisma generate  generate generate generate generate generate generate generate
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
stderr:
error Command failed with signal "SIGABRT".
error Command failed with exit code 1.
error Command failed with exit code 1.
error Command failed with exit code 1.
error Command failed with exit code 1.
error Command failed with exit code 1.
error Command failed with exit code 1.

I also installed prisma globally to use cli but also the same error as npx prisma

I can only repeat myself now:

This is caused by the amount of memory your cpanel installation provides to the command that is running. It is not enough to run it.
If you answer my question "Can you describe exactly your setup? Then we can try to reproduce this ourselves." we can take a look ourselves. Without that response we can not and we will not be able to help you.

Does this also happen when you have a minimal Prisma project (via npx prisma init) and then create a minimal schema file and try to db push that schema?

yeah i already try just try npx prisma --v, and the same erro, every time i try a command using prisma it shows the same error

How can we reproduce this ourselves? What do we have to do to see the same?

you can create a node js application, and add prisma to it with some schema, then add some endpoints using node js and prisma, then deploy the app in cpanel, a lot of video explain how, but if you want me to do the steps, i will record a video and put the link here

Please do, but only for the Cpanel steps. Where do I get a Cpanel? How exactly do I configure it to run a Node app that is using Prisma?

same issue, and i can not fix

chat GPt:
"The "Out of memory" error when using WebAssembly typically means that the JavaScript engine has run out of memory to allocate to the WebAssembly instance. There are several possible reasons why this could be happening:
The WebAssembly module is too large for the available memory. In this case, you could try reducing the size of the module by optimizing the code or reducing the amount of data it uses.
The JavaScript code that is calling the WebAssembly module is leaking memory. You could try using a memory profiler to find and fix any memory leaks in your code.
The JavaScript engine itself is running out of memory. You could try increasing the memory limit of your JavaScript engine using the --max-old-space-size flag. For example, to set the memory limit to 4 GB, you could use node --max-old-space-size=4096.
The computer running the code does not have enough available memory. In this case, you may need to upgrade the computer or run the code on a computer with more memory.
It's also worth noting that the error message can sometimes be caused by bugs in the JavaScript engine or the WebAssembly runtime, so updating to the latest versions of those components may also help."

`stdout:

<EMAIL_ADDRESS>generate
prisma generate
stderr:
/home/mcrhorke/nodevenv/repositories/daraja_stk_push/16/lib/node_modules/prisma/build/index.js:12451
var wasmInstance = new WebAssembly.Instance(wasmModule, imports);
^

RangeError: WebAssembly.Instance(): Out of memory: wasm memory
at ../../node_modules/.pnpm/@prisma+prisma-fmt-wasm<EMAIL_ADDRESS>(/home/mcrhorke/nodevenv/repositories/daraja_stk_push/16/lib/node_modules/prisma/build/index.js:12451:24)
at __require (/home/mcrhorke/nodevenv/repositories/daraja_stk_push/16/lib/node_modules/prisma/build/index.js:14:50)
at Object. (/home/mcrhorke/nodevenv/repositories/daraja_stk_push/16/lib/node_modules/prisma/build/index.js:87712:38)
at Module._compile (node:internal/modules/cjs/loader:1126:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1180:10)
at Module.load (node:internal/modules/cjs/loader:1004:32)
at Function.Module._load (node:internal/modules/cjs/loader:839:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
at node:internal/main/run_main_module:17:47`
having the same issue its been 3weeks now researching on the same no success,,this is really frustrating

Same issue

Been researching on this issue with no success, it became frustrating coz my client wanted the app hosted ASAP,,I  asked them to at least allow me 2weeks,,went a long and learnt Sequelize and luckily I was able to successfully host the application.  Ever since, I stopped using Prisma
From: Tolulope @.>
Sent: Tuesday, 16 May 2023 19:24
To: @.>
Cc: John @.>; @.>
Subject: Re: [prisma/prisma] Error Running Nestjs App with Prisma On Cpanel Shared Hosting (Issue #16805)
Same issue
[Screenshot 2023-05-16 at 17 24 03]https://user-images.githubusercontent.com/31691737/238709974-5099df61-665b-4f8a-b051-219b12074c30.png
—
Reply to this email directly, view it on GitHubhttps://github.com/prisma/prisma/issues/16805#issuecomment-1549989771, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AU5I7OR4CRMASZCAXZT4H4LXGOS3XANCNFSM6AAAAAAS6UQU6E.
You are receiving this because you commented.Message ID: @.***>

I was able to run it but I don't remember how to fix it. maybe it's because 'argon2',


Add NET 9 support, drop NET 6 support

NET 6 is EOL and NET 9 is the latest release.
fixes #5022

@lahma is this ready to be merged?

Should be, I followed earlier PRs and what was needed. Maybe preview quality still needing field testing though.

@lahma can you maybe update with latest develop (conflicts)?

@lahma can you maybe update with latest develop (conflicts)?

I guess you beat me to it 😄

Sorry, I have the day off today and I want to get this rolling today :-)


Airplane Mode

I was wondering if you could please write a powershell code to turn on/off/toggle Windows 11 airplane mode.

This isn't a PowerShell, but a Rust project. I'm also not familiar with Windows 11 airplane mode and have no need for it myself.

OK, thanks for the reply.


pkg/downloader: latest version is not actually correct (as for chartmuseum)

Output of helm version:

$ helm version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"dirty", GoVersion:"go1.14.3"}

Output of kubectl version:

 $ kubectl version
Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.6-beta.0", GitCommit:"e7f962ba86f4ce7033828210ca3556393c377bcc", GitTreeState:"clean", BuildDate:"2020-01-15T08:26:26Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
minikube
Description
Hi there ! I found a little confusing problem these days : When I push new chart to my remote chart registry (self-deployed chartmuseum in my case) , all works fine . However, when I pull the chart without --version (just run helm pull reg/repo ), it always pull the old version of my chart , and is not the latest version which I expect for.
Then , I jump into the both helm and chartmuseum's  codebase , And found something maybe incompatible :

In chartmuseum, the first chart is not the latest one , but the oldest one (as well as the local cache after run helm repo update), as I commented in chartmuseum issue#311.

In helm , helm pull will pull the first chart in HELM_REPOSITORY_CACHE , but I found a TODO in the related code.

Therefore, I think the solution for both side is ok , chartmuseum can sort the charts via created field  and  helm do not have any changes or helm can fix the TODO , and uses the really latest version of the chart .
Sorry for opening an issue here if it is not helm-related bug 🙏

I just realized the chart is already ordered by semantic version , but what about the non-semantic version chart (since the chartmuseum support non-semantic or bad semantic version) ?

@scbizu Helm chart versions are expected to be semantic versions. It might be worth a feature request over there to do some form of validation. helm lint should catch the non-semantic versions.
You can see the code Helm uses to find the matching version here. If Helm runs into an issue parsing a particular version it skips it.
Does that help?
There are ways you can modify your scheme to fit within semver. If you share it we might be able to help.

@mattfarina Hi, thanks for you reply . I missed the Get function when I post the issue , and I see it when I secondly read the code, thanks . But here is the other question,  if we have a list of charts , for example:

0.0.1-beta+hash_tag
0.0.1-beta+other_hash_tag
And so on

They are valid semantic version , and if we only do the semantic version  comparison , we can not distinguish from these charts which one is  the latest version ?
And I self-implement it by adding the createTime comparison when the semantic version is the same .


Thumbnail generation with certain images

Some images are not properly reduced to a thumbnail size. Thumbnail image is empty after upload. Fullsize image is displayed correctly.

Can you send me some of those pictures?

same image as in trello

The image seems to be uploaded and resized correctly. But the frontend doesn't seem to get a download link back for the image.