Large blocks that take over 3-4s to import trigger a backward sync session causing a 6-8 block gaps each time

Description
When a larger than usual block is imported (with > 90% gas utilization), the block import time will be unusually long (unsure why, as this doesn't happen with all > 90% gas blocks), when this happens Besu will trigger a new backward sync session causing besu to be out of sync for a short period of time (6-8) blocks resulting in missed attestations.
Expected behavior:
Since blocks are roughly every ~12s I'm not sure why Besu needs a new backward sync session after being delayed for what seems like 3-5s tops.
Few examples (logs are otherwise clean of warnings/errors):
2023-04-02 23:40:39.093-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,965,905 / 149 tx / base fee 17.67 gwei / 29,985,480 (100.0%) gas / (0x7bdfa719422f03d9026ef30518394700f3585767d9e7c59b1ae0951c9f9d064f) in 1.575s. Peers: 82
2023-04-02 23:41:48.313-04:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-02 23:41:48.605-04:00 | nioEventLoopGroup-3-1 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 83
2023-04-02 23:41:49.450-04:00 | nioEventLoopGroup-3-1 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 16.67% completed, imported 1 blocks of at least 6 (current head 16965906, target head 16965911). Peers: 82
2023-04-02 23:41:52.252-04:00 | ForkJoinPool.commonPool-worker-1 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 6 blocks. Peers: 82
2023-04-02 23:41:52.253-04:00 | ForkJoinPool.commonPool-worker-1 | INFO  | BackwardsSyncAlgorithm | Current backward sync session is done
2023-04-02 23:42:00.144-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,965,912 / 48 tx / base fee 17.74 gwei / 5,404,592 (18.0%) gas / (0x720e1b57db756f25e63c495d91c7cdbc83f7d59b7d1fec0aa4e3608a6c333dde) in 0.281s. Peers: 82

2023-04-02 23:56:39.574-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,965,984 / 135 tx / base fee 16.50 gwei / 26,929,761 (89.8%) gas / (0x66a194614e43d2c7a4850bfb98579685bf5cc8442a4088fea422e243222edeca) in 3.381s. Peers: 83
2023-04-02 23:57:47.802-04:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-02 23:57:48.115-04:00 | nioEventLoopGroup-3-1 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 83
2023-04-02 23:57:48.979-04:00 | nioEventLoopGroup-3-1 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 16.67% completed, imported 1 blocks of at least 6 (current head 16965985, target head 16965990). Peers: 83
2023-04-02 23:57:53.225-04:00 | ForkJoinPool.commonPool-worker-4 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 6 blocks. Peers: 84
2023-04-02 23:57:53.225-04:00 | ForkJoinPool.commonPool-worker-4 | INFO  | BackwardsSyncAlgorithm | Current backward sync session is done
2023-04-02 23:58:01.087-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,965,991 / 114 tx / base fee 18.48 gwei / 15,729,908 (52.4%) gas / (0x7cac53cf47feecb668df7915bb415f6d6c8a4df2514a3798ae982cd381c656f7) in 0.704s. Peers: 83

2023-04-03 02:51:41.278-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,966,847 / 172 tx / base fee 16.06 gwei / 29,997,876 (100.0%) gas / (0x24d17b0e3e1c937247fef2bfd7bf553aacce477b3d36e82dcdcdc96888189263) in 4.017s. Peers: 86
2023-04-03 02:52:49.550-04:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-03 02:52:50.393-04:00 | nioEventLoopGroup-3-10 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 86
2023-04-03 02:52:51.595-04:00 | nioEventLoopGroup-3-10 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 16.67% completed, imported 1 blocks of at least 6 (current head 16966848, target head 16966853). Peers: 86
2023-04-03 02:52:56.672-04:00 | ForkJoinPool.commonPool-worker-6 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 6 blocks. Peers: 86
2023-04-03 02:52:56.672-04:00 | ForkJoinPool.commonPool-worker-6 | INFO  | BackwardsSyncAlgorithm | Current backward sync session is done
2023-04-03 02:53:00.767-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,966,854 / 153 tx / base fee 18.93 gwei / 10,487,277 (35.0%) gas / (0xf01053e3fbe8933990d5c51728b045108939130d443845082a85a11ce6a4e730) in 0.516s. Peers: 86

2023-04-05 02:39:53.515-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,980,870 / 395 tx / base fee 27.00 gwei / 29,987,418 (100.0%) gas / (0x4d7652e0f19f7d554af7e3ae2083713b1706c0ee5fe0b40a384238e98eac3be8) in 4.095s. Peers: 72
2023-04-05 02:41:00.183-04:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-05 02:41:08.083-04:00 | nioEventLoopGroup-3-3 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 74
2023-04-05 02:41:11.036-04:00 | nioEventLoopGroup-3-3 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 16.67% completed, imported 1 blocks of at least 6 (current head 16980871, target head 16980876). Peers: 73
2023-04-05 02:41:15.637-04:00 | ForkJoinPool.commonPool-worker-8 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 7 blocks. Peers: 73
2023-04-05 02:41:15.637-04:00 | ForkJoinPool.commonPool-worker-8 | INFO  | BackwardsSyncAlgorithm | Current backward sync session is done
2023-04-05 02:41:26.162-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,980,878 / 123 tx / base fee 30.30 gwei / 14,577,888 (48.6%) gas / (0x3a2727c14294d95532168c27e88d2e7ee90a75e1330fbab6eae2ae344c8010ba) in 0.859s. Peers: 73

Important to note that block import times are usually < 1-2s even when blocks are >90% utlization, so I'm not sure why some blocks are so expensive, for example:
2023-04-05 11:55:48.778-04:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x1b3817526a08c5575e7e3eaf2cacb2f916bfab7c543ac6f9bb080ef12fff8e64, finalized: 0xc1c9c3c3fe95c3ae6ffc0308b8d0b8670548b16e51c88c85fd07ef8eb186a8c9, safeBlockHash: 0x13500199ec22220a30a15f2ce98c42b0a4e1691f44d0982880d7cfac81d73046
2023-04-05 11:56:02.580-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,601 / 190 tx / base fee 33.52 gwei / 16,656,164 (55.5%) gas / (0x72cfbf942728109f84fc0dbd04bfaa13563a2ef82b1f6538bfb79d677bb68d24) in 0.809s. Peers: 70
2023-04-05 11:56:10.764-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,602 / 0 tx / base fee 33.98 gwei / 0 (0.0%) gas / (0xcd3031e0782b1f20084113691f3272d5875ee6d808dc0d59f8140ef2130387e5) in 0.045s. Peers: 71
2023-04-05 11:56:26.781-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,603 / 299 tx / base fee 29.73 gwei / 29,980,191 (99.9%) gas / (0x69f8584830846cd16cef332b9cbdba361a3d1bf9b5f20af901362f469fabb99b) in 1.771s. Peers: 71
2023-04-05 11:56:37.428-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,604 / 162 tx / base fee 33.44 gwei / 17,478,256 (58.3%) gas / (0x842119b984e113c2a17b9f605dc3011f5e666aa5ab916a65c01214c378742e07) in 1.023s. Peers: 71
2023-04-05 11:56:49.184-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,605 / 140 tx / base fee 34.13 gwei / 11,426,213 (38.1%) gas / (0x01d567931b8638e987f40a0793fbf5becd322eb0145eea13cabdcff403ac1162) in 0.687s. Peers: 70
2023-04-05 11:56:49.450-04:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x01d567931b8638e987f40a0793fbf5becd322eb0145eea13cabdcff403ac1162, finalized: 0xc1c9c3c3fe95c3ae6ffc0308b8d0b8670548b16e51c88c85fd07ef8eb186a8c9, safeBlockHash: 0x13500199ec22220a30a15f2ce98c42b0a4e1691f44d0982880d7cfac81d73046
2023-04-05 11:57:03.950-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,606 / 222 tx / base fee 33.12 gwei / 25,296,048 (84.3%) gas / (0xa921596a8c96c1820413b04ba3b2e4bd38ff673e2d8184530106c7a20cc4561c) in 1.286s. Peers: 71
2023-04-05 11:57:26.114-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,607 / 337 tx / base fee 35.96 gwei / 29,343,421 (97.8%) gas / (0x24f7db52bdea5c9f3e4ba8b94ad1d0d9bb12444775007705deb693c1b00a1a3e) in 1.288s. Peers: 71
2023-04-05 11:57:38.292-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,608 / 162 tx / base fee 40.26 gwei / 20,595,909 (68.7%) gas / (0x84a12cfa1af56904aabd4c8f83092a677c473f95fbe170271c6f42d8097438c1) in 1.103s. Peers: 71
2023-04-05 11:57:48.772-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,609 / 126 tx / base fee 42.13 gwei / 9,419,915 (31.4%) gas / (0x1afe84046124cb90d769cfca4eb544fd4c75ea7566f81390bc59dcb01250fe35) in 0.584s. Peers: 71
2023-04-05 11:58:01.753-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,610 / 116 tx / base fee 40.17 gwei / 10,804,207 (36.0%) gas / (0x90605b19cb84a18e935480d18e61a040ab9481522e0262b19f74059ffa99e641) in 0.617s. Peers: 71
2023-04-05 11:58:02.044-04:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x90605b19cb84a18e935480d18e61a040ab9481522e0262b19f74059ffa99e641, finalized: 0x13500199ec22220a30a15f2ce98c42b0a4e1691f44d0982880d7cfac81d73046, safeBlockHash: 0x389d95e7ca8b9002e97cf5ce62520ecc0d22aa3752c8f5867c3e27857976b85b
2023-04-05 11:58:12.822-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,611 / 149 tx / base fee 38.77 gwei / 13,148,715 (43.8%) gas / (0x436c11609cbedf93d460235ea92eb1d05faa2e61aad3eee76b1d1a3dc62b6da8) in 0.759s. Peers: 71
2023-04-05 11:58:26.389-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,612 / 159 tx / base fee 38.17 gwei / 19,432,648 (64.8%) gas / (0xd4dd9f9fa1de73cf167d19f1bd824ade5699c3ea414707e29f9ac29ff72459b0) in 0.876s. Peers: 71
2023-04-05 11:58:36.590-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,613 / 148 tx / base fee 39.58 gwei / 12,038,555 (40.1%) gas / (0x0f7c4f741ca802210d720546618de3fb342f41988113db460f8cc94514f8c44e) in 0.583s. Peers: 71
2023-04-05 11:58:49.654-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,614 / 147 tx / base fee 38.60 gwei / 10,960,702 (36.5%) gas / (0x8296a5afb864af22e8bcfecb7e227b9d7339492c38b6006c2ed1614fc367a55a) in 0.603s. Peers: 71
2023-04-05 11:59:01.759-04:00 | vert.x-worker-thread-0 | INFO  | EngineNewPayload | Imported #16,983,615 / 156 tx / base fee 37.30 gwei / 13,561,518 (45.2%) gas / (0x52a3e62dd169f175d5e173af60f07131862e8df8edc5b87eae82c01d10e2d710) in 0.806s. Peers: 71
2023-04-05 11:59:02.103-04:00 | vert.x-worker-thread-0 | INFO  | EngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x52a3e62dd169f175d5e173af60f07131862e8df8edc5b87eae82c01d10e2d710, finalized: 0x13500199ec22220a30a15f2ce98c42b0a4e1691f44d0982880d7cfac81d73046, safeBlockHash: 0x389d95e7ca8b9002e97cf5ce62520ecc0d22aa3752c8f5867c3e27857976b85b

Actual behavior:
Besu triggers a backward sync session resulting in being out-of-sync for 6-8 blocks.
Frequency:
3-4 times roughly every 24h.
Versions (Add all that apply)

Software version: [besu --version]
Java version: [java -version]
Kernel Version: [uname -a]
Consensus Client & Version if using Proof of Stake: [e.g. Teku, Lighthouse, Prysm, Nimbus, Lodestar]

❯ besu --version
besu/v23.1.2/linux-x86_64/openjdk-java-17
2023-04-05 12:25:51.198-04:00 | main | INFO  | Besu | Using jemalloc
❯ java --version
openjdk 17.0.5 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+7-void-r1)
OpenJDK 64-Bit Server VM (build 17.0.5+7-void-r1, mixed mode, sharing)
❯ uname -a
Linux istake 6.1.14_1 #1 SMP PREEMPT_DYNAMIC Mon Feb 27 15:21:49 UTC 2023 x86_64 GNU/Linux
❯ nimbus_beacon_node --version
Nimbus beacon node v23.3.2-6c0d75-stateofus
Copyright (c) 2019-2023 Status Research & Development GmbH

