21.7.3 mainnet stops syncing with "Attempting to update buffer with 213 byte(s) but there is -213 byte(s) left to fill"

Description
I want to besu stay synced without getting stuck.
I encountered this issue on two nodes syncing with mainnet.
Acceptance Criteria
Should not get stuck
Steps to Reproduce (Bug)
Run a synced besu node on 21.7.3
Expected behavior:
Should work
Actual behavior: [What actually happens]
Observe log Attempting to update buffer with 213 byte(s) but there is -213 byte(s) left to fill. Besu will fail to accept that block and get stuck.
The node stops syncing, but there are still many peers connected (25).
Frequency:
I ran two nodes that stopped syncing on the same block.
Seems to resolve itself after recreating the container. I notice this error happens again with other byte values (e.g. Attempting to update buffer with 213 byte(s) but there is 0 byte(s) left to fill) but this doesn't seem to cause the node to get stuck.
Versions (Add all that apply)

Software version: 21.7.3
Java version:openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment 18.9 (build 11.0.12+7)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.12+7, mixed mode, sharing)

OS Name & Version: Debian GNU/Linux 10 (buster)
Kernel Version: x86_64 GNU/Linux
Cloud VM, type, size: GCP n1-standard-2

Additional Information
Logs:
2021-09-16 21:04:29.972+00:00 | nioEventLoopGroup-3-5 | INFO  | SyncTargetManager | Found common ancestor with peer Peer 0x2295bf19ca8f8e934c... at block 13238964
2021-09-16 21:04:36.328+00:00 | EthScheduler-Services-6920 (importBlock) | ERROR | MainnetTransactionProcessor | Critical Exception Processing Transaction
java.lang.IllegalArgumentException: Attempting to update buffer with 213 byte(s) but there is -213 byte(s) left to fill
	at org.hyperledger.besu.crypto.Blake2bfMessageDigest$Blake2bfDigest.update(Blake2bfMessageDigest.java:152)
	at org.bouncycastle.jcajce.provider.digest.BCMessageDigest.engineUpdate(Unknown Source)
	at java.base/java.security.MessageDigest.update(Unknown Source)
	at org.apache.tuweni.bytes.ArrayWrappingBytes.update(ArrayWrappingBytes.java:115)
	at org.hyperledger.besu.crypto.Hash.digestUsingAlgorithm(Hash.java:62)
	at org.hyperledger.besu.crypto.Hash.blake2bf(Hash.java:106)
	at org.hyperledger.besu.ethereum.mainnet.precompiles.BLAKE2BFPrecompileContract.compute(BLAKE2BFPrecompileContract.java:69)
	at org.hyperledger.besu.ethereum.mainnet.MainnetMessageCallProcessor.executePrecompile(MainnetMessageCallProcessor.java:131)
	at org.hyperledger.besu.ethereum.mainnet.MainnetMessageCallProcessor.start(MainnetMessageCallProcessor.java:60)
	at org.hyperledger.besu.ethereum.mainnet.AbstractMessageProcessor.process(AbstractMessageProcessor.java:163)
	at org.hyperledger.besu.ethereum.mainnet.MainnetTransactionProcessor.process(MainnetTransactionProcessor.java:454)
	at org.hyperledger.besu.ethereum.mainnet.MainnetTransactionProcessor.processTransaction(MainnetTransactionProcessor.java:361)
	at org.hyperledger.besu.ethereum.mainnet.AbstractBlockProcessor.processBlock(AbstractBlockProcessor.java:161)
	at org.hyperledger.besu.ethereum.mainnet.AbstractBlockProcessor.processBlock(AbstractBlockProcessor.java:42)
	at org.hyperledger.besu.ethereum.mainnet.BlockProcessor.processBlock(BlockProcessor.java:75)
	at org.hyperledger.besu.ethereum.MainnetBlockValidator.processBlock(MainnetBlockValidator.java:150)
	at org.hyperledger.besu.ethereum.MainnetBlockValidator.validateAndProcessBlock(MainnetBlockValidator.java:108)
	at org.hyperledger.besu.ethereum.mainnet.MainnetBlockImporter.importBlock(MainnetBlockImporter.java:45)
	at org.hyperledger.besu.ethereum.core.BlockImporter.importBlock(BlockImporter.java:44)
	at org.hyperledger.besu.ethereum.eth.sync.fullsync.FullImportBlockStep.accept(FullImportBlockStep.java:54)
	at org.hyperledger.besu.ethereum.eth.sync.fullsync.FullImportBlockStep.accept(FullImportBlockStep.java:31)
	at org.hyperledger.besu.services.pipeline.CompleterStage.run(CompleterStage.java:37)
	at org.hyperledger.besu.services.pipeline.Pipeline.lambda$runWithErrorHandling$3(Pipeline.java:152)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