eth2 specification v1.3.0-rc.5

Nim Compiler Version 1.6.12 [Linux: amd64]

Additional Information (Add any of the following or anything else that may be relevant)
16GB RAM using JAVA_OPTS=-Xmx5g and Xplugin-rocksdb-high-spec-enabled = true
####################################################################################################
#                                                                                #
# Besu 23.1.2                                                                                #
#                                                                                #
# Configuration:                                                                                #
# Network: Mainnet                                                                                #
# Network Id: 1                                                                                #
# Data storage: Bonsai                                                                             #
# Sync mode: Checkpoint                                                                            #
# RPC HTTP APIs: ADMIN,ETH,NET,DEBUG,TXPOOL,WEB3                                                   #
# RPC HTTP port: 8545                                                                              #
# Engine APIs: ENGINE,ETH                                                                          #
# Engine port: 8551                                                                                #
# High spec configuration enabled                                                                  #
#                                                                                #
# Host:                                                                                #
# Java: openjdk-java-17                                                                            #
# Maximum heap size: 5.00 GB                                                                       #
# OS: linux-x86_64                                                                                #
# glibc: 2.36                                                                                #
# Total memory: 15.63 GB                                                                           #
# CPU cores: 4                                                                                #
#                                                                                #
####################################################################################################

@fab-10 maybe we are too aggressive in triggering the new BWS format.

also drop that max peer count ;)

Thank you for the detailed report! Also drop that max peer count ;)

Ty!
It's currently set to max-peers = 100, what's the recommended value?

On a post-Merge network, you really only need a handful of peers and having that many will eat up CPU to maintain the connections. I'd recommend somewhere between ~10-25, especially for an in-sync node.

That could be very helpful for my node indeed, ty!

can you provide the nimbus logs as well? I am trying to determine if nimbus is directing besu to resync or if this is something with our configuration of backwards sync.

can you provide the nimbus logs as well? I am trying to determine if nimbus is directing besu to resync or if this is something with our configuration of backwards sync.

Unfortuntely I don't have the logs mainnet anymore as I moved back to Nethermind due to this issue (I run my services inside a tmux session so the logs aren't written to disk).
However, this is easily replicable on my stronger machine (64GB RAM) running goleri validators, here even blocks over 1s seem to trigger the backward sync, below are a few examples of the Besu log with it's corresponding nimbus logs (nothing suspecious AFAIK), lmk if you need any other data and I'll be happy to provide it.
My goerli machine:
####################################################################################################
#                                                                                #
# Besu 23.1.2                                                                                #
#                                                                                #
# Configuration:                                                                                #
# Network: Goerli                                                                                #
# Network Id: 5                                                                                #
# Data storage: Bonsai                                                                             #
# Sync mode: Snap                                                                                #
# RPC HTTP APIs: ADMIN,ETH,NET,DEBUG,TXPOOL,WEB3                                                   #
# RPC HTTP port: 8545                                                                              #
# Engine APIs: ENGINE,ETH                                                                          #
# Engine port: 8551                                                                                #
# High spec configuration enabled                                                                  #
#                                                                                #
# Host:                                                                                #
# Java: openjdk-java-17                                                                            #
# Maximum heap size: 8.00 GB                                                                       #
# OS: linux-x86_64                                                                                #
# glibc: 2.36                                                                                #
# Total memory: 62.78 GB                                                                           #
# CPU cores: 16                                                                                #
#                                                                                #
####################################################################################################

(1): Besu, block 8,806,471 (other logs arount these timestamps look totally normal)

2023-04-10 06:02:37.935-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,806,471 / 129 tx / 16 ws / base fee 181.73 gwei / 23,372,823 (77.9%) gas / (0x57323bb8ce92bdaf76a0e01ed67cd649d37a3df2513f0cc717a1aaec576e4277) in 1.072s. Peers: 25
2023-04-10 06:04:01.233-07:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-10 06:04:01.564-07:00 | nioEventLoopGroup-3-7 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 25
2023-04-10 06:04:03.039-07:00 | nioEventLoopGroup-3-7 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 20.00% completed, imported 1 blocks of at least 5 (current head 8806472, target head 8806476). Peers: 25
2023-04-10 06:04:06.643-07:00 | ForkJoinPool.commonPool-worker-20 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 5 blocks. Peers: 25
2023-04-10 06:04:06.643-07:00 | ForkJoinPool.commonPool-worker-20 | INFO  | BackwardSyncAlgorithm | Current backward sync session is done
2023-04-10 06:04:13.187-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,806,477 / 70 tx / 16 ws / base fee 247.67 gwei / 6,261,496 (20.9%) gas / (0x27591f26468e4a9c9998e9e04245de0fe896cf90fb43df0daf6882b3c86bd2b8) in 0.268s. Peers: 25

(1): Nimbus slot 5385313 (same block as Besu):

INF 2023-04-10 06:02:12.001-07:00 Slot start                                 topics="beacnde" slot=5385311 epoch=168290 sync=synced peers=160 head=f6caa4d3:5385310 finalized=168288:f050bc47 delay=781us908ns
INF 2023-04-10 06:02:14.194-07:00 State replayed                             topics="chaindag" blocks=0 slots=1 current=a25f47ab:5385280@5385312 ancestor=96a67889:5385311 target=96a67889:5385311@5385312 ancestorStateRoot=f85c844b targetStateRoot=136742bb found=true assignDur=33ms390us661ns replayDur=400ms355us121ns
INF 2023-04-10 06:02:20.097-07:00 Slot end                                   topics="beacnde" slot=5385311 nextActionWait=5m3s902ms144us508ns nextAttestationSlot=5385337 nextProposalSlot=-1 syncCommitteeDuties=none head=96a67889:5385311
NOT 2023-04-10 06:02:23.911-07:00 Attestation failed to match head           topics="chaindag" epoch=168289 validator=<redacted>
INF 2023-04-10 06:02:24.002-07:00 Slot start                                 topics="beacnde" slot=5385312 epoch=168291 sync=synced peers=160 head=96a67889:5385311 finalized=168288:f050bc47 delay=2ms155us789ns
INF 2023-04-10 06:02:33.871-07:00 State replayed                             topics="chaindag" blocks=0 slots=32 current=96a67889:5385311@5385312 ancestor=96a67889:5385311@5385312 target=96a67889:5385311@5385344 ancestorStateRoot=136742bb targetStateRoot=76229e0d found=true assignDur=2us863ns replayDur=1s596ms398us898ns
INF 2023-04-10 06:02:34.382-07:00 Slot end                                   topics="beacnde" slot=5385312 nextActionWait=4m49s617ms153us890ns nextAttestationSlot=5385337 nextProposalSlot=-1 syncCommitteeDuties=none head=96a67889:5385311
INF 2023-04-10 06:02:34.393-07:00 Missed multiple heartbeats                 topics="libp2p gossipsub" heartbeat=GossipSub delay=1s232ms439us436ns hinterval=700ms
INF 2023-04-10 06:02:36.000-07:00 Slot start                                 topics="beacnde" slot=5385313 epoch=168291 sync=synced peers=160 head=96a67889:5385311 finalized=168288:f050bc47 delay=128us10ns
WRN 2023-04-10 06:02:37.809-07:00 Failed to exchange transition configuration topics="elmon" url=http://<IP_ADDRESS>:8551 err=Timeout
INF 2023-04-10 06:02:44.114-07:00 Slot end                                   topics="beacnde" slot=5385313 nextActionWait=4m39s885ms465us357ns nextAttestationSlot=5385337 nextProposalSlot=-1 syncCommitteeDuties=none head=30266594:5385313
INF 2023-04-10 06:02:48.000-07:00 Slot start                                 topics="beacnde" slot=5385314 epoch=168291 sync=synced peers=160 head=30266594:5385313 finalized=168289:86cbefc2 delay=310us471ns
INF 2023-04-10 06:02:56.101-07:00 Slot end                                   topics="beacnde" slot=5385314 nextActionWait=4m27s898ms464us549ns nextAttestationSlot=5385337 nextProposalSlot=-1 syncCommitteeDuties=none head=4bd58568:5385314
INF 2023-04-10 06:03:00.001-07:00 Slot start                                 topics="beacnde" slot=5385315 epoch=168291 sync=synced/opt peers=160 head=4bd58568:5385314 finalized=168289:86cbefc2 delay=1ms12us760ns
INF 2023-04-10 06:03:00.028-07:00 Execution client not in sync; skipping validator duties for now topics="beacval" slot=5385315 headSlot=5385314
INF 2023-04-10 06:03:00.091-07:00 Slot end                                   topics="beacnde" slot=5385315 nextActionWait=4m23s908ms42us557ns nextAttestationSlot=5385337 nextProposalSlot=-1 syncCommitteeDuties=none head=4bd58568:5385314

(2): Besu block 8,802,737

2023-04-09 14:02:14.341-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineForkchoiceUpdated | VALID for fork-choice-update: head: 0xa68c9fccae334588bce4db5229b8a04b5bc5d4c4ede1c52966e9bd83aa9e202b, finalized: 0xbf6fab88a694ec8ea73cb75cf8433c15605a913287b3bfd4a076cc8ffc1a0457, safeBlockHash: 0x626e9c11eafb9107dfe842af338263a3f21ba9982fb4f64c7b7824246f90f913
2023-04-09 14:02:27.672-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,802,737 / 285 tx / 16 ws / base fee 5.04 gwei / 29,973,156 (99.9%) gas / (0x7a56aed200372621f63c9b38d29702a898bef1c5c3c5da21dbfb32b4e7418bb7) in 1.385s. Peers: 25
2023-04-09 14:03:36.688-07:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-09 14:03:36.988-07:00 | nioEventLoopGroup-3-1 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 200 headers. Peers: 25
2023-04-09 14:03:40.369-07:00 | nioEventLoopGroup-3-2 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 20.00% completed, imported 1 blocks of at least 5 (current head 8802738, target head 8802742). Peers: 25
2023-04-09 14:03:42.694-07:00 | nioEventLoopGroup-3-2 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 5 blocks. Peers: 25
2023-04-09 14:03:42.696-07:00 | ForkJoinPool.commonPool-worker-24 | INFO  | BackwardSyncAlgorithm | Current backward sync session is done
2023-04-09 14:03:51.060-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,802,743 / 211 tx / 16 ws / base fee 5.11 gwei / 29,858,880 (99.5%) gas / (0x6e2f01a824d7db8cd946c419e6618af438df6b5fcb39c4702f7d9bcb9e5875b0) in 1.249s. Peers: 25
2023-04-09 14:04:26.437-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,802,744 / 188 tx / 16 ws / base fee 5.74 gwei / 27,804,062 (92.7%) gas / (0x4647c8b12117e9d92cc1fb87ccf5410450ca9387942c8e198ce7b50b77c739c9) in 1.204s. Peers: 25

(2): Nimbus slot 5380512

INF 2023-04-09 14:08:36.000-07:00 Slot start                                 topics="beacnde" slot=5380543 epoch=168141 sync=synced peers=160 head=640ba7a9:5380542 finalized=168139:8e390e2a delay=140us448ns
INF 2023-04-09 14:08:44.075-07:00 Slot end                                   topics="beacnde" slot=5380543 nextActionWait=39s924ms968us963ns nextAttestationSlot=5380547 nextProposalSlot=-1 syncCommitteeDuties=none head=640ba7a9:5380542
INF 2023-04-09 14:08:48.001-07:00 Slot start                                 topics="beacnde" slot=5380544 epoch=168142 sync=synced peers=160 head=640ba7a9:5380542 finalized=168139:8e390e2a delay=1ms26us161ns
INF 2023-04-09 14:08:48.516-07:00 State replayed                             topics="chaindag" blocks=0 slots=2 current=294895ca:5380512@5380544 ancestor=640ba7a9:5380542 target=640ba7a9:5380542@5380544 ancestorStateRoot=8ed5c7bd targetStateRoot=053e6b01 found=true assignDur=33ms555us218ns replayDur=437ms709us426ns
INF 2023-04-09 14:08:57.713-07:00 State replayed                             topics="chaindag" blocks=0 slots=32 current=640ba7a9:5380542@5380544 ancestor=640ba7a9:5380542@5380544 target=640ba7a9:5380542@5380576 ancestorStateRoot=053e6b01 targetStateRoot=90daed42 found=true assignDur=2us893ns replayDur=1s640ms752us963ns
INF 2023-04-09 14:08:58.228-07:00 Slot end                                   topics="beacnde" slot=5380544 nextActionWait=25s771ms79us297ns nextAttestationSlot=5380547 nextProposalSlot=-1 syncCommitteeDuties=none head=640ba7a9:5380542
INF 2023-04-09 14:08:58.240-07:00 Missed multiple heartbeats                 topics="libp2p gossipsub" heartbeat=GossipSub delay=1s277ms511us46ns hinterval=700ms
INF 2023-04-09 14:09:00.007-07:00 Slot start                                 topics="beacnde" slot=5380545 epoch=168142 sync=synced peers=160 head=640ba7a9:5380542 finalized=168139:8e390e2a delay=7ms408us720ns
NOT 2023-04-09 14:09:03.482-07:00 Attestation failed to match head           topics="chaindag" epoch=168140 validator=<redacted>
INF 2023-04-09 14:09:03.524-07:00 State replayed                             topics="chaindag" blocks=0 slots=2 current=640ba7a9:5380542@5380543 ancestor=640ba7a9:5380542@5380543 target=640ba7a9:5380542@5380545 ancestorStateRoot=ac7356de targetStateRoot=2e016ed6 found=true assignDur=3us154ns replayDur=949ms8us648ns
INF 2023-04-09 14:09:08.260-07:00 Slot end                                   topics="beacnde" slot=5380545 nextActionWait=15s739ms310us276ns nextAttestationSlot=5380547 nextProposalSlot=-1 syncCommitteeDuties=none head=8054a3dd:5380545
INF 2023-04-09 14:09:12.001-07:00 Slot start                                 topics="beacnde" slot=5380546 epoch=168142 sync=synced peers=160 head=8054a3dd:5380545 finalized=168140:ad2fed16 delay=991us809ns
INF 2023-04-09 14:09:20.106-07:00 Slot end                                   topics="beacnde" slot=5380546 nextActionWait=3s893ms243us122ns nextAttestationSlot=5380547 nextProposalSlot=-1 syncCommitteeDuties=none head=200a7e6b:5380546

(3): Besu block 8,798,617