2021-09-16 21:04:36.329+00:00 | EthScheduler-Services-6920 (importBlock) | INFO  | AbstractBlockProcessor | Block processing error: transaction invalid 'INTERNAL_ERROR'. Block 0xb738c748d52d0c2f1a66a2306078a763ee99ad3d9a126c250036a43e91b539e9 Transaction 0xfc55eac21b7803e27d65ad9146b606b206cc0aa830a06d117baf2a2e82fa055c
2021-09-16 21:04:36.330+00:00 | EthScheduler-Services-6920 (importBlock) | WARN  | PipelineChainDownloader | Invalid block detected.  Disconnecting from sync target. Failed to import block: Invalid block at #13238965 (0xb738c748d52d0c2f1a66a2306078a763ee99ad3d9a126c250036a43e91b539e9)
2021-09-16 21:04:36.330+00:00 | EthScheduler-Services-6920 (importBlock) | WARN  | PipelineChainDownloader | Chain download failed. Restarting after short delay.
java.util.concurrent.CompletionException: org.hyperledger.besu.ethereum.eth.sync.tasks.exceptions.InvalidBlockException: Failed to import block: Invalid block at #13238965 (0xb738c748d52d0c2f1a66a2306078a763ee99ad3d9a126c250036a43e91b539e9)
	at java.base/java.util.concurrent.CompletableFuture.encodeRelay(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.completeRelay(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.completeExceptionally(Unknown Source)
	at org.hyperledger.besu.services.pipeline.Pipeline.abort(Pipeline.java:180)
	at org.hyperledger.besu.services.pipeline.Pipeline.lambda$runWithErrorHandling$3(Pipeline.java:159)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.hyperledger.besu.ethereum.eth.sync.tasks.exceptions.InvalidBlockException: Failed to import block: Invalid block at #13238965 (0xb738c748d52d0c2f1a66a2306078a763ee99ad3d9a126c250036a43e91b539e9)
	at org.hyperledger.besu.ethereum.eth.sync.fullsync.FullImportBlockStep.accept(FullImportBlockStep.java:55)
	at org.hyperledger.besu.ethereum.eth.sync.fullsync.FullImportBlockStep.accept(FullImportBlockStep.java:31)
	at org.hyperledger.besu.services.pipeline.CompleterStage.run(CompleterStage.java:37)
	at org.hyperledger.besu.services.pipeline.Pipeline.lambda$runWithErrorHandling$3(Pipeline.java:152)
	... 5 more
2021-09-16 21:07:55.851+00:00 | nioEventLoopGroup-3-3 | INFO  | SyncTargetManager | Found common ancestor with peer Peer 0xeaa7bc9bd297c70f79... at block 13238964
2021-09-16 21:07:56.066+00:00 | EthScheduler-Services-6921 (downloadBodies) | INFO  | AbstractRetryingPeerTask | No peers available, waiting for peers: 25
2021-09-16 21:10:20.339+00:00 | nioEventLoopGroup-3-3 | INFO  | SyncTargetManager | Found common ancestor with peer Peer 0xbd71c6b2d202b8faf6... at block 13238964
2021-09-16 21:10:20.370+00:00 | EthScheduler-Services-6926 (downloadBodies) | INFO  | AbstractRetryingPeerTask | No peers available, waiting for peers: 25
2021-09-16 21:10:25.646+00:00 | nioEventLoopGroup-3-3 | INFO  | AbstractRetryingPeerTask | No peers available, waiting for peers: 25
2021-09-16 21:10:30.890+00:00 | nioEventLoopGroup-3-3 | INFO  | AbstractRetryingPeerTask | No peers available, waiting for peers: 25

Please indicate which network or chain you were syncing. Please provide information on your OS and machine architecture. Please let us know if native bindings were loaded on startup (looking for the first 100 lines of your log at startup time).
Thank you for your report.

@atoulme Thanks for looking at this.

Startup logs

2021-09-16 21:44:48.090+00:00 | main | INFO  | Besu | Using LibEthPairings native alt bn128
2021-09-16 21:44:48.094+00:00 | main | INFO  | Besu | Using the native implementation of the signature algorithm
2021-09-16 21:44:48.100+00:00 | main | INFO  | Besu | Starting Besu version: besu/v21.7.3/linux-x86_64/oracle_openjdk-java-11
2021-09-16 21:44:48.378+00:00 | main | INFO  | Besu | Static Nodes file = /data/static-nodes.json
2021-09-16 21:44:48.380+00:00 | main | INFO  | StaticNodesParser | StaticNodes file /data/static-nodes.json does not exist, no static connections will be created.
2021-09-16 21:44:48.381+00:00 | main | INFO  | Besu | Connecting to 0 static nodes.
2021-09-16 21:44:48.384+00:00 | main | INFO  | Besu | Security Module: localfile
2021-09-16 21:44:48.407+00:00 | main | INFO  | DatabaseMetadata | Lookup database metadata file in data directory: /data
2021-09-16 21:44:48.493+00:00 | main | INFO  | RocksDBKeyValueStorageFactory | Existing database detected at /data. Version 1
2021-09-16 21:44:50.584+00:00 | main | INFO  | KeyPairUtil | Loaded public key 0x017cb427027149128597e841b79c76a29b2ce4aa5dadb3d289370eea79a98a144080b319da0c9a6163240d204c42eab907a4000870c4438f116c65308e9b57c1 from /data/key
2021-09-16 21:44:50.721+00:00 | main | INFO  | ProtocolScheduleBuilder | Protocol schedule created with milestones: [Frontier: 0, Homestead: 1150000, DaoRecoveryInit: 1920000, DaoRecoveryTransition: 1920001, Homestead: 1920010, TangerineWhistle: 2463000, SpuriousDragon: 2675000, Byzantium: 4370000, Petersburg: 7280000, Istanbul: 9069000, MuirGlacier: 9200000, Berlin: 12244000, London: 12965000]
2021-09-16 21:44:51.448+00:00 | main | INFO  | FastDownloaderFactory | Fast sync was requested, but cannot be enabled because the local blockchain is not empty.
2021-09-16 21:44:51.468+00:00 | main | INFO  | RunnerBuilder | Detecting NAT service.
2021-09-16 21:44:51.618+00:00 | main | INFO  | Runner | Starting Ethereum main loop ...
2021-09-16 21:44:51.618+00:00 | main | INFO  | MetricsHttpService | Starting metrics http service on <IP_ADDRESS>:9094
2021-09-16 21:44:51.799+00:00 | main | INFO  | KubernetesNatManager | Starting kubernetes NAT manager.
2021-09-16 21:44:51.799+00:00 | vert.x-eventloop-thread-3 | INFO  | MetricsHttpService | Metrics service started and listening on 9094:9094
ANTLR Tool version 4.7.1 used for code generation does not match the current runtime version 4.8ANTLR Runtime version 4.7.1 used for parser compilation does not match the current runtime version 4.8ANTLR Tool version 4.7.1 used for code generation does not match the current runtime version 4.8ANTLR Runtime version 4.7.1 used for parser compilation does not match the current runtime version 4.8SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/besu/lib/log4j-slf4j-impl-2.14.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/besu/lib/logback-classic-1.2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
2021-09-16 21:44:52.160+00:00 | main | INFO  | NetworkRunner | Starting Network.
2021-09-16 21:44:52.163+00:00 | main | INFO  | DefaultP2PNetwork | Starting DNS discovery with URL<EMAIL_ADDRESS>2021-09-16 21:44:52.225+00:00 | nioEventLoopGroup-2-1 | INFO  | RlpxAgent | P2P RLPx agent started and listening on /<IP_ADDRESS>:30303.
2021-09-16 21:44:52.226+00:00 | main | INFO  | PeerDiscoveryAgent | Starting peer discovery agent on host=<IP_ADDRESS>, port=30303
2021-09-16 21:44:52.243+00:00 | vert.x-eventloop-thread-4 | INFO  | VertxPeerDiscoveryAgent | Started peer discovery agent successfully, on effective host=<IP_ADDRESS> and port=30303
2021-09-16 21:44:52.244+00:00 | vert.x-eventloop-thread-4 | INFO  | PeerDiscoveryAgent | P2P peer discovery agent started and listening on /<IP_ADDRESS>:30303
2021-09-16 21:44:52.295+00:00 | vert.x-eventloop-thread-4 | INFO  | PeerDiscoveryAgent | Writing node record to disk. NodeRecord{seq=74, publicKey=0x03017cb427027149128597e841b79c76a29b2ce4aa5dadb3d289370eea79a98a14, udpAddress=Optional[/<IP_ADDRESS>:30303], tcpAddress=Optional[/<IP_ADDRESS>:30303], asBase64=-Je4QJWTEcqUmqW1gE_rOk5DMa0dxzIzE6VITdTkAeQi96Pzb5nJ41spP_zxk48TWZUfX7j8oX5s7mrf8CyK_mRAKwtKg2V0aMfGhLcVB32AgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQMBfLQnAnFJEoWX6EG3nHaimyzkql2ts9KJNw7qeamKFIN0Y3CCdl-DdWRwgnZf, nodeId=0x3163108181fdee800ddd854ba1ba49093909e29bb4fdfa524634f6735c1ee460, customFields={tcp=30303, udp=30303, ip=0x7f000001, eth=[[0xb715077d, 0x]], id=V4, secp256k1=0x03017cb427027149128597e841b79c76a29b2ce4aa5dadb3d289370eea79a98a14}}
2021-09-16 21:44:52.372+00:00 | main | INFO  | DefaultP2PNetwork | Enode URL enode://017cb427027149128597e841b79c76a29b2ce4aa5dadb3d289370eea79a98a144080b319da0c9a6163240d204c42eab907a4000870c4438f116c65308e9b57c1@<IP_ADDRESS>:30303
2021-09-16 21:44:52.373+00:00 | main | INFO  | DefaultP2PNetwork | Node address 0xa1ba49093909e29bb4fdfa524634f6735c1ee460
2021-09-16 21:44:52.378+00:00 | main | INFO  | DefaultSynchronizer | Starting synchronizer.
2021-09-16 21:44:52.380+00:00 | main | INFO  | FullSyncDownloader | Starting full sync.
2021-09-16 21:44:52.381+00:00 | StatePruning-0 | INFO  | Pruner | Starting Pruner.
2021-09-16 21:44:52.382+00:00 | main | INFO  | FullSyncTargetManager | No sync target, waiting for peers: 0
2021-09-16 21:44:52.394+00:00 | main | INFO  | JsonRpcHttpService | Starting JSON-RPC service on <IP_ADDRESS>:9091
2021-09-16 21:44:52.393+00:00 | StatePruning-0 | ERROR | Besu | Uncaught exception in thread "StatePruning-0"
org.hyperledger.besu.plugin.services.exception.StorageException: org.rocksdb.RocksDBException: DeleteRangeCF not implemented
        at org.hyperledger.besu.plugin.services.storage.rocksdb.segmented.RocksDBColumnarKeyValueStorage.clear(RocksDBColumnarKeyValueStorage.java:211)
        at org.hyperledger.besu.plugin.services.storage.rocksdb.segmented.RocksDBColumnarKeyValueStorage.clear(RocksDBColumnarKeyValueStorage.java:62)
        at org.hyperledger.besu.services.kvstore.SegmentedKeyValueStorageAdapter.clear(SegmentedKeyValueStorageAdapter.java:40)
        at org.hyperledger.besu.ethereum.worldstate.MarkSweepPruner.clearMarks(MarkSweepPruner.java:229)
        at org.hyperledger.besu.ethereum.worldstate.MarkSweepPruner.prepare(MarkSweepPruner.java:124)
        at org.hyperledger.besu.ethereum.worldstate.Pruner.lambda$start$0(Pruner.java:97)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.rocksdb.RocksDBException: DeleteRangeCF not implemented
        at org.rocksdb.RocksDB.deleteRange(Native Method)
        at org.rocksdb.RocksDB.deleteRange(RocksDB.java:1493)
        at org.hyperledger.besu.plugin.services.storage.rocksdb.segmented.RocksDBColumnarKeyValueStorage.clear(RocksDBColumnarKeyValueStorage.java:206)
        ... 8 more
2021-09-16 21:44:52.422+00:00 | vert.x-eventloop-thread-8 | INFO  | JsonRpcHttpService | JSON-RPC service started and listening on <IP_ADDRESS>:9091
2021-09-16 21:44:52.424+00:00 | main | INFO  | WebSocketService | Starting Websocket service on <IP_ADDRESS>:9092
2021-09-16 21:44:52.434+00:00 | vert.x-eventloop-thread-10 | INFO  | WebSocketService | Websocket service started and listening on <IP_ADDRESS>:9092
2021-09-16 21:44:52.436+00:00 | main | INFO  | Runner | Ethereum main loop is up.

Maybe it was just a bad peer or something. I felt this needed a report because the server would get stuck for many blocks without restarting. Besu's liveness is very valuable.

Are you unblocked now?

Hi @leontastic - realise it's been a while but we have made some improvements in peering and syncing (eg 22.1.0 had fast sync optimisations). Additionally we are beginning a holistic assessment of peering behavior including any outstanding issues. So we're hoping that either those changes have it fixed already, or that you're able to give us an update if you're still having related issues?


IL: Add 2019 committees

This PR is a bit of a spitball.
The committee memberships are not resolved.  The to_yaml.py doesn't do it. and I don't see any other code in the people scripts that looks like it might.  If it isn't clear what I mean, newly imported yaml memberships look like:
memberships:
- name: David Koehler
  start_date: '2018'
  end_date: '2019'
- name: Laura Ellman
  start_date: '2018'
  end_date: '2019'

but the existing ones have the people id's:
memberships:
- id: ocd-person/f8e78760-4ec7-44f4-a00f-54f42fb834d5
  name: Napoleon Harris, III
  role: chairperson
  start_date: '2017'
  end_date: '2018'
- id: ocd-person/86147150-e615-43a2-a748-e95d06627ad3
  name: Scott M. Bennett
  role: vice-chairperson
  start_date: '2017'
  end_date: '2018'

Matching these up manually is prohibitively costly; Illinois has over a hundred committees, probably over a thousand individual memberships.  I see some other states have unresolved memberships, so I'm guessing it won't break anything.
In order to have correct memberships over time, I don't think the old committees should go away, or that these should be merged as individual files.  But it's just a guess.
Related: https://github.com/openstates/openstates/issues/2821, https://github.com/openstates/openstates/pull/2869

Pull Request Test Coverage Report for Build 346

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

Totals

Change from base Build 344:
0.0%

Covered Lines:
928

Relevant Lines:
1315

💛  - Coveralls

The lint errors are for other states.


chore(4.5): release 1.8.19

:robot: I have created a release beep boop
1.8.19 (2023-07-10)
Bug Fixes

topology spread  constrains app label selector (9e374ba)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/GluuFederation/cloud-native-edition/releases/tag/v1.8.19 :sunflower:


Karina/wmdp 119 alternate benefits

Ticket
https://wicmtdp.atlassian.net/browse/WMDP-119
Changes

What was added, updated, or removed in this PR.

adds alternate page
adds conditional routing to eligibility page

if "None of the above" is selected for second question, "continue" button routes to alternate benefits page

Context for reviewers

Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers. Explain how the changes were verified.

run jest tests
assert that you are routed to alternate benefits page if you select none of the above for second question in eligibility page
assert that eligibility page routes to  income page by default

Testing

Screenshots, GIF demos, code examples or output to help show the changes working as expected. ProTip: you can drag and drop or paste images into this textbox.

https://user-images.githubusercontent.com/14364118/184664620-ca145f6f-59c6-466b-a7c3-2fd32574c9d2.mov

It doesn't look like these changes will be going in to main. Are you combining these changes with another ticket?


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>chore(scripts): cover@#overwrite c8 --temp-directory build/coverage ava && c8 report -r lcov --temp-directory build/coverage
chore(package): add nyc from template
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

Coverage remained the same at 90.909% when pulling 844aa1e41e5389c89fb4ab53e41ffe9131ba18be on template-sync-1 into b38915737e4b2ab9a709600042ccfc55870baf2f on master.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #475   +/-   ##
=======================================
  Coverage   95.12%   95.12%
=======================================
  Files           1        1
  Lines          41       41
=======================================
  Hits           39       39
  Misses          2        2

Continue to review full report at Codecov.

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


WebGL Support

Thank you for the great plugin!
But it seems that it doesn't work on webgl. On windows it's ok.
I run your test c# code and it shows just a white Scaffold.

Yes, It's never tested on WebGL, and for now, I have no time to support this.
Sorry for that.
If you are willing to support running on WebGL, please submit a PR, thanks.


[SPARK-15750][MLLib][PYSPARK] Constructing FPGrowth fails when no numPartitions specified in pyspark

What changes were proposed in this pull request?
Change FPGrowth from private to private[spark]. If no numPartitions is specified, then default value -1 is used. But -1 is only valid in the construction function of FPGrowth, but not in setNumPartitions. So I make this change and use the constructor directly rather than using set method.
How was this patch tested?
Unit test is added

Test build #59923 has started for PR 13493 at commit 56cd7cf.

Test build #59923 has finished for PR 13493 at commit 56cd7cf.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

lgtm cc: @MLnick

Shall we change the logic in the Python wrapper and set numPartitions correctly if it is -1? Please also update the PR description to add more details to the changes.

Test build #3236 has started for PR 13493 at commit 56cd7cf.

Test build #3236 has finished for PR 13493 at commit 56cd7cf.

This patch passes all tests.
This patch does not merge cleanly.
This patch adds no public classes.

Pinging!  Is this still active?

@jkbradley I will update the PR soon

@mengxr @jkbradley  I think we should keep as less logic in python side as possible.  So I didn't update the PR, please help review. Thanks

Test build #65071 has started for PR 13493 at commit f0d37c8.

Test build #65071 has finished for PR 13493 at commit f0d37c8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

This looks pretty reasonable to me, the only thing is (and its relatively minor) testing the default param might be better as a tests.py test rather than as a doc test since the doctests are part of the documentation and we might not need this in the docs along with the current example.

Same here, looks fine except for @holdenk 's comment.  Thanks!

Ping --- let me know if you'd like someone to take it over.  Thanks!

Sorry, I am in vacation. Will update it next week.

@zjffdu Enjoy vacation and no worries - I don't think this is blocking anything and we can circle back in a week :)

Test build #66589 has started for PR 13493 at commit e8fefc0.

Test build #66589 has finished for PR 13493 at commit e8fefc0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

PR is updated, @holdenk @jkbradley

ping @jkbradley @holdenk

Test build #81076 has started for PR 13493 at commit e8fefc0.

Test build #81076 has finished for PR 13493 at commit e8fefc0.

This patch fails PySpark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81076/
Test FAILed.

ping @zjffdu Looks reasonable fix, But pls resolve the conflicts! Thanks!

Test build #82315 has started for PR 13493 at commit 3575444.

Test build #82319 has started for PR 13493 at commit fbbcd26.

Test build #82315 has finished for PR 13493 at commit 3575444.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82315/
Test FAILed.

Merged build finished. Test FAILed.

Test build #82319 has finished for PR 13493 at commit fbbcd26.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/82319/
Test FAILed.

retest this please

Test build #82330 has started for PR 13493 at commit fbbcd26.

Test build #82330 has finished for PR 13493 at commit fbbcd26.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

Test build #4167 has started for PR 13493 at commit fbbcd26.

LGTM pending fresh tests
Sorry for the delay!

Test build #4167 has finished for PR 13493 at commit fbbcd26.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Thanks @jkbradley The failed tests seems unrelated.

LGTM retest this please

Test build #90147 has started for PR 13493 at commit fbbcd26.

Test build #90147 has finished for PR 13493 at commit fbbcd26.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

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

LGTM!

Merging with master
Thanks all!
@zjffdu Did you want to backport this to branch-2.3 too?


linearGAM with sklearn gridsearchCV

Hi
I tried implementing LinearGAM with sklearn's GridsearchCV and got an error when gridsearchCV tried to clone the estimator. The code is below:
def gam(x, y):
    lams = np.random.rand(10, x.shape[1])
    lams = np.exp(lams)
    linear_gam = LinearGAM(n_splines=10, max_iter=1000)
    parameters = {
        'lam': [x for x in lams]
    }
    gam_cv = GridSearchCV(linear_gam, parameters, cv=5, iid=False, return_train_score=True,
 refit=True, scoring='neg_mean_squared_error')
    gam_cv.fit(x, y)
    cv_results_df = pd.DataFrame(gam_cv.cv_results_).sort_values(by='mean_test_score', ascending=False)
    return gam_cv, cv_results_df

gam_rank, gam_cv_results = gam(x_all, y_all)
I get the error

RuntimeError                              Traceback (most recent call last)
 in
----> 1 gam_rank, gam_cv_results = gam(x_all, y_all)
 in gam(x, y)
7     }
8     gam_cv = GridSearchCV(linear_gam, parameters, cv=5, iid=False, return_train_score=True, >refit=True, scoring='neg_mean_squared_error')
----> 9     gam_cv.fit(x, y)
10     cv_results_df = pd.DataFrame(gam_cv.cv_results_).sort_values(by='mean_test_score', >ascending=False)
11     return gam_cv, cv_results_df
C:\Anaconda3\lib\site-packages\sklearn\model_selection_search.py in fit(self, X, y, groups, **fit_params)
630         n_splits = cv.get_n_splits(X, y, groups)
631
--> 632         base_estimator = clone(self.estimator)
633
634         parallel = Parallel(n_jobs=self.n_jobs, verbose=self.verbose,
C:\Anaconda3\lib\site-packages\sklearn\base.py in clone(estimator, safe)
73             raise RuntimeError('Cannot clone object %s, as the constructor '
74                                'either does not set or modifies parameter %s' %
---> 75                                (estimator, name))
76     return new_object
77
RuntimeError: Cannot clone object LinearGAM(callbacks=['deviance', 'diffs'], fit_intercept=True,
max_iter=1000, n_splines=10, scale=None, terms='auto', tol=0.0001,
verbose=False), as the constructor either does not set or modifies parameter callbacks

The dataset I used was sklearn's california housing dataset.

@hongkahjun unfortunately this is a somewhat deep issue. When writing the new terms functionality, i diverged from sklearn's requirement that the estimator instance's parameters are not changed after looking at data (even though the coefficients are allowed to change).
This will require a deeper fix right now :/

Getting what looks like the same problem when using LinearGAM it with sklearn's TransformedTargetRegressor.
Admittedly knowing absolutely nothing about the motivations for the changes you made, it seems like diverging from such an important package's requirements would be a bad idea?  I know that if I can't get it to play nice with my infrastructure I'm probably are going to have to abandon it.'
Is there an older version that keeps to sklearn's requirements?

@dswah
I see two solutions to this issue:

According to the SkLearn developer guide since the terms depend on the data it could be argued that they are "estimated parameters". This would allow for self.terms_ to be assigned from self.terms in _validate_data_dep_params and then self.terms_ to be used throughout. This would, I believe, follow the contract set out by SkLearn.

Another option would be to overload self.get_params() to return self.terms rather than the terms that the estimator was initialized with?

Actually, having looked at this further this does not seem to have anything at all to do with terms it instead occurs because the default value of the callbacks keyword argument for every GAM estimator is a list. This tends to be a big no no in Python as lists are mutable and so leads to confusing situations where it is possible to change the default value of a keyword argument.
I believe this was the root of this bug. When I instead apply the changes is #267 GridSearchCV succeeds with no issues.

It seems this can be simply fixed by adding "callbacks=callbacks," to line 2267 of pygam.py.

Also having this issue

Is this not fixed yet?

https://github.com/dswah/pyGAM/issues/291

It seems this can be simply fixed by adding "callbacks=callbacks," to line 2267 of pygam.py.

here is complete correction to pygam.py (line 2461):
super(LinearGAM, self).init(
callbacks=callbacks,
terms=terms,
distribution=NormalDist(scale=self.scale),
link='identity',
max_iter=max_iter,
tol=tol,
fit_intercept=fit_intercept,
verbose=verbose,
**kwargs,
)


Document MSRV

Is there a minimal supported Rust version for this crate? It seems to require associated constants, which makes it incompatible with older Rust versions.

I pulled the code from KAS for which the MSRV is "the latest release", but we should probably be a bit more careful here.

Sure, that's fair! It would be nice to document this somewhere.
I used easy-cast to get rid of my dependency on the unmaintained conv crate in average, which worked well but turned out to be incompatible with Rust 1.36. (the MSRV of Rand).

Why does it require associated consts? For LBOUND/UBOUND? If so they could just be moved to the lib root.
I'll try testing later if you like but slow internet makes it a pain to install various Rustc versions.

This is the error:
error[E0599]: no associated item named `MIN` found for type `i8` in the current scope
   --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/easy-cast-0.2.0/src/lib.rs:319:46
    |
319 |                     const LBOUND: $x = <$y>::MIN as $x;
    |                                              ^^^ associated item not found in `i8`
...
353 | impl_float!(f32: i8, i16, i32, i64, i128, isize);
    | ------------------------------------------------- in this macro invocation

So I think it is about using the associated constant in std, which is not available in old Rust versions. Should be easy to fix, but I don't know whether you want to bother to support such old Rust versions.

So minimum viable version is probably 1.43.0, eleven months old. 1.36.0 is approx twenty months old; from discussions I remember hardly anyone cares beyond about six months. It seems silly bumping the rand version for this though, so I'm happy to support older rustc here (probably requires $t: tt or similar in the macro to make std::$t::MIN work).

I think supporting older Rustc is easy enough, but there may be another problem with using this in rand: we expect no_std to work.
This crate doesn't use any trig/exponential float ops, but does use ceil, floor and round, and it seems those are not supported in core.

I used easy-cast to get rid of my dependency on the unmaintained conv crate in average, which worked well but turned out to be incompatible with Rust 1.36. (the MSRV of Rand).

But average is only used as a dev-depenendency in rand_distr, so why do we care about Rust 1.36?

Don't we run the tests on 1.36 too?

CI for 1.36.0 is done.


fix outPackets counter

Need to check that, but I feel like the patch will not fix packet counting, but will count sent chunks. And a chunk on top of the transport may contain multiple packets. I guess it depends what we expect outPackets to count.

@akallabeth So is there any good place to increment the packet counter? right now it's almost never updated


more efficient sync?

This is maybe a lightCouch q, but I wonder if synchronizeWithDb could be made more efficient with something such as:

md5 hash the document, do a query including that hash?
keep a 'revision number' in the js file (manually updated) and only sync if it changes?

This API changed in 2.0.0, the equivalent functionality now is Database.getDesignDocumentManager().put(DesignDocument).
This method performs a GET of the design document from the database and does an equality check with the supplied DesignDocument (which can be obtained from a js file with DesignDocumentManager.fromFile()). If the equality check fails then an update will be performed, but not otherwise.
I think to get the behaviour you want you just need to make sure that the _rev of the design document is up-to-date in your js file after a sync (so that the documents will be equal if there are no other changes). You can get it from the Response object returned from the put.

Closing based on the above.


Improve spanish translation of repost

Use "republicar" instead of "volver a publicar"

There's a PR open for updating the Spanish localization: #6094
Could I suggest you discuss changes on that PR?
cc: @elenatorro

Sure! Elena is a good friend 😄

@surfdude29 the other PR has been merged, so I'm reopening this one.

@hogaza in case you want to help, as you said here.


release v0.3.25

Let's release https://github.com/japaric/xargo/pull/331.

bors r+

failed to get 200 response from `[https://crates.io/api/v1/crates/cfg-if/0.1.10/download`,](https://crates.io/api/v1/crates/cfg-if/0.1.10/download%60,) got 403

bors retry

crates.io seems to be having a bad time...

bors retry


Handle hosted mode overlaps

Mostly https://issues.redhat.com/browse/ACM-12032, but also a potential fix for some continues ConstraintsNotSatisfiable problems in the tests.

Issue during first run (made it all the way to the hosted mode test though)
[FAIL] Testing OperatorPolicy Test CRD deletion delayed because of a finalizer [It] Should become compliant after the finalizer is removed [supports-hosted]
/home/runner/work/config-policy-controller/config-policy-controller/test/e2e/case38_install_operator_test.go:2724

• [FAILED] [73.221 seconds]
Testing OperatorPolicy Test CRD deletion delayed because of a finalizer [It] Should become compliant after the finalizer is removed [supports-hosted]
/home/runner/work/config-policy-controller/config-policy-controller/test/e2e/case38_install_operator_test.go:2720

  Timeline >>
  [FAILED] in [It] - /home/runner/work/config-policy-controller/config-policy-controller/test/e2e/case38_install_operator_test.go:2724 @ 06/10/24 16:24:30.51
  Debug info for failure.
  policy JSON: {
    "apiVersion": "policy.open-cluster-management.io/v1beta1",
    "kind": "OperatorPolicy",
    "metadata": {
      "annotations": {
        "policy.open-cluster-management.io/parent-policy-compliance-db-id": "124",
        "policy.open-cluster-management.io/policy-compliance-db-id": "64"
      },
      "creationTimestamp": "2024-06-10T16:23:06Z",
      "generation": 3,
      "labels": {
        "policy.open-cluster-management.io/cluster-name": "managed",
        "policy.open-cluster-management.io/cluster-namespace": "managed"
      },
      "name": "oppol-mustnothave",
      "namespace": "managed",
      "ownerReferences": [
        {
          "apiVersion": "policy.open-cluster-management.io/v1",
          "kind": "Policy",
          "name": "parent-policy",
          "uid": "65e40d37-0746-4224-96ab-26907f501c2b"
        }
      ],
      "resourceVersion": "15156",
      "uid": "8e29a727-55be-4d8c-a215-522b639752ae"
    },
    "spec": {
      "complianceConfig": {
        "catalogSourceUnhealthy": "Compliant",
        "deploymentsUnavailable": "NonCompliant",
        "upgradesAvailable": "Compliant"
      },
      "complianceType": "mustnothave",
      "remediationAction": "enforce",
      "removalBehavior": {
        "clusterServiceVersions": "Delete",
        "customResourceDefinitions": "Delete",
        "operatorGroups": "DeleteIfUnused",
        "subscriptions": "Delete"
      },
      "severity": "medium",
      "subscription": {
        "channel": "stable-3.10",
        "name": "project-quay",
        "namespace": "operator-policy-testns",
        "source": "operatorhubio-catalog",
        "sourceNamespace": "olm"
      },
      "upgradeApproval": "Automatic"
    },
    "status": {
      "compliant": "NonCompliant",
      "conditions": [
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "MustNotHave policies ignore kind CatalogSource",
          "reason": "CatalogSourceNotApplicable",
          "status": "False",
          "type": "CatalogSourcesUnhealthy"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "the ClusterServiceVersion is not present",
          "reason": "ClusterServiceVersionNotPresent",
          "status": "True",
          "type": "ClusterServiceVersionCompliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "NonCompliant; the policy spec is valid, the OperatorGroup is not present, the Subscription is not present, there are no relevant InstallPlans in the namespace, the ClusterServiceVersion is not present, the CustomResourceDefinition has a deletion timestamp, MustNotHave policies ignore kind Deployment, MustNotHave policies ignore kind CatalogSource",
          "reason": "NonCompliant",
          "status": "False",
          "type": "Compliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "the CustomResourceDefinition has a deletion timestamp",
          "reason": "CustomResourceDefinitionDeleting",
          "status": "False",
          "type": "CustomResourceDefinitionCompliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "MustNotHave policies ignore kind Deployment",
          "reason": "DeploymentNotApplicable",
          "status": "True",
          "type": "DeploymentCompliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "there are no relevant InstallPlans in the namespace",
          "reason": "NoInstallPlansFound",
          "status": "True",
          "type": "InstallPlanCompliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "the OperatorGroup is not present",
          "reason": "OperatorGroupNotPresent",
          "status": "True",
          "type": "OperatorGroupCompliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:22Z",
          "message": "the Subscription is not present",
          "reason": "SubscriptionNotPresent",
          "status": "True",
          "type": "SubscriptionCompliant"
        },
        {
          "lastTransitionTime": "2024-06-10T16:23:06Z",
          "message": "the policy spec is valid",
          "reason": "PolicyValidated",
          "status": "True",
          "type": "ValidPolicySpec"
        }
      ],
      "relatedObjects": [
        {
          "compliant": "Compliant",
          "object": {
            "apiVersion": "operators.coreos.com/v1alpha1",
            "kind": "CatalogSource",
            "metadata": {
              "name": "operatorhubio-catalog",
              "namespace": "olm"
            }
          },
          "properties": {
            "uid": "3cff6adc-14d2-413a-9222-dc1222cb59cb"
          },
          "reason": "Resource found but will not be handled in mustnothave mode"
        },
        {
          "compliant": "Compliant",
          "object": {
            "apiVersion": "operators.coreos.com/v1alpha1",
            "kind": "ClusterServiceVersion",
            "metadata": {
              "name": "-",
              "namespace": "operator-policy-testns"
            }
          },
          "reason": "Resource not found as expected"
        },
        {
          "compliant": "NonCompliant",
          "object": {
            "apiVersion": "apiextensions.k8s.io/v1",
            "kind": "CustomResourceDefinition",
            "metadata": {
              "name": "quayregistries.quay.redhat.com"
            }
          },
          "reason": "The object is being deleted but has not been removed yet"
        },
        {
          "compliant": "Compliant",
          "object": {
            "apiVersion": "apps/v1",
            "kind": "Deployment",
            "metadata": {
              "name": "quay-operator-tng",
              "namespace": "operator-policy-testns"
            }
          },
          "reason": "Resource not found as expected"
        },
        {
          "compliant": "Compliant",
          "object": {
            "apiVersion": "operators.coreos.com/v1alpha1",
            "kind": "InstallPlan",
            "metadata": {
              "name": "-",
              "namespace": "operator-policy-testns"
            }
          },
          "reason": "There are no relevant InstallPlans in this namespace"
        },
        {
          "compliant": "Compliant",
          "object": {
            "apiVersion": "operators.coreos.com/v1",
            "kind": "OperatorGroup",
            "metadata": {
              "name": "-",
              "namespace": "operator-policy-testns"
            }
          },
          "reason": "Resource not found as expected"
        },
        {
          "compliant": "Compliant",
          "object": {
            "apiVersion": "operators.coreos.com/v1alpha1",
            "kind": "Subscription",
            "metadata": {
              "name": "project-quay",
              "namespace": "operator-policy-testns"
            }
          },
          "reason": "Resource not found as expected"
        }
      ],
      "resolvedSubscriptionLabel": "project-quay.operator-policy-testns"
    }
  }
  wanted related objects: [{Properties:<nil> Object:{Metadata:{Name:- Namespace:} Kind:CustomResourceDefinition APIVersion:apiextensions.k8s.io/v1} Compliant:Compliant Reason:No relevant CustomResourceDefinitions found}]
  wanted condition: {Type:CustomResourceDefinitionCompliant Status:True ObservedGeneration:0 LastTransitionTime:0001-01-01 00:00:00 +0000 UTC Reason:RelevantCRDNotFound Message:no CRDs were found for the operator}

  << Timeline

  [FAILED] Timed out after 60.000s.
  The function passed to Eventually failed at /home/runner/work/config-policy-controller/config-policy-controller/test/e2e/case38_install_operator_test.go:141 with:
  Expected
      <bool>: false
  to be true
  In [It] at: /home/runner/work/config-policy-controller/config-policy-controller/test/e2e/case38_install_operator_test.go:2724 @ 06/10/24 16:24:30.51


MAIN: Update SF writer in manifest of Snowpark Streamlit and Keboola Ecommerce template

Two small changes in manifest.jsonnet:
from: componentId: "keboola.wr-snowflake-blob-storage",
to: componentId: SnowflakeWriterComponentId(),

Hi @TomNett I found a small bug within templates.
Function for snowflake writer was not correctly used in 2 templates.
Please, check the changes and approve this. Thank you.


chore: move release issue creation to gh-action

related to https://github.com/bpmn-io/fake-join/pull/44

https://github.com/bpmn-io/actions/ is currently internal. Camunda should have access to it, but if it fails we can make it public if needed

Should that maybe go to master?

will rebase 👍

Let's wait for the CI to run through again an then merge


fix(cli): Control clap colors through config

What does this PR try to resolve?
Part of #9012
How should we test and review this PR?
To accomplish this, I pivoted in how we handle -C.  In #11029, I made the config lazily loaded.  Instead, we are now reloading the config for -C like we do for "cargo script" and cargo install.  If there is any regression, it will be felt by those commands as well and we can fix all together.  As this is unstable, if there is a regression, the impact is less.  This allowed us access to the full config for getting the color setting, rather than taking more limited approaches like checking only CARGO_TERM_CONFIG.
Additional information

:umbrella: The latest upstream changes (presumably #13409) made this pull request unmergeable. Please resolve the merge conflicts.

Not sure if we should ship a partial solution or hold on until --color and --config get addressed.

I don't see a reasonable way for addressing that part.  We need to be able to parse the command line to get those which requires knowing what level of styling to use.  We could say "parse the command line, take the result, and strip the message based on our own decision".  However, --help and errors short-circuits CLI parsing.  We'd have to parse, see if an error gets back, and then re-parse using the "ignore errors" setting which is a very brittle feature in clap.

@bors r=weihanglo

:hourglass: Testing commit 67474259e9893fdfa3a9f98148dc871e3c970e31 with merge d325f9b7d0c24023a7312cc1d014706789a11888...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing d325f9b7d0c24023a7312cc1d014706789a11888 to master...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing d325f9b7d0c24023a7312cc1d014706789a11888 to master...

:eyes: Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request.

Seems like we can leverage https://github.com/rust-lang/cargo/pull/13461 to test colors for this PR, right?

Okay I didn't notice you've linked the original issue in that PR.


21.7.2 node return 5 peers on 4 node IBFT2.0 network

Description
Here is log from a node (non boot) which shows 5 peers on 4 node IBFT2.0 network. The system was upgraded from 21.1 to 21.7.2 a couple of days ago. All 4 nodes are running on a single physical server with 8GB RAM:

2021-08-29 04:49:56.053+08:00 | pool-8-thread-1 | INFO  | IbftBesuControllerBuilder | Imported #93,799 / 0 tx / 0 pending / 0 (0.0%) gas / (0x9306201950f95779416cc6f8c59887aca42526fe51a8db09654e5ce3a9d36ecf)
2021-08-29 04:49:58.046+08:00 | EthScheduler-Workers-2 | INFO  | PersistBlockTask | Imported #93,800 / 0 tx / 0 om / 0 (0.0%) gas / (0x1872ffef8dc9ae6bf16895f095060e1a88fd565680de743872750dffd68dd99f) in 0.000s. Peers: 5
2021-08-29 04:50:00.047+08:00 | EthScheduler-Workers-3 | INFO  | PersistBlockTask | Imported #93,801 / 0 tx / 0 om / 0 (0.0%) gas / (0x2458a620019d9062e47f9c04f7682f008f98fc69ade9f03ef77263ffeca5a55a) in 0.000s. Peers: 5
2021-08-29 04:50:02.056+08:00 | EthScheduler-Workers-2 | INFO  | PersistBlockTask | Imported #93,802 / 0 tx / 0 om / 0 (0.0%) gas / (0x249b2c4aa49ba5ec22d0246a4dbf2e217b45cc3ebca6e178e7d8ba2d20ba4c94) in 0.000s. Peers: 5
2021-08-29 04:50:02.058+08:00 | pool-8-thread-1 | INFO  | IbftBesuControllerBuilder | Imported #93,802 / 0 tx / 0 pending / 0 (0.0%) gas / (0x249b2c4aa49ba5ec22d0246a4dbf2e217b45cc3ebca6e178e7d8ba2d20ba4c94)
2021-08-29 04:50:04.059+08:00 | pool-8-thread-1 | INFO  | IbftBesuControllerBuilder | Imported #93,803 / 0 tx / 0 pending / 0 (0.0%) gas / (0x5af02576113618c80d68cc09097daaf526f73f6889789372486abf1be5250c76)

Here is debug log for boot node showing 3 peers:
2021-08-29 04:55:08.015+08:00 | pool-8-thread-1 | DEBUG | IbftRound | Received a proposal message. round=ConsensusRoundIdentifier{Sequence=93955, Round=0}
2021-08-29 04:55:08.022+08:00 | pool-8-thread-1 | DEBUG | IbftRound | Sending prepare message. round=ConsensusRoundIdentifier{Sequence=93955, Round=0}
2021-08-29 04:55:08.039+08:00 | pool-8-thread-1 | DEBUG | IbftRound | Received a prepare message. round=ConsensusRoundIdentifier{Sequence=93955, Round=0}
2021-08-29 04:55:08.039+08:00 | pool-8-thread-1 | DEBUG | IbftRound | Sending commit message. round=ConsensusRoundIdentifier{Sequence=93955, Round=0}
2021-08-29 04:55:08.045+08:00 | EthScheduler-Workers-0 | DEBUG | TransactionLogBloomCacher | Caching logs bloom for block 0x16f03.
2021-08-29 04:55:08.045+08:00 | EthScheduler-Workers-0 | INFO  | PersistBlockTask | Imported #93,955 / 0 tx / 0 om / 0 (0.0%) gas / (0x986ca2cff51f96cd539ab44590057875cdf334d052cca5749d6108b18eef3cd5) in 0.000s. Peers: 3
2021-08-29 04:55:08.048+08:00 | pool-8-thread-1 | DEBUG | BaseBftController | Discarding a message which targets a height not above current chain height.
2021-08-29 04:55:08.049+08:00 | pool-8-thread-1 | DEBUG | BaseBftController | Discarding a message which targets a height not above current chain height.
2021-08-29 04:55:08.049+08:00 | pool-8-thread-1 | DEBUG | BaseBftController | Discarding a message which targets a height not above current chain height.
2021-08-29 04:55:08.049+08:00 | pool-8-thread-1 | DEBUG | BaseBftController | Discarding a message which targets a height not above current chain height.
2021-08-29 04:55:08.049+08:00 | pool-8-thread-1 | DEBUG | BaseBftController | New chain head detected (block number=93955), currently mining on top of 93954.

Here is a log from regular node showing 3 peers:
2021-08-29 04:56:24.042+08:00 | EthScheduler-Workers-3 | INFO  | PersistBlockTask | Imported #93,993 / 0 tx / 0 om / 0 (0.0%) gas / (0x7bf31d4c8c023f8e190d20bd54baf1d6a2c623e479c5de6c9950ad1affb68ab8) in 0.000s. Peers: 3
2021-08-29 04:56:24.042+08:00 | pool-8-thread-1 | INFO  | IbftBesuControllerBuilder | Imported #93,993 / 0 tx / 0 pending / 0 (0.0%) gas / (0x7bf31d4c8c023f8e190d20bd54baf1d6a2c623e479c5de6c9950ad1affb68ab8)
2021-08-29 04:56:26.050+08:00 | EthScheduler-Workers-1 | INFO  | PersistBlockTask | Imported #93,994 / 0 tx / 0 om / 0 (0.0%) gas / (0x3fd2ce48d647aa5bc9efc4215f1fac6bd34be4a5431a1e1b55a24694c9b045d5) in 0.000s. Peers: 3
2021-08-29 04:56:26.052+08:00 | pool-8-thread-1 | INFO  | IbftBesuControllerBuilder | Imported #93,994 / 0 tx / 0 pending / 0 (0.0%) gas / (0x3fd2ce48d647aa5bc9efc4215f1fac6bd34be4a5431a1e1b55a24694c9b045d5)
2021-08-29 04:56:28.047+08:00 | pool-8-thread-1 | INFO  | IbftBesuControllerBuilder | Produced #93,995 / 0 tx / 0 pending / 0 (0.0%) gas / (0x221f36bdb08ec1734109a44ec0c5c4f71f46f8ffbc949c3a3f9f2b35d2837a3b)
2021-08-29 04:56:30.056+08:00 | EthScheduler-Workers-3 | INFO  | PersistBlockTask | Imported #93,996 / 0 tx / 0 om / 0 (0.0%) gas / (0x16830ba3c14d2fc3d57968b86de54d51ac69a29a03e54ec8e887dd340914f657) in 0.000s. Peers: 3
2021-08-29 04:56:32.052+08:00 | EthScheduler-Workers-1 | INFO  | PersistBlockTask | Imported #93,997 / 0 tx / 0 om / 0 (0.0%) gas / (0x79c1f02505dae9e7d4af21eb1934c64cbbbf8f8a103cae6b78e3e0f80c7919b2) in 0.000s. Peers: 3

Acceptance Criteria

[Criteria 1]

Steps to Reproduce (Bug)

[Step 1]
[Step 2]
[Step ...]

Expected behavior: [What you expect to happen]
3 peers on 4 node network
Actual behavior: [What actually happens]
one node has 5 peers while other 3 have 3 peers.
Frequency: [What percentage of the time does it occur?]
Versions (Add all that apply)

Software version: [besu --version] 21.7.2
Java version: [java -version] openjdk 14
OS Name & Version: [cat /etc/*release] ubuntu 20.04
Kernel Version: [uname -a]
Virtual Machine software & version: [vmware -v]
Docker Version: [docker version]
Cloud VM, type, size: [Amazon Web Services I3-large]

Additional Information

Encountered the same problem on Besu 21.10. In a 4-nodes network, one node has 3 peers, one has 6 peers and two have 4 peers.

This log line comes from here https://github.com/hyperledger/besu/blob/5e0301a749ac49a611a26c1df84eee5c0ee198f6/ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/sync/tasks/PersistBlockTask.java#L226
          ethContext.getEthPeers().peerCount()));

Not sure how/why it would exceed the number of peers available. We can aim to add some more testing around this method.

We have observed the same behaviour. When admin_peers details are examined, the discrepancy is that we have two peers that are identical, except that one has ?disc_port=0
@RP27 Have a look at the usages of this disconnect reason code in DisconnectMessage.java
ALREADY_CONNECTED((byte) 0x05),
I would expect that in the above case we would get "already connected" but we aren't.

Just an update on this issue, I have been looking into the RlpxAgent code as there is a handleIncomingConnection method that is supposed to disconnect duplicate nodes from the network. The logic within the method seems to work as expected and further tests have shown that. I believe the data structure being used to store the nodes are a map, which should prevent identical keys. So next, I will look into why this is occurring.

Repo with minimal reproduce instructions https://github.com/macfarla/besu-duplicate-peers

and I just ruled out IBFT2. I get the same thing with ethash.

It looks from the logs like both nodes are detecting the duplicate connection and initiating disconnect. maybe there's a race condition there.

Hi @emclab, we have had a look at that problem and we are planning to fix that issue as part of some work in the p2p area in the near future.

Just checking on the status of this work - Is https://github.com/hyperledger/besu/pull/3945 the latest approach?

@pinges - Have you found the source of the issue?  I'm seeing a similar problem on some nodes on the Palm network.  I ran a node locally for a bit with trace logging on and was seeing a large number of peers kept in EthPeers.connections that were marked as "disconnected":
2022-06-09 20:30:14.661-04:00 | nioEventLoopGroup-3-9 | TRACE | EthProtocolManager | 12 EthPeers {
Peer 0x0dc8743929014993a9... PeerReputation 100, validated? true, disconnected? true,
Peer 0x0e759653a9dac12068... PeerReputation 100, validated? true, disconnected? true,
Peer 0x14601ba2d78d81d8fa... PeerReputation 100, validated? true, disconnected? true,
Peer 0x26e3ca259bce7933cc... PeerReputation 100, validated? true, disconnected? true,
Peer 0x421f71f6b88ae98083... PeerReputation 100, validated? true, disconnected? true,
Peer 0x4acab12d3e011a6ffd... PeerReputation 100, validated? true, disconnected? true,
Peer 0x4ca85a907acac09c45... PeerReputation 100, validated? true, disconnected? true,
Peer 0xbf71a1fde11fbc2104... PeerReputation 100, validated? true, disconnected? true,
Peer 0xc75062191d57de365a... PeerReputation 100, validated? true, disconnected? false,
Peer 0xcc2d5b07c0a6dc52c2... PeerReputation 100, validated? true, disconnected? true,
Peer 0xddbe110a7a2b46bbca... PeerReputation 100, validated? true, disconnected? true,
Peer 0x80af873bfc8f6ed78d... PeerReputation 100, validated? true, disconnected? false}

During normal operations, I saw this kind of behavior occassionally, but after opening / closing my laptop and moving around I ended up with that list full of stale peers ^.
One guess is that PeerConnection.equals() is not behaving deterministically, so peers are not always being removed from EthPeers.connections on disconnect.  I did notice that EnodeURLImpl.getIp() is doing a live calculation which seems like it could mess up that equality check, but I'm not sure that would explain the discrepancy for peers whose hostnames are just plain ip addresses.

@mbaxter This should get fixed with the changes that I'm doing. The main map holding the peers in EthPeers will use the peerId instead of the connection as the key. There will be another map containing potential new peers that haven't exchanged the status messages yet, and another one that will hold some peers that were already usable, but are replaced because of another connection from that peer, but they are both only holding their entries for a few seconds. These two other maps are only used when there are connection attempts from both peers at the same time, so that should not really happen in a "normal" network (just happens all the time with our acceptance tests).

@pinges - have you found the root cause of the mismatch between EthPeers.connections and RlpxAgent.connectionsById ?  RlpxAgent is the source of truth wrt connection management, so this should just be an issue related to how connection / disconnection events are communicated and handled between these 2 objects.

Next steps

clean up logging on #4001

Hey @emclab we are still working on fixing the root cause here, but we think some other improvements that have been made elsewhere in peering may have reduced the incidence of this "duplicate peer" issue, to such a low level that you may not be affected by it. Are you able to try with the most recent Besu? We have just released 22.7.0-RC2

Reported by a user on 22.7.0 on mainnet https://discord.com/channels/905194001349627914/1006351975467728916

After a few days running on goerli besu 22.7.0
[TRACE] 2022-08-15 00:32:32.646 [nioEventLoopGroup-3-9] EthProtocolManager - 20 EthPeers {
PeerId 0x14601ba2d78d81d8fac9ee735cc3a4c1e49939f987adc21a6e0a391ec688a22601cc7030e5a2e9ad64ebc5e1aeb8b9dec1ccedefe041ced9614c1af6d38ee0b6, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v21.1.4/linux-x86_64/openjdk-java-11, connection 512764178, enode enode://14601ba2d78d81d8fac9ee735cc3a4c1e49939f987adc21a6e0a391ec688a22601cc7030e5a2e9ad64ebc5e1aeb8b9dec1ccedefe041ced9614c1af6d38ee0b6@<IP_ADDRESS>:30303,
PeerId 0x24de87f10d52409c348accadbfb7c7982a5bde6122e969e89bdf2323a49cd17c951f2d4cbfb7c9a3dc22d099978338ea13c47903ff8be6fa846132f1fcd0e5b9, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.1-dev-7319dbb4/linux-x86_64/openjdk-java-11, connection<PHONE_NUMBER>, enode enode://24de87f10d52409c348accadbfb7c7982a5bde6122e969e89bdf2323a49cd17c951f2d4cbfb7c9a3dc22d099978338ea13c47903ff8be6fa846132f1fcd0e5b9@<IP_ADDRESS>:30303,
PeerId 0x2740325245eb5d34b1f6fe4758e6636969425fe1e593d7c8b46a1eeaf227b9bc91d82172bfb73ed8516fe96bfd9b4d33db61258c106d4c79e84ee28685ac29af, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.1-dev-e4b621b3/linux-x86_64/openjdk-java-11, connection 734223677, enode enode://2740325245eb5d34b1f6fe4758e6636969425fe1e593d7c8b46a1eeaf227b9bc91d82172bfb73ed8516fe96bfd9b4d33db61258c106d4c79e84ee28685ac29af@<IP_ADDRESS>:30303,
PeerId 0x284b09eb902f249e85c12a330ff88b89be3f6eacc9877e1c356152e9962910e72f746d5bfe9ae239ed93e6478deda79c8e6ffef208ce9f4f5744acabf7a14743, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.4.0-RC1/linux-x86_64/openjdk-java-11, connection 382894318, enode enode://284b09eb902f249e85c12a330ff88b89be3f6eacc9877e1c356152e9962910e72f746d5bfe9ae239ed93e6478deda79c8e6ffef208ce9f4f5744acabf7a14743@<IP_ADDRESS>:30303,
PeerId 0x2eaf83ffc16446f795a54124887388d014399deaa8110adeb0c89b1adf9783c48686caefd61f4a8455b648a84ecb9db952ea811bf14a5c68401b0d83ace07155, reputation PeerReputation 100, validated? true, disconnected? true, client: bor/v0.2.16-stable/linux-amd64/go1.18.3, connection 188072587, enode enode://2eaf83ffc16446f795a54124887388d014399deaa8110adeb0c89b1adf9783c48686caefd61f4a8455b648a84ecb9db952ea811bf14a5c68401b0d83ace07155@<IP_ADDRESS>:30000,
PeerId 0x3d4d5b69f6de9cf5c2073b56ca6e7998f910e41e5f6a8577cf17397054d1969d1c860a5f904bf2ecf260b97bcb9249c94edf4ab82c8a8fbcf375baa12f8171b2, reputation PeerReputation 100, validated? true, disconnected? false, client: Geth/v1.1.11-cf1245fe-20220629/linux-amd64/go1.16.5, connection 25860011, enode enode://3d4d5b69f6de9cf5c2073b56ca6e7998f910e41e5f6a8577cf17397054d1969d1c860a5f904bf2ecf260b97bcb9249c94edf4ab82c8a8fbcf375baa12f8171b2@<IP_ADDRESS>:0,
PeerId 0x4f3d02b456c3fd9f8c7a53f295db9fdcffbf7757ec681ddc44bfc8f38222fef81cbd7dfd4135cb11c80f7f930d047a7a9305e44d4bb62bc4cd2272fe74e83bff, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.4.0-RC2/linux-x86_64/openjdk-java-11, connection 842890299, enode enode://4f3d02b456c3fd9f8c7a53f295db9fdcffbf7757ec681ddc44bfc8f38222fef81cbd7dfd4135cb11c80f7f930d047a7a9305e44d4bb62bc4cd2272fe74e83bff@<IP_ADDRESS>:30303,
PeerId 0x523c8c89e25d6159dac2c6a41ac5fa98f7db2df44cdae1a4ae6fb739dd147ea382166e20617ead4f1c2577acb272682d9b8fd61bce8782e46554d397e0c93c2b, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.4.0/linux-x86_64/openjdk-java-11, connection 272722608, enode enode://523c8c89e25d6159dac2c6a41ac5fa98f7db2df44cdae1a4ae6fb739dd147ea382166e20617ead4f1c2577acb272682d9b8fd61bce8782e46554d397e0c93c2b@<IP_ADDRESS>:30303,
PeerId 0x5c694d2bf2b894b596fc46630066eef2d68fbc056fdde544ed0b5c4a1ecc0a81c900645b81c436c8f5c24d0e0c67a31a6aa0084e3f419b674f103f1f5eb4c3f6, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v21.10.0/linux-x86_64/openjdk-java-11, connection<PHONE_NUMBER>, enode enode://5c694d2bf2b894b596fc46630066eef2d68fbc056fdde544ed0b5c4a1ecc0a81c900645b81c436c8f5c24d0e0c67a31a6aa0084e3f419b674f103f1f5eb4c3f6@<IP_ADDRESS>:30304,
PeerId 0x5dddbca60a3a5abc1fa66006c4e9cd44e4d60b59de9c2e38d4abab1817dbe6558abe84cd0265eed4fe1687b84b61a8df2afca01f6f02012e15e1a9fea57c6f09, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.0-dev-326113d2/linux-x86_64/openjdk-java-11, connection<PHONE_NUMBER>, enode enode://5dddbca60a3a5abc1fa66006c4e9cd44e4d60b59de9c2e38d4abab1817dbe6558abe84cd0265eed4fe1687b84b61a8df2afca01f6f02012e15e1a9fea57c6f09@<IP_ADDRESS>:30303,
PeerId 0x5f694f6837c3983d5c29ea58fce50c3c7296ea67ddc53a52f4e00bba01473d598d450e32c76941dfe344d3d3d28af2745b9a165b26784d7696ce74835fd6e3ed, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.4.3-dev-e1d0a3d6/linux-x86_64/openjdk-java-11, connection 160178864, enode enode://5f694f6837c3983d5c29ea58fce50c3c7296ea67ddc53a52f4e00bba01473d598d450e32c76941dfe344d3d3d28af2745b9a165b26784d7696ce74835fd6e3ed@<IP_ADDRESS>:30303,
PeerId 0x5f694f6837c3983d5c29ea58fce50c3c7296ea67ddc53a52f4e00bba01473d598d450e32c76941dfe344d3d3d28af2745b9a165b26784d7696ce74835fd6e3ed, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.4.3-dev-e1d0a3d6/linux-x86_64/openjdk-java-11, connection 973513062, enode enode://5f694f6837c3983d5c29ea58fce50c3c7296ea67ddc53a52f4e00bba01473d598d450e32c76941dfe344d3d3d28af2745b9a165b26784d7696ce74835fd6e3ed@<IP_ADDRESS>:30303,
PeerId 0x6feb25e94406ad665a1b20e3cde8c2d89246558bc5614d9b0b18e7f660dee5040741c032674d0589ddd7562a2f4d635799bb8a4f2efa7c94c1735a396c6d4d94, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.0/linux-x86_64/openjdk-java-11, connection<PHONE_NUMBER>, enode enode://6feb25e94406ad665a1b20e3cde8c2d89246558bc5614d9b0b18e7f660dee5040741c032674d0589ddd7562a2f4d635799bb8a4f2efa7c94c1735a396c6d4d94@<IP_ADDRESS>:54916,
PeerId 0x7c89c5d47311babc331454d93a4fbaca62d957535bfc0fc8adb7e07c23fd12c3cb70ad0b5cc2b5fb77353fbc1f65a1a5c3ab8b9ee6466b11860dbd40f9bb8396, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v21.1.4/linux-x86_64/openjdk-java-11, connection 256537157, enode enode://7c89c5d47311babc331454d93a4fbaca62d957535bfc0fc8adb7e07c23fd12c3cb70ad0b5cc2b5fb77353fbc1f65a1a5c3ab8b9ee6466b11860dbd40f9bb8396@<IP_ADDRESS>:30305,
PeerId 0x8deeec45c0264ac711826bbefac134958a4e5d9fee9419bd8ee27426f12d0ca7a52ad5b232234c1e1d851ae9b5211d900539ea4f10f21f7a8e2e7c807d8912ea, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.1-dev-e4b621b3/linux-x86_64/openjdk-java-11, connection 597060785, enode enode://8deeec45c0264ac711826bbefac134958a4e5d9fee9419bd8ee27426f12d0ca7a52ad5b232234c1e1d851ae9b5211d900539ea4f10f21f7a8e2e7c807d8912ea@<IP_ADDRESS>:30303,
PeerId 0x93fb884afb2f272c93e09ca9269374896caa2ad71c8d3f8cabef9d7f79e628c09ff4e09bf4ecf6d8be09c6cb06dfb12571177180ced02e2e01ab32183c796740, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.1-dev-7319dbb4/linux-x86_64/openjdk-java-11, connection 368696996, enode enode://93fb884afb2f272c93e09ca9269374896caa2ad71c8d3f8cabef9d7f79e628c09ff4e09bf4ecf6d8be09c6cb06dfb12571177180ced02e2e01ab32183c796740@<IP_ADDRESS>:30303,
PeerId 0x9db8f073e78764ca838d2f42a2f2e04c9f6449b58f4e52264cd4a2bc76d2685316f3f0f326415c0c2d3c15ef6365b68d962b92aa2e2f6b2ca5678776cf2d37cd, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.4.0/linux-x86_64/corretto-java-11, connection<PHONE_NUMBER>, enode enode://9db8f073e78764ca838d2f42a2f2e04c9f6449b58f4e52264cd4a2bc76d2685316f3f0f326415c0c2d3c15ef6365b68d962b92aa2e2f6b2ca5678776cf2d37cd@<IP_ADDRESS>:30303,
PeerId 0x9f18e529db1d9423921e6e05b399860b9e2a0645fd846515754c3b940d0242b45331056899809e94957726592d4f0f88a3eff0754e63ac87b724db99ce7472a2, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v1.3.1/linux-x86_64/openjdk-java-11, connection<PHONE_NUMBER>, enode enode://9f18e529db1d9423921e6e05b399860b9e2a0645fd846515754c3b940d0242b45331056899809e94957726592d4f0f88a3eff0754e63ac87b724db99ce7472a2@<IP_ADDRESS>:30303,
PeerId 0xc627dcd14e929aeca2fe0c3a8d784dfe834692c3d990fb9ea497a7dd55a18b100ca3bab2839b5c0db8bb617fa7afcb05e54c712cb325d79c8fcc1e2b1784b7d0, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v22.7.RC1-dev-d3aaca8f/linux-x86_64/corretto-java-17, connection 797543779, enode enode://c627dcd14e929aeca2fe0c3a8d784dfe834692c3d990fb9ea497a7dd55a18b100ca3bab2839b5c0db8bb617fa7afcb05e54c712cb325d79c8fcc1e2b1784b7d0@<IP_ADDRESS>:30303,
PeerId 0xe472b75f3ca9fa83e84300ec1bd433a236e28770c424061d997b88f170b4747b087fe15546cf189d6e90690a31ebd1fc23cc3c9def4ed476efbc7448a96d23aa, reputation PeerReputation 100, validated? true, disconnected? true, client: besu/v21.10.0/linux-x86_64/openjdk-java-11, connection 844363741, enode enode://e472b75f3ca9fa83e84300ec1bd433a236e28770c424061d997b88f170b4747b087fe15546cf189d6e90690a31ebd1fc23cc3c9def4ed476efbc7448a96d23aa@<IP_ADDRESS>:30306}

#4304 should help with this issue

This issue should be resolved by #4304


Avoid global styles to break components

Bug Report
Describe the bug
In docz-theme-default some global styles are applied which are reaching components and breaking the styles on some scenarios:
*, *:before, *:after {
    box-sizing: border-box;
  }

All my components will receive box-sizing: border-box;.
These global rules could be easily avoided by using the box-sizing properties on the necessary elements directly.
A clear and concise description of what the bug is.
docz-theme-default global styles are leaking to consumer components.
To Reproduce
I guess this is self explanatory.
Expected behavior
Styles from docz-theme-default should not impact on consumer components.
I can provide a PR for this if maintainers think this is a valid issue.

Also experiencing this on the dark theme and the global font color leaking into the live preview:

While this is one example, for non-trivial implementations / themes I think it could be a common problem in the wild.
Storybook mitigates this by wrapping each component in an iframe. We're working on a Storybook to DocZ bridge right now, and one of the things we're exploring is wrapping our components in either an iframe or potentially using shadow dom (yay component heights being respected!) to encapsulate each of the story components.

Using all: initial, possibly with help from a postcss plugin could be a practical way to achieve an element level CSS reset.
https://developer.mozilla.org/en-US/docs/Web/CSS/initial
https://github.com/maximkoretskiy/postcss-autoreset

Fixed on the new release v0.12.10 ✅

I removed normalize.css from theme default and the classes and styles applied to Playground are fixed too!


Scroll issue when navigating between pages (follow-up)

Describe the bug
This is a follow-up to #2760, which was closed #2761. I have updated my replication case to vnext.196 which has the fix from #2761. The issue is partially fixed but now there's an issue when using the back button.
Reproduction

Go to https://gavinr.github.io/sveltekit-scroll-issue/
Scroll down 75% on the page, click link ~400
Next page loads at the top (As expected! This was fixed by #2761)
Scroll to the BOTTOM of this page.
Click "Back" button in the browser

Expected: page loads where you just were (about 75% down with item 400 in view)
Actual: page loads scrolled near the TOP of the page

Logs
No response
System Info
System:
  I have tested this on multiple browsers (Firefox, Chromium) on multple OSs (Windows 10, Linux) - it happens on all of them.
Binaries:
  Node: 14.18.1 - /usr/bin/node
  npm: 8.1.1 - /usr/bin/npm
npmPackages:
  @sveltejs/adapter-static: ^1.0.0-next.21 => 1.0.0-next.21
  @sveltejs/kit: next => 1.0.0-next.196
  svelte: ^3.42.6 => 3.44.1

Severity
blocking an upgrade
Additional Information
Thank you for your time supporting this project!

As extra info, I've tested this on macOS 11.6 in Chromium/Firefox/Safari with the reproduction site you provided and the scroll position was perfectly preserved.

I tested it too on Windows 10 using Firefox 95.0b6 (64-bit) and it perfectly preserves scroll position as well.

Another data point: I can reproduce the problem (page scrolls to top) on Edge 95 and Chrome 95, both on macOS 11.6. The scroll position is preserved on Safari 15 on the same macOS 11.6.

Thanks all, sorry I did not post specific OS and browser details - I should have. The issue is happening for me on:
OS: Linux 5.4 Linux Mint 20.2 (Uma)
Chromium: 95.0.4638.69

video:
https://user-images.githubusercontent.com/209355/141660166-8c8d7ecc-97f8-438c-bd68-80028a25c2ba.mp4

The issue also happens for me on:
Windows 10 Pro, build 19043.1348
Firefox 94.0.1

Video (Sorry no cursor in video but i think it's fairly obvious):
https://user-images.githubusercontent.com/209355/141660388-0468a53f-4317-497e-b38b-cd68eea45aaa.mp4
I will try to test with Windows 10 and  Firefox 95.0b6 (64-bit) (@CarlosIvanchuk says the issue should be resolved in that case)

I can reproduce this problem on my devices too, but only if I scroll down after navigating to page 400. If I click on the back button without scrolling down first, I get back to the same scroll position with the link to page 400 on the screen.

@bttger yes, that's step 4 of the reproduction instructions.

Oh sorry, my fault.

Thanks for the thorough reproduction! I'll try to look into this today or tomorrow if no one takes it.

I took a look at this today, it isn't as easy as I thought. Turns out if you navigate back to the home page (based on repro steps), the pageYOffset before navigation is different after navigation. We had expected pageYOffset to be the same so we know there was no custom happening in onMount(). You can also reproduce this if you add a home link at the bottom of the slug page (not necessarily going back).
The interesting part is now that the difference mentioned can be derived from the body's implicit vertical margin, that happens because it's children are "inline" and has vertical mergin that extends over the parent:

(Opening devtools and highlighting body reveals this. Notice the implicit margin above the yellow area).
And the difference can be calculated by top implicit margin - bottom implicit marginpx. What this also means is that if the top and bottom are the same, the bug doesn't happen, e.g. remove the "Welcome to SvelteKit" text in the repro.
With these said, I haven't found a solution yet and it feels like a simple navigation is getting too complex. IMO it might be better if we do it the proper way, but I'm not sure what yet.

I have same problem ~
here is what I do:
async function scTop() {
    await tick()
    document.scrollingElement.scrollTop = 0
    window.scrollTo(0, 0)
}
<svelte:window on:sveltekit:navigation-end={scTop}/>

@bluwy I understand that the no_scroll_happened check in renderer.js originated from #2664, but I think this is really complicating things and is what is causing the scrolling issues.
I may be off here, but if custom scroll is happening inside onMount, it should happened AFTER the Sveltekit navigation scroll, not INSTEAD of it.
Alternatively, we could let the author explicitly disable Sveltekit's navigation scroll by providing a function or option that could be called inside onMount.
All this is to say that checking the different pageYOffsets, as is the case right now, produces inconsistent results and seems very brittle. Since this check only exists to satisfy a fairly niche case (explicitly overriding scroll position in onMount), I don't think it has its place and I feel the alternatives I outlined above (or some other) would be better.

I agree, the pageYOffset checks we do now are very hacky and brittle :sweat_smile: I really want to move away from it but I can't find a way for it to satisfy all use-cases ootb.

I may be off here, but if custom scroll is happening inside onMount, it should happened AFTER the Sveltekit navigation scroll, not INSTEAD of it.

Yes ideally we want this to be the case, but currently there's no way to do kit's navigation scroll before onMount(). Unless, the user runs their custom scrolling after a tick, which isn't something we'd want to enforce since it had always work in normal SPAs, and a kit specific condition for this would be off.

Alternatively, we could let the author explicitly disable Sveltekit's navigation scroll by providing a function or option that could be called inside onMount.

I'm not sure if this would work nicely with actions that do custom scrolling, but so far we have sveltekit:noscroll (though that works a bit differently). An interesting idea though.
Ultimately, I too am very tempted to intentionally regress #2477, but so far the only way I think that might really fix this is if we inject a custom onMount for all the routes somehow (sounds like a bad idea). Or I wonder if we shouldn't mess with scrolls in the first place (I'm not sure why we did).

currently there's no way to do kit's navigation scroll before onMount().

I thought that the await 0 was specifically to let onMount() run. Can't we just put it after kit's navigation scroll like it was done in the fix for #2477? Or am I wrong here?

I thought that the await 0 was specifically to let onMount() run. Can't we just put it after kit's navigation scroll like it was done in the fix for #2477? Or am I wrong here?

If we put kit's navigation scroll before await 0 the new route component wouldn't be rendered yet, so when kit's navigation scroll try to check for the hash element to auto-scroll to, it wouldn't be able to find it and causes #2664.
The current flow of the things is something like this:

Before new route component
Render new route component (no onMount() yet)
Mount new route component (called onMount())

await 0 now skips from step 1 to 3, ideally we want to run our navigation scroll checks in step 2.

If we put kit's navigation scroll before await 0 the new route component wouldn't be rendered yet, so when kit's navigation scroll try to check for the hash element to auto-scroll to, it wouldn't be able to find it and causes #2664.

Of course! Sorry I didn't catch that.
I think you just solved it!
You could try something like this:
if (scroll) {
    scrollTo(scroll.x, scroll.y);
} else {
    scrollTo(0, 0);
}

await 0;

const deep_linked = hash && document.getElementById(hash.slice(1));

if (deep_linked) {
    deep_linked.scrollIntoView();
}

@f-elix I just tried that and turns out it won't solve this issue either. When we navigate back to the long list of numbers page, we're scrolling to a large scroll.y value when doing  scrollTo(scroll.x, scroll.y);, and because the old page doesn't a large scroll height, the scroll would be clamped when navigate to the new page after await 0. Meaning we would still need to run the scrollTo(scroll.x, scroll.y); after await 0, but that suffers from the incorrect no_scroll_happened logic.
Note: The scroll.x and scroll.y are values of which the user last scrolled to before navigating to a new page, so when navigate back, scroll would be defined and contains the values.

@bluwy Hey thanks for trying!
I tried to find a solution myself for a few hours now and I am coming to the conclusion that we should keep sveltekit's scroll restoration to this (or something along those lines):
await 0;

const deep_linked = hash && document.getElementById(hash.slice(1));

if (scroll) {
	scrollTo(scroll.x, scroll.y);
} else if (deep_linked) {
	deep_linked.scrollIntoView();
} else {
	scrollTo(0, 0);
}

This was the way scroll restoration was handled before version 193 and it is the in my opinion most efficient. It was changed to allow custom scrolling in unMount and actions, but I don't think there is a reliable way for Sveltekit to tell if that occured or not.
With the code above, the solution for users is pretty simple: they simply have to wait for the next tick to execute their custom scrolling.
This (does not work):
const autofocus = (node) => {
	node.focus();
};

Would turn into this:
import { tick } from 'svelte';

const autofocus = async (node) => {
        await tick();
	node.focus();
};

I would very much like that there was a way to not impose this on the user, but at the same time it's not that much work.
I also looked at a few other client-side routing solutions and couldn't find on that tried to automate this. Vue router handles it by providing a special  scrollBehavior function to tell the router where to scroll to, or use Vue.nextTick to run your custom scrolling code after the router. React-router just gave up on handling it (https://v5.reactrouter.com/web/guides/scroll-restoration).
I understand this would be a breaking change to revert back to, but I really think it's worth it. After so many iterations on this, I doubt that anyone can find a reliable way to tell if scrolling occured in onMount.

Thanks for the help @f-elix! Good to know that other frameworks had struggled with this as well. we can pull up our sleeves and find our own balance point. Regarding the tick() solution, that would be the last resort, or we would come up with a similar solution as Vue router or Nuxt.
But otherwise, I think I have an idea of using a custom preprocessor though to inject the scroll handling in the ideal mounting phase. I'm still testing it, but I'll also bring this up with the other maintainers and see what they think of the solutions.

Oh interesting! Can't wait to see what you come up with.

I made #2986, which hopefully will end all scrolling issues. It might be the last option we have for scrolling to work OOTB, otherwise we would be resorting to export const autoscroll = false. Feel free to try it out or give any opinions!

#2986 was closed. There are some ideas for fixes listed in the final comments there: https://github.com/sveltejs/kit/pull/2986#issuecomment-1002302203


How to exclude armv7 when build ios app

I have a local pod which does not support armv7 in my ios project. How to exclude armv7 when build ios app with flutter build ios

Hi @teabyii
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @teabyii
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


[Bug Report] Dialog not opening if nested in a component (v-if/ v-show)

Element UI version
1.3.6
OS/Browsers version
macOS
Vue version
2.3.4
Reproduction Link
https://jsfiddle.net/dbg2e9z2/
Steps to reproduce
Replace <popup v-if="showDialog" :show-dialog.sync="showDialog"></popup> with <popup v-show="showDialog" :show-dialog.sync="showDialog"></popup>
Replace <popup v-if="showDialog" :show-dialog.sync="showDialog"></popup> with <popup :show-dialog.sync="showDialog"></popup>
What is Expected?
The pop up should open in the two cases
What is actually happening?
For the first one, the pop up opens but the content is not displayed
For the second case, the pop up is not displayed at all

https://jsfiddle.net/dbg2e9z2/3/

:visible.sync="show"

This show never changes to true in those two cases. So you need to update it.

@Leopoldthecoder  where is the visible-change in documents?


[VOTE] RateLimits naming

@JoshKeegan @ON-MX @dubmartin @komBAS @lcichanowicz @rdahan156 @Muchomasquewebs @gsogol
Your vote was quite helpful regarding the LoggedUser vs AuthenticatedUser. As I am struggling with 2 other names please let me know what you think.
Questions :

TokenRateLimits vs. CredentialsRateLimits
TokenRateLimit vs. EndpointRateLimits
Any other comment/idea.

More details below:
I would like to change TokenRateLimits (it represents all the rate limits available for a token)  into CredentialsRateLimits.
I would like to change TokenRateLimit (it represents the rate limits applied to a specific url) into EndpointRateLimit or UrlRateLimit.
Thanks again for your help.

CredentialsRateLimits
EndpointRateLimits

CredentialsRateLimits & EndpointRateLimit

CredentialsRateLimits
EndpointRateLimits


Support ip group names in dynamic firewall rules

Resolves #2328
What is being addressed
Some services require firewall rules while deploying, i.e. open a new rule for the resource processor. The Pipeline method of creating rules dynamicly didn't allow for this so templates like Certs, Airlock-Notifier created rules directly via terraform which caused issues when running in parallel with another firewall change.
How is this addressed

Create an ip group for the resource processor subnet
Include a source_ip_groups_in_core property for the rules defined by another template to be able to specify ip groups present in the core resource group
Update the firewall template to be able to use these referenced ip groups
Update Certs and Airlock Notifier templates to use this new capability
Re-enable Certs and Nexus to run in the shared services E2Es

/test-force-approve
gave up with the certs bundle in the ci environments. will pick it up separately.


Add a feature to handle setid for UCPath tables

Ideally I would like to avoid making a new macro specifically for setid'd UCPath tables.
(A general feature approach)
A feature could be added such that a where condition or conditions could be declared in the source.yml for each table and then surfaced in the generated model.
      - name: ps_jobcode_tbl
        description: jobcode validation table
        meta:
          effective_dated: true
          partition_columns: ["jobcode", "setid"]
          final_where_condition: ["setid in ('UCSHR')"]

The declared final_where_condition would surface in the final select statement of the staging model. For example,
-- Dummy Line

/*  The partition columns are: ['jobcode', 'setid']
*/

with
    source as (
        select * from {{ source(  'ucp', 'ps_jobcode_tbl' ) }}
        where
            _fivetran_deleted != true
            and dml_ind != 'D'

    ),

    valid_to as (
        -- Group the records so that each group belonging to one effdt gets the same valid_to date
        select
            jobcode,
            setid,
            effdt,
            coalesce((lag(to_date(effdt), 1) over (
                partition by
                    jobcode,
                    setid
                order by effdt desc
            ) - 1), '2099-12-31') as valid_to

        from source
        group by
            1,
            2,
            3
    ),

    final as (
        select
            source._fivetran_deleted,
            source._fivetran_id,
            source._fivetran_synced,
            source.avail_telework,
            source.barg_unit,
            source.can_noc_cd,
            source.comp_frequency,
            source.company,
            source.cr_bt_dtm,
            source.cr_bt_nbr,
            source.currency_cd,
            source.descr,
            source.descrshort,
            source.directly_tipped,
            source.dml_ind,
            source.eeo1code,
            source.eeo4code,
            source.eeo5code,
            source.eeo6code,
            source.eeo_job_group,
            source.eff_status,
            source.effdt,
            source.eg_academic_rank,
            source.eg_group,
            source.encumb_sal_amt,
            source.encumb_sal_optn,
            source.encumber_indc,
            source.flsa_status,
            source.function_cd,
            source.grade,
            source.ipedsscode,
            source.job_family,
            source.job_function,
            source.job_sub_func,
            source.jobcode,
            source.key_jobcode,
            source.last_update_date,
            source.lastupddttm,
            source.lastupdoprid,
            source.manager_level,
            source.med_chkup_req,
            source.ods_vrsn_nbr,
            source.posn_mgmt_indc,
            source.reg_region,
            source.reg_temp,
            source.retro_percent,
            source.retro_rate,
            source.sal_admin_plan,
            source.sal_range_currency,
            source.sal_range_freq,
            source.sal_range_max_rate,
            source.sal_range_mid_rate,
            source.sal_range_min_rate,
            source.setid,
            source.setid_salary,
            source.std_hours,
            source.std_hrs_frequency,
            source.step,
            source.survey_job_code,
            source.survey_salary,
            source.trn_program,
            source.union_cd,
            source.upd_bt_dtm,
            source.upd_bt_nbr,
            source.us_occ_cd,
            source.us_soc_cd,
            source.workers_comp_cd,

            -- New Objects
            to_date(source.effdt) as valid_from,
            valid_to.valid_to as valid_to,
            case
                when valid_from > {{ var("current_date_pst") }} then 'future'
                when valid_to.valid_to < {{ var("current_date_pst") }} then 'past'
                when valid_to.valid_to >= {{ var("current_date_pst") }} then 'current'
            end as current_record_desc,
            case
                when current_record_desc = 'current' then true
                when current_record_desc in ('future', 'past') then false
            end as is_current_record

        from source

        left outer join valid_to
            on source.jobcode = valid_to.jobcode
                and source.setid = valid_to.setid
                and source.effdt = valid_to.effdt
    )

select * from final
where -- <-- THIS WHERE CONDITION WOULD BE VARIABLE AND ONLY POPULATE WHEN THE final_where_condition KEY IS POPULATED
    setid in ('UCHSR')

(A UCPath setid specific approach)
If we choose to make a setid specific UCPath macro, then the meta information declared can be more specific (naming wise).
      - name: ps_jobcode_tbl
        description: jobcode validation table
        meta:
          effective_dated: true
          partition_columns: ["jobcode", "setid"]
          ucsc_setid: ["UCSHR"]

We could also have more freedom in where the condition is set. For example we can apply the condition at the source CTE,
-- Dummy Line

/*  The partition columns are: ['jobcode', 'setid']
*/

with
    source as (
        select * from {{ source(  'ucp', 'ps_jobcode_tbl' ) }}
        where
            _fivetran_deleted != true
            and dml_ind != 'D'
            and setid in ('UCSHR') -- <-- THIS LINE WOULD NEED TO BE HARCODED IN THE MACRO. THE IN LIST VALUES WOULD BE THE ONLY VARIABLE PORTION.
    ),

    valid_to as (
        -- Group the records so that each group belonging to one effdt gets the same valid_to date
        select
            jobcode,
            setid,
            effdt,
            coalesce((lag(to_date(effdt), 1) over (
                partition by
                    jobcode,
                    setid
                order by effdt desc
            ) - 1), '2099-12-31') as valid_to

        from source
        group by
            1,
            2,
            3
    ),

    final as (
        select
            source._fivetran_deleted,
            source._fivetran_id,
            source._fivetran_synced,
            source.avail_telework,
            source.barg_unit,
            source.can_noc_cd,
            source.comp_frequency,
            source.company,
            source.cr_bt_dtm,
            source.cr_bt_nbr,
            source.currency_cd,
            source.descr,
            source.descrshort,
            source.directly_tipped,
            source.dml_ind,
            source.eeo1code,
            source.eeo4code,
            source.eeo5code,
            source.eeo6code,
            source.eeo_job_group,
            source.eff_status,
            source.effdt,
            source.eg_academic_rank,
            source.eg_group,
            source.encumb_sal_amt,
            source.encumb_sal_optn,
            source.encumber_indc,
            source.flsa_status,
            source.function_cd,
            source.grade,
            source.ipedsscode,
            source.job_family,
            source.job_function,
            source.job_sub_func,
            source.jobcode,
            source.key_jobcode,
            source.last_update_date,
            source.lastupddttm,
            source.lastupdoprid,
            source.manager_level,
            source.med_chkup_req,
            source.ods_vrsn_nbr,
            source.posn_mgmt_indc,
            source.reg_region,
            source.reg_temp,
            source.retro_percent,
            source.retro_rate,
            source.sal_admin_plan,
            source.sal_range_currency,
            source.sal_range_freq,
            source.sal_range_max_rate,
            source.sal_range_mid_rate,
            source.sal_range_min_rate,
            source.setid,
            source.setid_salary,
            source.std_hours,
            source.std_hrs_frequency,
            source.step,
            source.survey_job_code,
            source.survey_salary,
            source.trn_program,
            source.union_cd,
            source.upd_bt_dtm,
            source.upd_bt_nbr,
            source.us_occ_cd,
            source.us_soc_cd,
            source.workers_comp_cd,

            -- New Objects
            to_date(source.effdt) as valid_from,
            valid_to.valid_to as valid_to,
            case
                when valid_from > {{ var("current_date_pst") }} then 'future'
                when valid_to.valid_to < {{ var("current_date_pst") }} then 'past'
                when valid_to.valid_to >= {{ var("current_date_pst") }} then 'current'
            end as current_record_desc,
            case
                when current_record_desc = 'current' then true
                when current_record_desc in ('future', 'past') then false
            end as is_current_record

        from source

        left outer join valid_to
            on source.jobcode = valid_to.jobcode
                and source.setid = valid_to.setid
                and source.effdt = valid_to.effdt
    )

select * from final

The reason final_where_condition is restricted to the final select statement is so devs have more freedom in what kind of conditions they can specify. Since it is going to be added to the final select statement then can apply conditions on fields that were added during the staging process.
I prefer the final_where_condition method because this can be used in other models and not just for UCPath setid tables.
For example for our effseq'd models we could final_where_condition = ["setid in ('UCHSR ')", "is_max_effseq_of_effdt = true"].
.
.
.
select * from final
    where
        setid in ('UCHSR')
        and is_max_effseq_of_effdt = true

I like the options Insuh. I do like handling setid  at the source CTE (feels appropriate there), but I also like the final_where_condition tag being able to handle other conditions.
Is the reason the ucsc_setid  meta tag wouldn't work in the general feature approach due to the fact that setid doesn't exist in other projects (besides Student)? If it doesn't exist couldn't we just not populate it and then the macro wouldn't take it into consideration?
Let's bring this up at the next AE meeting. I'm interested in what the others have to say.


Improvements to the SDK versioning page for .NET 9

Add 9.0.100 to the various tables
Also break the top table into an out of support table and an active table to simplify it some

Internal previews

📄 File
🔗 Preview link

docs/core/porting/versioning-sdk-msbuild-vs.md
.NET SDK, MSBuild, and Visual Studio versioning

I made some changes to resolve the lint errors (hide whitespace to see important changes only).


Adding test to existing file: Test with id /path/to/test/file.R&[object Object] could not be found.

Repro steps:

Run tests from the sidebar by clicking the play button that runs a file.
Add a test to that file.
Again click the play button that runs all tests in file (not individual tests).

Expected result: both tests run
Actual result: First test runs successfully. Second test doesn't run (from what I can tell). File is reported as failing with Test with id /path/to/test/file.R&[object Object] could not be found.
Video of issue:
https://github.com/user-attachments/assets/8227d538-98b3-4eb4-8f9b-f3eadc0a937e
Test file in question with surrounding repo can be found here:
https://github.com/katrinabrock/minimal-r-package/blob/main/tests/testthat/test-passes.R

I did some more digging. This happens when there are warnings or errors outside of a test_that(...) block.
in that case, no test or context are passed into add_result method and the result looks something like this:
List of 6
 $ message    : chr "The `code` argument to `test_that()` must be a braced expression to get accurate file-line information for failures."
 $ srcref     : 'srcref' int [1:8] 3 1 3 39 1 39 3 3
  ..- attr(*, "srcfile")=Classes 'srcfilecopy', 'srcfile' <environment: 0x55b7041aab38>
 $ trace      :Classes ‘rlang_trace’, ‘rlib_trace’, ‘tbl’ and 'data.frame':     1 obs. of  5 variables:
  ..$ call     :List of 1
  .. ..$ : language test_that("Test #1", expect_true(TRUE))
  .. .. ..- attr(*, "srcref")= 'srcref' int [1:8] 3 1 3 39 1 39 3 3
  .. .. .. ..- attr(*, "srcfile")=Classes 'srcfilecopy', 'srcfile' <environment: 0x55b7041aab38>
  ..$ parent   : int 0
  ..$ visible  : logi TRUE
  ..$ namespace: chr "testthat"
  ..$ scope    : chr "::"
  ..- attr(*, "version")= int 2
 $ start_frame: int 27
 $ end_frame  : num 28
 $ test       : chr "(code run outside of `test_that()`)"
 - attr(*, "class")= chr [1:3] "expectation_warning" "expectation" "condition"

The the VScodeReporter emits and undefined test like this:

Dear Brock, thanks a lot for the detailed report! I will check it out as soon as possible, just a bit busy these days.


kola: More calico fixes

~I'll need to update the github action to mention in the created PR that these templates should be manually compared with the original versions.~
There seemed to be a race between using one manifest file to create CRDs and afterwards applying another manifest file that was using those CRDs. Sometimes the CRDs were not established, so the resources of that type could not be used. Use kubectl wait to make sure that those CRDs are ready.
While at it, sync our modified custom-resources.yaml manifest with the upstream and add a note about it to the github action. The note looks like in this PR: https://github.com/krnowak/mantle/pull/2.
Test run: http://jenkins.infra.kinvolk.io:8080/job/container/job/test/1988/console (note the customresourcedefinition.apiextensions.k8s.io/installations.operator.tigera.io condition met line in the output, after CRDs were created, but before the object of that type was created).

Another test run: http://jenkins.infra.kinvolk.io:8080/job/container/job/test/1989/console

Tested with my toolchain update build: http://jenkins.infra.kinvolk.io:8080/job/container/job/sdk/204/cldsv/

Thanks for the review. I just remembered that this needs an entry in the changelog. Added one and merged. If you have some suggestions about the entry, I'll fix eventually.


Stats variations: Amenities

Fix https://github.com/hlxsites/caesars/issues/74
🔗 Test URLs:

Before: https://main--caesars--hlxsites.hlx.page/caesars-palace/
After: https://issue-74-amenities--caesars--hlxsites.hlx.page/caesars-palace/drafts/tmathern/stats-amenities

📝 Description:

Refactor stats component to work with multi-line stats
Make sure short stats display nicely, even if there are not exactly 5/3/2 columns
Add icons for amenities

Authoring experience:

(Same as existing authoring experience for stats, but now can go multi-line)

At the smallest viewport (<= 480px) tiles should be in a single column.


implement mwc-dialog

PR is out for anybody subbed to this issue

@e111077 Can't wait to start using this.  When can we expect an NPM release?  Thanks!

I want to see if I can bundle in a few textfield/area changes into the release first


Saner sending strategy

Currently, a burst of probes are sent out when the trace is activated. Something less obnoxious should be used, since the burst can cause subsequent packets to be dropped by some IDS's.

a 100ms delay has been added between probes. this doesn't fully solve the problem though.