2023-04-08 20:19:37.818-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,798,616 / 133 tx / 16 ws / base fee 100.20 gwei / 8,857,883 (29.5%) gas / (0x8b63a3a8c508a0e556e419e168cae94664180b2e9a3bc482d5918aa5f2a28012) in 0.417s. Peers: 25
2023-04-08 20:19:51.794-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,798,617 / 161 tx / 16 ws / base fee 95.07 gwei / 29,996,593 (100.0%) gas / (0x777fc03d53f438a318716557122ad7b927986f268f5eb3e6ef59ad29d037f07d) in 1.454s. Peers: 25
2023-04-08 20:19:53.364-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineForkchoiceUpdated | VALID for fork-choice-update: head: 0x777fc03d53f438a318716557122ad7b927986f268f5eb3e6ef59ad29d037f07d, finalized: 0xd202d7ce53811b02ee2f6323a10611fb1c63feb656db46692945a7b8ad0311c6, safeBlockHash: 0x5938a234202a46bc467ac6c7eb878d1270ea33785caf94382ea3352a7f65e108
2023-04-08 20:21:01.603-07:00 | vert.x-worker-thread-0 | INFO  | BackwardSyncContext | Starting a new backward sync session
2023-04-08 20:21:02.238-07:00 | nioEventLoopGroup-3-8 | INFO  | BackwardSyncStep | Backward sync phase 1 of 2 completed, downloaded a total of 192 headers. Peers: 25
2023-04-08 20:21:03.432-07:00 | nioEventLoopGroup-3-8 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2, 20.00% completed, imported 1 blocks of at least 5 (current head 8798618, target head 8798622). Peers: 25
2023-04-08 20:21:06.826-07:00 | nioEventLoopGroup-3-8 | INFO  | BackwardSyncContext | Backward sync phase 2 of 2 completed, imported a total of 5 blocks. Peers: 25
2023-04-08 20:21:06.829-07:00 | ForkJoinPool.commonPool-worker-5 | INFO  | BackwardSyncAlgorithm | Current backward sync session is done
2023-04-08 20:21:38.597-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,798,623 / 247 tx / 16 ws / base fee 103.18 gwei / 29,998,288 (100.0%) gas / (0xa1ec4480243faaa12f8f30858aa81d6121fb37747020e3d343e5b5c73dd9769f) in 1.410s. Peers: 25
2023-04-08 20:21:50.176-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,798,624 / 108 tx / 16 ws / base fee 116.08 gwei / 16,688,362 (55.6%) gas / (0x47dab1c059e324caaae6bf17b355d12a72632e94b17fb89206e2e52771026795) in 0.628s. Peers: 25
2023-04-08 20:22:02.319-07:00 | vert.x-worker-thread-0 | INFO  | AbstractEngineNewPayload | Imported #8,798,625 / 78 tx / 16 ws / base fee 117.71 gwei / 11,499,324 (38.3%) gas / (0xfcc3bd7f4d549bc62190aee3f75ad835f671215ea7ad2cec90bcc551ed248036) in 0.482s. Peers: 25

(3): Nimbus slot 5375199

INF 2023-04-08 20:19:36.000-07:00 Slot start                                 topics="beacnde" slot=5375198 epoch=167974 sync=synced peers=159 head=f947b406:5375197 finalized=167972:5ee2a2bd delay=283us502ns
INF 2023-04-08 20:19:44.106-07:00 Slot end                                   topics="beacnde" slot=5375198 nextActionWait=27s893ms671us768ns nextAttestationSlot=5375201 nextProposalSlot=-1 syncCommitteeDuties=none head=5da2ff83:5375198
INF 2023-04-08 20:19:48.000-07:00 Slot start                                 topics="beacnde" slot=5375199 epoch=167974 sync=synced peers=158 head=5da2ff83:5375198 finalized=167972:5ee2a2bd delay=894us991ns
WRN 2023-04-08 20:19:51.405-07:00 Failed to exchange transition configuration topics="elmon" url=http://<IP_ADDRESS>:8551 err=Timeout
INF 2023-04-08 20:19:52.655-07:00 State replayed                             topics="chaindag" blocks=0 slots=1 current=0bb13188:5375168@5375200 ancestor=7397aa62:5375199 target=7397aa62:5375199@5375200 ancestorStateRoot=2aa3ecf9 targetStateRoot=8bc483fd found=true assignDur=33ms528us672ns replayDur=407ms898us623ns
INF 2023-04-08 20:19:56.102-07:00 Slot end                                   topics="beacnde" slot=5375199 nextActionWait=15s897ms66us236ns nextAttestationSlot=5375201 nextProposalSlot=-1 syncCommitteeDuties=none head=7397aa62:5375199
INF 2023-04-08 20:20:00.000-07:00 Slot start                                 topics="beacnde" slot=5375200 epoch=167975 sync=synced peers=159 head=7397aa62:5375199 finalized=167972:5ee2a2bd delay=267us296ns
INF 2023-04-08 20:20:08.322-07:00 Slot end                                   topics="beacnde" slot=5375200 nextActionWait=3s677ms92us22ns nextAttestationSlot=5375201 nextProposalSlot=-1 syncCommitteeDuties=none head=abf39360:5375200
INF 2023-04-08 20:20:12.000-07:00 Slot start                                 topics="beacnde" slot=5375201 epoch=167975 sync=synced/opt peers=158 head=abf39360:5375200 finalized=167973:e2ce79bc delay=188us16ns
INF 2023-04-08 20:20:12.027-07:00 Execution client not in sync; skipping validator duties for now topics="beacval" slot=5375201 headSlot=5375200
INF 2023-04-08 20:20:12.091-07:00 Slot end                                   topics="beacnde" slot=5375201 nextActionWait=2m59s908ms810us448ns nextAttestationSlot=5375216 nextProposalSlot=-1 syncCommitteeDuties=none head=abf39360:5375200
INF 2023-04-08 20:20:24.001-07:00 Slot start                                 topics="beacnde" slot=5375202 epoch=167975 sync=synced/opt peers=159 head=abf39360:5375200 finalized=167973:e2ce79bc delay=1ms23us910ns
INF 2023-04-08 20:20:24.028-07:00 Execution client not in sync; skipping validator duties for now topics="beacval" slot=5375202 headSlot=5375200
INF 2023-04-08 20:20:24.091-07:00 Slot end                                   topics="beacnde" slot=5375202 nextActionWait=2m47s908ms946us775ns nextAttestationSlot=5375216 nextProposalSlot=-1 syncCommitteeDuties=none head=abf39360:5375200

Thanks for this report - we have noticed this on our own nodes on sepolia and will work to debug (or blame on nimbus ;0)

@non-fungible-nelson, siince I upgraded my goerli node to v23.4.0 (just about when it came out) I didn't have a single "Starting a new backward sync session" message aside from the initial sync when starting the service - was anything changed in the new version that should've affected this issue?
As of now, this issue seems to be solved.

this is a problem with the way sync is handled between besu and certain CLs - I am going to keep this open so we can track against our new post-Merge sync strategy.

Another data point for you @non-fungible-nelson, after seeing the new version works great on my Goerli node I migrated back my mainnet node from nethermind to besu and I'm experiencing the same great performance, hope I'm not jinxing it but it's been over 2 days so far and not a single "new backward sync" message :-)
From my end, this issue is definitely solved, attestation eff is also hovering between 97-99% which is great!


[AA-1354] Claim set registration updates

In case you're not able to reach the TeamCity builds, 4 integration tests are failing here. See https://github.com/Ed-Fi-Alliance-OSS/Ed-Fi-ODS-AdminApp/blob/main/docs/developer.md#build-script to repro these locally.

BulkRegisterOdsInstanceCommandTests.BulkShouldNotRegisterOneOdsInstancePreviouslyRegistered
BulkRegisterOdsInstanceCommandTests.ShouldRegisterOneNewOdsInstanceInBulk
RegisterOdsInstanceCommandTests.ShouldRegisterDistrictSpecificOdsInstance
RegisterOdsInstanceCommandTests.ShouldRegisterYearSpecificOdsInstance

OdsInstanceFirstTimeSetupService.CreateAndSaveApiKeyAndSecret (somewhere near line 59) throws null reference exceptions in at least three of these, though the TeamCity captured logs are a little garbled by Shouldly running in Release mode. My guess would be something caused CreateAdminAppInAdminDatabase to return null, but I have not tried to catch it under the debugger.
What I see in the actual code change looks like a merge resolution mixup. See how it's leaving the original newInstance variable in place though it seems that was meant to be replaced in favor of the new variable odsInstance variable, but then still returns newInstance.Id at the end, which is probably Guid.Empty now.

I'm also surprised by the remaining change. @CSR2017 would it be valid for the OdsInstanceRegistration.Name to be only the numeric suffix? If so, how has anything worked to date?

@pmcvtm can you evaluate if this is still relevant, and if not, close it? Thanks.

This one looks safe to close. Besides moving to aysnc, we have introduced a separate property (OdsInstanceRegistrations.DatabaseName) derived from the NumericSuffix, which appears to be part of the intent here.
@jamessmckay if I am missing something or you're still facing an issue please open a new PR from latest which addresses it! As an added bonus, we will see test failures right here in GitHub.


I need simple on/off interval timer with delay function

Hello there, I'm newbie at HA. I have some greenhouse plastic boxes with computer fans. I need simple on/off timer with delay function for the fans. For instance I would like to "on" the fans for a particular time "30 sec" and "off" the fans for "5 min" and so on. The HA documents not sufficient to understand. How can I do that ? (I just need automation and script)

Home Assistant release with the issue:

Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):

Component/platform:

Description of problem:
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

This isn't a forum for support or feature requests. For help view the Help page.


chose lessons for workshop

However, I am quite flexible (except when not available) and it can be changed if required.

Awesome, thanks Anne!


Add coveralls setting

Add coveralls setting
Move coverage scripts into coverage.sh

Changes Unknown when pulling be44494a6f83e6c1ce06d63bf207c88ead0662aa on add-coveralls-setting into ** on develop**.

LGTM


Link to existing PR when trying to open a new PR on the same branches

when trying to create a PR for an existing PRs branch combination link to the PR directly and not just to the repo.
Before:

After:

I think there is already a button there

I think there is already a button there

Yes there is a button, but currently the link does only point to the repo.
As the link shows the number of the existing pr it looks like it will open the existing PR. In my opinion this is not intuitive for the user.


[ircnumerics] rename to [numerics]

'ircnumerics' was mostly used just because of the legacy name of the file, we should change this over now and continue to provide 'ircnumerics.html' for things that link to it.

Fixed in c4132dd. Similar to #12, this is a bit of a change, but I think this is necessary and good to do now now rather than trying to do it later when things link to us proper. We also do provide that ircnumerics.html file, so it's not an issue.


"Twitter Bootstrap" => "Bootstrap"

See http://getbootstrap.com/about/#brand

@balupton Ping.

Thank you!


Could not parse kubeconfig file - keyNotFound

Hi,
first of all great idea! :)
However, after installing and configuring the kubeconfig file I get the following error message:
Could not parse selected kubeconfig file
 keyNotFound(CodingKeys(stringValue: "env", intValue: nil), Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "users", intValue: nil), _YAMLCodingKey(stringValue: "Index 0", intValue: 0), CodingKeys(stringValue: "user", intValue: nil), CodingKeys(stringValue: "exec", intValue: nil)], debugDescription: "No value associated with key CodingKeys(stringValue: \"env\", intValue: nil) (\"env\").", underlyingError: nil))

Here the config file:
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <cert>
    server: https://<id>.sk1.us-east-1.eks.amazonaws.com
  name: arn:aws:eks:us-east-1:<account-id>:cluster/test2-blub
contexts:
- context:
    cluster: arn:aws:eks:us-east-1:<account-id>:cluster/test2-blub
    user: arn:aws:eks:us-east-1:<account-id>:cluster/test2-blub
  name: arn:aws:eks:us-east-1:<account-id>:cluster/test2-blub
current-context: arn:aws:eks:us-east-1:<account-id>:cluster/test2-blub
kind: Config
preferences: {}
users:
- name: arn:aws:eks:us-east-1:<account-id>:cluster/test2-blub
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - test2-blub
      command: aws-iam-authenticator

In case this is relevant: the config file is generated by aws eks update-kubeconfig --name.
Any idea how to fix this? :)

Thanks for reporting!
You can install this version until fix is available on App store.

Fix is available on the App Store

Awesome, thx for the quick fix! ;)


[Dynamic Regions] resolved ts can't  advance for long time

Bug Report

What version of TiKV are you using?

TiKV
Release Version:   7.4.0-alpha
Edition:           Community
Git Commit Hash:   e43a157c4a35034dfd705bdd94fac6d958e8a1ff
Git Commit Branch: heads/refs/tags/v7.4.0-alpha
UTC Build Time:    2023-09-14 11:47:25
Rust Version:      rustc 1.67.0-nightly (96ddd32c4 2022-11-14)
Enable Features:   pprof-fp jemalloc mem-profiling portable sse test-engine-kv-rocksdb test-engine-raft-raft-engine cloud-aws cloud-gcp cloud-azure
Profile:           dist_release
What operating system and CPU are you using?

Steps to reproduce

The cluster contains about 60 tikv with dynamic region enabled, each tikv contains 2.5TB data, a table contains about 6billion rows with each row size about 10kb.

What did you expect?
What did happened?

After region merge, TiKV creates a GcPeerRequest with incorrect information. This leads to a misleading GcPeerResponse, causing the target region leader to mistakenly think that the source peers have been garbage collected. As a result, the source peers are left abandoned indefinitely, leading to a stuck resolved ts.
https://github.com/tikv/tikv/blob/4a5fb7321ca2ee2bab0b31f6556c8fb196a590f4/components/raftstore-v2/src/operation/life.rs#L702-L711
After merge, removed peer may come from source region.


Streaming Requests documentation error for Python 3

The documentation for streaming requests supplies a code snippet (below) that hits #3359 which is also experienced in iter_lines due to its use of iter_content.
r = requests.get('http://httpbin.org/stream/20', stream=True)

for line in r.iter_lines():
    if line:
        print(json.loads(line))

Since iter_lines default is decode_unicode=False, it returns bytes causing Python 3 to barf on json.loads(lines). Unfortunately, decode_unicode=True doesn't work either because httpbin.org doesn't provide a charset in the Content-Type header.
As for fixing the example, we can manually decode line before passing it into json.loads. This exposes some of our dirty laundry though, and may give the user the wrong idea that they need to manually decode their strings in all cases.
Alternatively, we update httpbin to pass a charset with the Content-Type and change the example to use decode_unicode=True.
Edit: Moving semi-related comment to appropriate issue. (#3359)

I view this as strictly a Python 2 vs Python 3 problem, rather than a problem with iter_lines. iter_lines returns bytes by default, that's a good sensible default, so we should just decode those bytes ourselves.

Alright, I'll update the example accordingly.

Resolved with #3678.


Bug in L-BFGS-B minimize?

Hi. I think I found a bug. Good news is that I think I know where it's coming from.
I'm calling function minimize with argument method='l-bfgs-b'. I get an error like this:
_________________________________________________________________________
  File "/home/wilmer/Dropbox/Research/VMAT/VMATwPenCode/greedyVMAT.py", line 679, in solveRMC
    res = minimize(calcObjGrad, data.currentIntensities, method='L-BFGS-B', jac = True, bounds=[(0, None) for i in range(0, data.numbeams)], options={'ftol':1e-6, 'disp':5,'maxiter':1000})
  File "/usr/lib/python3.5/site-packages/scipy/optimize/_minimize.py", line 444, in minimize
    callback=callback, **options)
  File "/usr/lib/python3.5/site-packages/scipy/optimize/lbfgsb.py", line 311, in _minimize_lbfgsb
    isave, dsave)
ValueError: failed to initialize intent(inout) array -- input not fortran contiguous
__________________________________________________________________________

I just spent a couple of hours banging my head against my laptop. Here's the solution. The solution was my function calcObjGrad returns a value f and a gradient. Instead of returning gradient I should be returning the transpose of a gradient.
Maybe this problem is not limited to 'L-BFGS-B'? Or maybe it was pointed out in the documentation somewhere in which case, I apologize and please ignore.

Depends on what you mean by "transpose" of the gradient... Usually, given the objective function f(x) where x is a vector (1-dimension, shape (n, )) and f returns a scalar, the gradient has the shape of x and is a vector (1-dimension), so transpose is somehow meaningless.

self.scipygradient = (np.asmatrix(self.mygradient) * self.GradientIntermediate).transpose()

In theory, numpy matrices are great...

For debugging it may help to know the types and shapes of the objects passed to minimize and of the objects returned by the callback function.

I'm using Ubuntu 16.04 with scipy-0.18.1 installed with pip.
Here's a "minimal" reproducible example of the problem I'm having.
https://gist.github.com/odellus/505fe9d1ec8f501c797441bdffaac1b5
If I switch out fmin_cg  for fmin_l_bfgs_b it starts working, but in it's current state I get the error
Traceback (most recent call last):
  File "my_atari_ram_policy.py", line 243, in <module>
    test_AtariRAMPolicy()
  File "my_atari_ram_policy.py", line 240, in test_AtariRAMPolicy
    res = opt.fmin_l_bfgs_b(fpen, theta, fprime=fgradpen, maxiter=20)
  File "/usr/local/lib/python2.7/dist-packages/scipy/optimize/lbfgsb.py", line 193, in fmin_l_bfgs_b
    **opts)
  File "/usr/local/lib/python2.7/dist-packages/scipy/optimize/lbfgsb.py", line 321, in _minimize_lbfgsb
    isave, dsave, maxls)
ValueError: failed to initialize intent(inout) array -- expected elsize=8 but got 4

Could you trim the example a bit further, to remove the dependency on TensorFlow at least.

In fact, if I start playing the guessing game, the error message

ValueError: failed to initialize intent(inout) array -- expected elsize=8 but got 4

looks to be hinting that you have some 32-bit floats somewhere, while Fortran code expects real*8, i.e. C double. And indeed, you have some tf.float32 in your code. So the guess is that the error goes away if you change those to tf.float64 or something to that effect.

That does fix the issue, but I'd really like to be able to hand single precision floats to fmin_l_bfgs_b if possible since they're computed so much faster on the GPU. Maybe I need to read up on Nocedal and Wright some more to see why this , but it doesn't seem like an unreasonable expectation.
Feature request?

Also, many thanks.

Looks similar to https://github.com/scipy/scipy/issues/4873 (hence different from the OP). In principle, I guess, one could copy-paste the Fortran code, replace all double precision with real and write a fused-type cython wrapper to dispatch depending on the input type. This would then be a bit of a project to actually investigate the stability of single-precision maths.

Exactly. I think I'll take a look into how fmin_cg and other fmin_* functions handle both single and double precision since I'm new to SciPy development, but I might have time tackle it if you folks have other priorities at the moment.

@odellus sure thing!

LBFGSB uses finite differences to calculate the jacobian if no callable is provided to the function.
The estimation of gradient by finite differences really requires double precision to work in a reasonable fashion across a range of problems. Whilst SP might be ok for some things they'll be in the minority, and if conversions to double weren't made there would soon be issues being raised by people using SP on problems were DP was required.
Also, the fortran code for LBFGSB is all setup for double precision calculation, and changing it would be a big job, and not necessarily result in improved behaviour.
Thus, the development effort needed to make a change probably outweighs the gain. OP may find that casting to SP before objective/jac calculation on a GPU, then recasting to DP might work satisfactorily.


"ChatCodeInlineTemplate" template boxes cause failures when exploding cells

This rule has a typo:
https://github.com/WolframResearch/Chatbook/blob/21369a0fe8f7e8548bcd7ec6a498990594d1b180/Source/Chatbook/Explode.wl#L64
The style pattern is contained in the BoxData[...] instead of the surrounding cell, so this will never match the desired expressions.

Debug Data

Property
Value

Name
"Wolfram/Chatbook"

Version
"1.3.8"

ReleaseID
"186213a94b060e056f37c20776afdddce2281255"

EvaluationEnvironment
"Session"

FrontEndVersion
"Desktop: 14.0 for Microsoft Windows (64-bit) (December 12, 2023)"

KernelVersion
"14.0.0 for Microsoft Windows (64-bit) (December 13, 2023)"

SystemID
"Windows-x86-64"

Notebooks
True

DynamicEvaluation
True

SynchronousEvaluation
False

TaskEvaluation
False

Settings

Property
Value

StyleSheetVersion
"<IP_ADDRESS>13394031"

Stack Data
throwFailure
trimURL

Failure Data
<|
  "Evaluation" :> Wolfram`Chatbook`Explode`Private`regroupCells[{Cell[TextData[{"Test code block: "}], "Text"], Cell[BoxData[RowBox[{"1", "+", "1"}]], "Input"]}, {"Test inline code:  "}, {Cell[BoxData[TemplateBox[{RowBox[{"2", "+", "2"}]}, "ChatCodeInlineTemplate"]], "ChatCode", Background -> None]}]
  "Arguments" -> {}
  "Stack" :> Wolfram`Chatbook`Common`Private`$stack$17600
|>

Bug was introduced in this commit: https://github.com/WolframResearch/Chatbook/blob/21369a0fe8f7e8548bcd7ec6a498990594d1b180/Source/Chatbook/Explode.wl#L64


Move overdetermined tests to compliance

Reported by jmattsson on 21 Oct 2014 09:18 UTC
The packages ModelicaTest.OverdeterminedInitialization and ModelicaTest.Translational.TestOverdeterminedInitial are tests of the tool's handling of overdetermined initialization systems more than they are tests of the library. They should probably be moved to ModelicaCompliance and converted to that format (or removed, if they are redundant). This especially applies to the models named _Something_Inconsistent, where compilation is supposed to fail.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1591

Modified by jmattsson on 17 Nov 2014 15:03 UTC

Comment by dietmarw on 19 Dec 2014 07:01 UTC
Ticket retargeted after milestone closed

Comment by otter on 19 Feb 2016 21:23 UTC
Fixed in 9e763c47be2f6b25b9b7b22955281df97ae88abd, by moving all models with overdetermined initial equations from ModelicaTest to the new library ModelicaTestOverdetermined

Changelog modified by otter on 19 Feb 2016 21:23 UTC
Moved test models with overdetermined initial equations from ModelicaTest to the new library ModelicaTestOverdetermined


Hiperdex cloudflare bypass not working

As you told me, hiperdex needs to be updated to use a different user agent in order to bypass cloudflare

#445


feat: Add a button to "snooze" tasks

Example of the full mode:

Example of the short mode:

Description
This button allows you to quickly "snooze" (postpone) a task until tomorrow.
If you click on the '⏩' button, the due date of the task is moved to tomorrow.
Motivation and Context
Because

This is my frequent use case
This is the fastest way to delay unimportant tasks
I've seen at minimum one issue about this feature

https://github.com/obsidian-tasks-group/obsidian-tasks/issues/1446
https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2039

How has this been tested?

Tested manually on my vault with two view modes (short and full). I have the latest Obsidian with many plugins.
MacOS Ventura, Node 20:

Screenshots (if appropriate)

Types of changes
Changes visible to users:

[ ] Bug fix (prefix: fix - non-breaking change which fixes an issue)
[x] New feature (prefix: feat - non-breaking change which adds functionality)
[ ] Breaking change (prefix: feat!! or fix!! - fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation (prefix: docs - improvements to any documentation content for users)
[ ] Sample vault (prefix: vault - improvements to the Tasks-Demo sample vault)
[ ] Contributing Guidelines (prefix: contrib - any improvements to documentation content for contributors - see Contributing to Tasks)

Internal changes:

[ ] Refactor (prefix: refactor - non-breaking change which only improves the design or structure of existing code, and making no changes to its external behaviour)
[ ] Tests (prefix: test - additions and improvements to unit tests and the smoke tests)
[ ] Infrastructure (prefix: chore - examples include GitHub Actions, issue templates)

Checklist

[x] My code follows the code style of this project and passes yarn run lint.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] My change has adequate Unit Test coverage.

Terms

[x] My contribution follow this project's contributing guide
[x] I agree to follow this project's Code of Conduct

Hi @m0rtyn,
Thanks very much indeed for implementing this. I'm sure I'm not alone in getting irritated at how long it takes to defer tasks I don't feel like working on today!
I pulled the code in to my own fork of Tasks and used it on my own personal vault for a couple of hours, and then tried various changes to it, to see how much improvement they were, if any.
Some notes follow, but I think the tl,dr is:

I think it's really, really promising
and also that it needs more work before it's ready for release...
how much time and energy do you have for more work on this?
I see from your GH profile you have a lot of coding experience that I don't have - would you be interested in working together with me on this to get it to the stage where it's ready for release?

Some initial thoughts...
For example, these are the things I wondered about whilst experimenting with it...

I'm not sure that users will be able to figure out what 'Snooze' actually means
It shows the snooze button even when there is no due date which is a bit non-obvious
It's got a fast forward icon but if the date is ahead of tomorrow it goes backwards to tomorrow
I think that if the date is already in the future then it should just add one day
I think that if the date was in the past it should probably first forward to the current date
If a task has a scheduled date only, currently the snooze button adds a due date for tomorrow. I think in this situation it should probably edit the schedule date instead.
I think people who use multiple dates on their tasks, such as a start date and a due date, may well want to be able to advance individual dates separately. For example, I might want to leave the due date unchanged, but advance the start date.
It seems to not do anything if the scheduled date value was generated by inferring it from the file name.

In my fork, I experimented with adding an UnSnooze button, as well, and tried out updating any of Due, Scheduled and Starts that were already set - and changing the behaviour depending on the current date. The code is below...
I still don't think I've got the logic quite right (for example, advancing an overdue task moves it to today, which, in short mode, gives no visual feedback if the query is due before tomorrow, as the task is still shown, so it feels like the click was missed...
Also, I often found myself wanting to move a date multiple days forward, like a week or two.... And doing it one click at a time was rather annoying...
Anyway, here was my experiment (after a bit of refactoring):
    private addSnoozeButton(listItem: HTMLElement, task: Task, shortMode: boolean) {
        function snooze(oldDate: Moment | null) {
            // If no date, do not add one
            if (!oldDate) {
                return null;
            }

            // If overdue, fast-forward to today
            if (oldDate.isBefore(window.moment(), 'day')) {
                return window.moment().startOf('day');
            }

            // Otherwise, fast-forward to next day
            return oldDate.clone().add(1, 'days');
        }

        const updatedTask = new Task({
            ...task,
            dueDate: snooze(task.dueDate),
            scheduledDate: snooze(task.scheduledDate),
            startDate: snooze(task.startDate),
        });
        this.addButton(listItem, 'tasks-snooze-button', shortMode, '⏩', 'Snooze', task, updatedTask);
    }

    // Move any dates a day earlier
    private addUnSnoozeButton(listItem: HTMLElement, task: Task, shortMode: boolean) {
        function unSnooze(oldDate: Moment | null) {
            // If no date, do not add one
            if (!oldDate) {
                return null;
            }

            // Otherwise, rewind to previous day
            return oldDate.clone().subtract(1, 'days');
        }

        const updatedTask = new Task({
            ...task,
            dueDate: unSnooze(task.dueDate),
            scheduledDate: unSnooze(task.scheduledDate),
            startDate: unSnooze(task.startDate),
        });
        this.addButton(listItem, 'tasks-unsnooze-button', shortMode, '⏪', 'UnSnooze', task, updatedTask);
    }

    private addButton(
        listItem: HTMLElement,
        cls: string,
        shortMode: boolean,
        icon: string,
        buttonDisplayText: string,
        task: Task,
        updatedTask: Task,
    ) {
        // TODO Add a Tooltip describing what the change will be
        const snoozeButton = listItem.createSpan({ cls: cls });

        const button = snoozeButton.createEl('button');

        button.addClass('internal-button');
        if (shortMode) {
            button.addClass('internal-button-short-mode');
        }

        let buttonText = ' ' + icon;
        if (!shortMode) {
            buttonText += ' ' + buttonDisplayText;
        }

        button.setText(buttonText);

        button.addEventListener('click', async () => {
            replaceTaskWithTasks({
                originalTask: task,
                newTasks: updatedTask,
            });
        });

        button.addEventListener('mousedown', async (ev: MouseEvent) => {
            // Open in a new tab on middle-click.
            // This distinction is not available in the 'click' event, so we handle the 'mousedown' event
            // solely for this.
            // (for regular left-click we prefer the 'click' event, and not to just do everything here, because
            // the 'click' event is more generic for touch devices etc.)
            if (ev.button === 1) {
                replaceTaskWithTasks({
                    originalTask: task,
                    newTasks: updatedTask,
                });
            }
        });
    }

I see from your GH profile you have a lot of coding experience that I don't have

... by this, I mean that it seems you have UI experience, whereas in TypeScript, I am much more a back-end, algorithms kind of person...

@claremacrae Hi. I really like your reply and want to improve this PR. Thank you a lot for the feedback and ideas to improve it.

how much time and energy do you have for more work on this?
Currently, I have enough time to complete this PR with your suggestions within a couple of weeks (approximately).

I'm not sure that users will be able to figure out what 'Snooze' actually means
Yes, it can be "to Next day / Tomorrow / Later" or something similar

It shows the snooze button even when there is no due date which is a bit non-obvious
It's got a fast forward icon but if the date is ahead of tomorrow it goes backwards to tomorrow
Yes, these are bugs. I will fix them.

I think that if the date is already in the future then it should just add one day
I think that if the date was in the past it should probably first forward to the current date
If a task has a scheduled date only, currently the snooze button adds a due date for tomorrow. I think in this situation it should probably edit the schedule date instead.

Good ideas, and I want to implement or fix them as you suggested.

I think people who use multiple dates on their tasks, such as a start date and a due date, may well want to be able to advance individual dates separately. For example, I might want to leave the due date unchanged, but advance the start date.
It seems to not do anything if the scheduled date value was generated by inferring it from the file name.

These points confuse me because they involve unfamiliar use cases. I need to think about them. Could you provide more context or examples to clarify the issue further? I prefer to exclude these improvements or reduce their complexity.

Thanks for the reply @m0rtyn. I’ve done several of these things on my vault as an experiment and wanted to show them to you, to get your feedback.
My message was meant for us to start a conversation, rather than have you go off on your for a couple of weeks.
This is such a complicated topic that by far the easiest way ahead would be for us to have a chat about it, rather than typing back and forward here.
Please would you send me an email - address is in my profile here - to try to set up a call? Many thanks.

This is the most important case I was thinking of when I wrote this issue https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2039
It'd be extremely useful in my opinion.
Is there any way I can help with pushing this forward?

Is there any way I can help with pushing this forward?

What skills do you have?

That said, this is still being worked, and I find that trying to push forward volunteer contributors is rarely effective. So please be patient @chrabia, thanks.

@chrabia, hi. Thank you for your question.
I am mindful of this PR and intend to finalize it.
I think at best I will finalize it today/tomorrow, and at worst I can work with it in a fortnight. No problems at all, but the schedule of my new job is affecting.
Sorry for the silence here.

Thanks very much @m0rtyn.
@chrabia Once the PR is submitted, you could help with the testing, and ideally with writing or reviewing the user docs as well.

Oh, I didn't want to rush you, just wanted to help :).

What skills do you have?

Oh, I can do all kind of stuff I guess, but I'm more of a backend person, so I prefer/I am better with typescript than html/css etc.

@chrabia Once the PR is submitted, you could help with the testing, and ideally with writing or reviewing the user docs as well.

Yeah, sure I can help with testing (and docs probably too). Actually, I already tested it a bit. Mostly I found some things that were already mentioned (past date should go to today and future dates should get +1 day).
Besides that, I'm not really sure what "mousedown" part is for.
Also, the button looks a bit strange on my side. I turned off the css snipets and changed the theme to default, also turned off other plugins, so they are not at fault here.

Hi @chrabia, thanks for a super helpful message. Can you be more specific about what was strange with the button please?

Yeah, sure.
So, in the screenshot from m0rtyn the button is only a emoji, while on my pc it is a complete button, with borders etc (and the emoji inside the button). It looks a lot better as only emoji. Maybe (even though I believe I checked all the setting etc) it's something on my side. I think you can check how it looks on your side @claremacrae .

Perfect, thanks, that's really clear.

Hi @m0rtyn, I see you pushed some changes recently - many thanks! ❤
Don't worry about the merge conflicts... I can sort those out when you're ready...
How are you getting on with this? Is there anything I can do to help?

@claremacrae, hi. It's still in progress. It works, but I tested it and found a couple of bugs.
BTW, I added your suggestion with the context menu (right click) to postpone the task for a week/month/quarter. I think I'll work with PR over the weekend and make final corrections.

Is there anything I can do to help?

Yes, I don't know how to rerender the task list without reloading, to be able to click the postpone button more than once. I currently have an error message on subsequent clicks: "Tasks: could not find the correct task line to update...". I have some hypotheses how to solve it.

Hi @m0rtyn,

@claremacrae, hi. It's still in progress. It works, but I tested it and found a couple of bugs.
BTW, I added your suggestion with the context menu (right click) to postpone the task for a week/month/quarter. I think I'll work with PR over the weekend and make final corrections.

Sounds good - thanks.

Is there anything I can do to help?

Yes, I don't know how to rerender the task list without reloading, to be able to click the postpone button more than once. I currently have an error message on subsequent clicks: "Tasks: could not find the correct task line to update...". I have some hypotheses how to solve it.

I don't exactly know the answer to that, and won't be able to look at it for several days.
But in case it helps, I don't get that problem in my modified copy of your original PR cod...
I was so keen to have the feature that I forked your work.
Here are my diffs that are specific to your work - that is, diffs from my other customisations of Tasks.
https://github.com/claremacrae/obsidian-tasks/compare/bleeding-edge...claremacrae:obsidian-tasks:feat--snooze-button-clare-experiments
The main changes I made to your version are:

Change from 1 button to 3 (1 day earlier, 1 day later, 3 days later)
Move the date calculation logic out to a separate file, and add tests for it
I've been merging main in, so it also has all fixes in the code on main since your branch... I don't know if any of them could explain the difference.

It's working well for me, so there must be something significantly different between this and yours... Maybe you can spot the difference...
If this error is the only problem you have, I suggest you ignore it and create a PR anyway, as I can probably solve it quite quickly - I've looked at that code a lot.

I'm using all the time @m0rtyn version and I also have his bug.
Another bug is that "I think that if the date is already in the future then it should just add one day" is not fixed yet.
The right click context menu is a quite cool feature, but I'm wondering if it would be possible for user to configure it for themselves, the way it is right now I didn't use it even once unfortunately. For example, from my experience it's much more often that I'm postponing something for 2/3 days or postponing to the monday next week. I can't imagine a situation when I'd like to postpone something for a quarter actually.
And again thanks for this contribution! Having this feature already benefitted me greatly.

I've fixed the bug with past dates and also change the option list in the context menu. Postponing for the future dates working well.

@claremacrae I'm going to finish my work with this PR. Could you improve a codestyle and complete a refactoring?

@claremacrae I'm going to finish my work with this PR. Could you improve a codestyle and complete a refactoring?

Hi @m0rtyn, thanks very much indeed - and yes, with pleasure I'll get it ready to release...
Huge thanks!

Just a quick update...
I'm currently working on finishing up Tasks 5.1.0 as I've ended up with lots of stuff in-flight...

I expect to be able to pick up work on Tasks again in 2 to 3 weeks, and this will be the first big thing that I pick up, as I know it's especially valuable to users...

I've renamed the PR to reflect that the button is now called "postpone".

@m0rtyn I'm starting to look at this now.
Please ignore the comments that I am about to add in code review - they are placeholders to remind me to deal with things before merging, and not requests for you to change anything...

Just noting what I've found in exploratory testing before the merge...
Something has changed since the original PR about how the new dates are applied...
In this code, which is a slightly modified version of the original code in this PR, I can make many repeated deferrals to a task with no problems at all:

https://github.com/claremacrae/obsidian-tasks/commit/646c44bed549467a94ca0004fd697e2f33db0b25

With the latest code in this PR, after a few deferrals I get error messages after a few postponements:

I now need to try and work out how the file-editing/saving has changed before merging this.

I see now that this bug was mentioned by @m0rtyn in https://github.com/obsidian-tasks-group/obsidian-tasks/pull/2191#issuecomment-1750115807 - and also by @chrabia ... So it's not specific to my build.
And that I said:

If this error is the only problem you have, I suggest you ignore it and create a PR anyway, as I can probably solve it quite quickly - I've looked at that code a lot.

🤣

We're tracking the next steps in:

https://github.com/obsidian-tasks-group/obsidian-tasks/discussions/2452

I see now that this bug was mentioned by @m0rtyn in #2191 (comment) - and also by @chrabia ... So it's not specific to my build.
And that I said:

If this error is the only problem you have, I suggest you ignore it and create a PR anyway, as I can probably solve it quite quickly - I've looked at that code a lot.

🤣

Just to note that when adding tests I found the source of the problem with the second and subsequent postpone. We were looking at async/await issues but it turned out to be much simpler:
https://github.com/obsidian-tasks-group/obsidian-tasks/pull/2486/files
So the code on main now has the fix, and other improvements that ilandikov and I have been making...

@m0rtyn there was a nice thank you for your work in Discord today:

Just want to express huge thanks to you and others who have brought Tasks so far. The new postpone functionality is for me personally the biggest added value of all. Most grateful.


Check if the first byte is really part of the http header (too short TTFB times on windows!)

Ah I think I found the issue.. I need to sum the durations up 🤔.. Check again how chrome is doing this


Add comparison for Euler solvers using PyClaw.

This is a cleaned-up version of #135.

Thanks @ketch, I like it!  Some comments:

There seems to be a block of stuff repeated twice, from the "Comparison of two approximate solvers with the exact solution" (which doesn't seem to show that) followed by a second copy of "Transonic rarefactions and an entropy fix" and "HLLE Solver" sections.

There's a \wave macro used in (18) that is undefined.

You might point out that when rho goes negative in the Roe solution the velocity and pressure blow up with huge values.

Should I try to write something on transonic rarefactions?

I have mixed feelings about horizontal vs. vertical layout.  Vertical allows one to see how the waves line up between the different plots better and works better on my narrow laptop screen in the sense that one plot doesn't go off the screen to the side, but then with vertical I have to scroll up and down a bit to see all four plots (when I have things magnified to a size where my old eyes can read the text). On balance I think I prefer vertical since it shows more detail and how things line up.

By "Second-order modified Lax-Wendroff algorithm" I assume you mean with limiters?  Maybe best to add "... with limiters" to this heading since people might expect L-W to be more oscillatory.

In the "High-order WENO + Runge-Kutta" section I get warnings like euler_1D_py.py:309: RuntimeWarning: invalid value encountered in sqrt although the plots look fine.

I'm closing this since it is replaced by the contents of Euler_compare.ipynb.  I have tried to resolve most of the comments from @rjleveque in #163.  I went with the vertical layout but also made the plots a bit smaller so they should all fit on the screen.
The section on transonic rarefactions is still missing; if you want to write it, that would be great!


exec() has issues on *nix systems

The old test-suite, which used exec() runs on OSX, but fails on Travis and Ubuntu 14.04:
https://gist.github.com/bcoe/574f20564e423375d0a6
We should dig into the issues with exec() and add some targeted tests.

Addressed in docs https://github.com/isaacs/spawn-wrap#contracts-and-caveats


Added the Azure.MixedReality.Authentication library

This change adds an authentication library for Mixed Reality services, which all currently utilize a custom STS for authentication. Upcoming Mixed Reality client libraries will depend on this library to perform authentication using identities from Azure.Identity. See the added README.md for more information about the library.
ApiView link

/azp run prepare-pipelines

/azp run js - mixedreality - ci

@bterlson and @xirzec Would you mind helping me get some eyes on this PR? It's easy for master to move ahead and cause merge conflicts or other issues, so I'd like to get this in soon if possible. I've also got some other teams needing to take a dependency on this to unblock them. Thanks!

/azp run prepare-pipelines

@chradek can you do a first pass on this one?

@deyaaeldeen and @chradek Thanks for all the feedback! How are we looking?

@craigktreasure looks good to me! @xirzec do you want to have a look?


Rewrite list with Rc rather than Box.

I'm trying to write a wholly stack allocated list implementation, as described in #89, but this may not ever end up seeing the light of day, primarily due to issues relating to the list creation macro (which I think is kind of a necessary feature).
However, it should be easy to replace the boxed references in the current list implementation with reference-counted references, which should make the list persistent and lead to some performance improvements, anyway

It should be possible to do something similar with State so we don't have to copy unchanged stack values. And now that we have benchmarks we can see if this actually makes it faster.


Cookie already set

When I first set up the button it doesn't appear, I thought I was doing something wrong when I realised its already been dismissed/clicked on and I need to clear cookies to make it appear, confirmed this on another device too.

@paulsimonrough please provide more info. Also please clarify if you're using:
v3: window.cookieconsent.inialise({...options})
or
v4: new CookieConsent({...options})

Not sure if this is related but I ran in to a similar problem:
localhost:4200
Implemented on this website and it works
localhost:49802
Different website, but the cookie already exists
I'll report back whether this occurs in production.
Thanks,
Ryan

@coherent-software  ( Ryan )
What's happening is expected behavior. When you're running localhost, that's considered your domain, as though it were 'google.com', if you have google.com:4200 and google.com:48902, those addresses are still using the same domain. With that in mind, the cookies, local storage and session storage all function on a domain level. You can restrict by subdomain, but you'll have to individually add those to the configuration as well then.
Cheers!


Make draft-email-campaign-frontend available

This vhost wasn't set, which means nothing is listening to this vhost.
@bradwright @mattbostock and I looked at the previous PR and this seems to fix the tests. Opened as a new PR in case it's wrong.

I know this pattern just follows the others, but I was wondering why we don't set the default vhost (eg email-campaign-frontend or government-frontend) in the Puppet class as a default argument value? Then we'd only need to override it on draft machines and not explicitly set it everywhere.

I can't think of a good reason to not set a default. I think that would be the correct thing to do in this case.

Okay, so I'll do the default vhost refactor, but as a separate PR as this one seems functionally complete.


How to give height auto for row detail

I'm submitting a ...  (check one with "x")
[ ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ x] support request => Please do not submit support request here

Current behavior
Need help for giving height auto for row details section.
Expected behavior

Reproduction of the problem

What is the motivation / use case for changing the behavior?

**Please tell us about your
OS : Windows
IDE : NetBeans

Table version: 0.7.x
6.1.2

Angular version: 2.0.x
2.4.1

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5]

Hello, did you find a solution for this? I have the same problem.

Use [rowHeight]="'auto'"

It doesn't work for me

I have got the same issue. I need to set scrollbarV and scrollbarH to true, meanwhile show row details (which means I need to set [rowHeight]="'auto'"), but it will give me error if I combine all these options together.

I managed to do it. You need to add this in your global styles:
ngx-datatable {
   .auto-details-height {
      .datatable-row-wrapper {
         height: unset !important;
         .datatable-row-detail {
            height: unset !important;
         }
      }
   }
}

I'm not able to get this working either.. The CSS provided by @Humberd doesn't work for me.
The amount of hard coded pixel sizes in this plugin is insane, very difficult to make a responsive app with this.

Did a slight modification to the solution by @Humberd to make it work for me.
I didn't specify [rowHeight] in ngx-datatable-row-detail either.
ngx-datatable {
  .datatable-row-wrapper {
    height: unset !important;
    .datatable-row-detail {
      height: unset !important;
    }
  }
}

this just results in the detail-row-height being 0...ugh...this is a pita


Bug 2174335:[release-4.12] remove namespace deps from the bundle

These changes will allow us to install operator in any namespace.
Signed-off-by: Nitin Goyal<EMAIL_ADDRESS>Manual cherry-pick of #1908

/bugzilla refresh

/bugzilla refresh

/lgtm

/test ocs-operator-bundle-e2e-aws

/test ocs-operator-bundle-e2e-aws

/test ocs-operator-bundle-e2e-aws

/test ocs-operator-bundle-e2e-aws

looks like openshift ci is really mad, Will run it again in some time.

/test ocs-operator-bundle-e2e-aws

/test ocs-operator-bundle-e2e-aws


Fix DefaultAzureCredential exception issues #8936

ManagedIdentityCredential is unavailable No managed identity endpoint found..

It is missing a period after unavailable
It ends with two periods

SharedTokenCacheCredential is unavailable No accounts were found in thecache. To authenticate with the SharedTokenCacheCredential, login an account through developer tooling supporting Azure single sign on..

Same as above. Missing period. Ends with two periods.
"thecache" needs a space.
"login" should be "log in"
Suggest this: "To authenticate with the SharedTokenCacheCredential, log in with a development tool that supports Azure single sign on."

Solution of period problem:
While creating Aggregate Exception message, don't take care of period. Let inner message take care of period itself.

@tzhanl thanks for your work on this. I have merged these changes as part of PR #9821


Add isExpanded to Section to replace collapsible

If isExpanded is not provided, the section cannot be collapsed/expanded. If provided, it expects a Bool.

Can you add to CHANGELOG


Prevent forced layouts

Right now layouts are being forced by offsetWidth and getComputedStyle(element).
The offsetWidth can be removed (since callOnAdd option exists) and getComputedStyle(element) may be changed to element.style because only position is accessed (which does not need to be computed, or does it?).
This makes the .start() call 10 times faster in bootstrap-elq.

Unfortunately, element.style does not resolve the cascaded style so the script is stuck with using getComputedStyle...


Request permission for redis-fingerprint-storage-plugin

Description

Request upload permission for redis-fingerprint-storage-plugin
repo link: https://github.com/jenkinsci/redis-fingerprint-storage-plugin
hosting request link: https://issues.jenkins-ci.org/browse/HOSTING-964
CC @oleg-nenashev @afalko @mikecirioli
Submitter checklist for changing permissions

Always

[x] Add link to plugin/component Git repository in description above

For a newly hosted plugin only

[x] Add link to resolved HOSTING issue in description above

For a new permissions file only

[x] Make sure the file is created in permissions/ directory
[x] artifactId (pom.xml) is used for name (permissions YAML file).
[x] groupId / artifactId (pom.xml) are correctly represented in path (permissions YAML file)
[x] Check that the file is named plugin-${artifactId}.yml for plugins

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[x] All newly added users have logged in to Artifactory at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @daniel-beck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

@afalko I don't know your JIRA ID which is why I didn't add it, feel free to comment it here if you would like me to add it :)


Fix chef-server-ctl test for opsworks

Passes pedant in the CI environment. Should be good to merge.
The AWS Opsworks Automate offering has Chef Server using Automate's
elasticsearch instead of the built in Solr. This is done via the
external database feature of Chef Server.
This is implemented by setting the following in chef_server.rb:
opscode_solr4['external_url'] = http://localhost:8080/elasticsearch'
And then having nginx proxy that to the elasticsearch backend.
However that breaks pedant because  it uses the solr_root helper, which
would take the above external_url and render http://localhost:8080.
If we use the solr_url helper instead, the full URI is rendered, and
the tests work.
Signed-off-by: Mark Anderson<EMAIL_ADDRESS>

@chef/chef-server-maintainers

The changes pass in pedant now @sdelano

@markan - approved!