unbounded memory growth to OOM with relatively simple scripts on version 1.5.7

Overview
I'm trying to leverage Kapacitor 1.5.7 on Linux/amd64 for context aware traffic alerting in our multi-tenant commerce system at our ingress points for traffic spikes, etc... Typically this means data collection on two (optionally three -- in this example the data is sent but not grouped) fields:

The IP of the requester
The ID of the store for which the request is destined
(optionally) The URI

We collect and report on the data in 1-2 minute windows and don't care about any data outside such window. That is, if the point in question is over 2 minutes old, it should be expired and expunged. Kapacitor is a standalone Influx product for this use case -- there is no InfluxDB instance for this data, no retention policies, etc... Data is transmitted to Kapacitor via the UDP listener.
The format of the message is the following:
combined,uri=/path/to/some/product,id=123456789,ip=<IP_ADDRESS>,role=ingresstype count=1

As shown in singled-out stream stats later detailed in this issue, the cardinality of each of the aforementioned fields is roughly:

uri - unknown, medium
id - 20-30k within a minute window, avg
ip - 40-60k within a minute window, avg
role - at most 3

The count parameter exists so that we can run a mathematical sum operation on the data in the pipe. However, this is redundant because each request generates its own message, its own point, always.
We found Kapacitor struggling with unbounded memory growth in our Production systems, something we did not observe in other (non live traffic) environments. Our initial response to these uncontrollable runaway memory situations was to examine and reduce the cardinality of sets, particularly group by operations on streams. We initially tried reporting on the IP address, the Store ID, and the URI. These are all relatively high cardinality fields, but putting them together in an ordered group by wasn't helping with efficient and unbounded use of memory. So, we paired things back to the following tick script where the uri is dropped from the equation:
dbrp "toptraffic"."autogen"

var streamCounts = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('combined')
    |barrier()
        .period(1m)
        .delete(TRUE)
    |window()
        .period(1m)
        .every(5s)
        .align()
    |sum('count')
        .as('totalCount')

streamCounts
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "totalCount" > 17500)
        .crit(lambda: "totalCount" > 22500)
        .message('''Observed  {{ index .Fields "totalCount" }} requests to Production Store ID {{ index .Tags "id" }} for IP {{ index .Tags "ip" }} within the last minute.''')
        .noRecoveries()
        .stateChangesOnly(5m)
        .slack()
        .channel('#ops-noise')

streamCounts
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "totalCount" > 17500)
        .crit(lambda: "totalCount" > 22500)
        .message('''Observed  {{ index .Fields "totalCount" }} requests to Production Store ID {{ index .Tags "id" }} for IP {{ index .Tags "ip" }} within the last minute.''')
        .stateChangesOnly(5m)
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')
        .log('/var/log/kapacitor/alerts.log')

The script is straight forward enough; we group on the stream by ip, then id, from the combined measurement. A barrier exists to delete data after one minute. These operations are assigned to a stream variable which is used in alerting to do different things (at the same threshold).
The dot graph and sample output of that tick script while running renders:
DOT:
digraph top_combined {
graph [throughput="14278.31 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="518885257"];

from1 [avg_exec_time_ns="43.931µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="518885257"];

barrier2 [avg_exec_time_ns="65.018µs" errors="0" working_cardinality="93843" ];
barrier2 -> window3 [processed="518865870"];

window3 [avg_exec_time_ns="107.889µs" errors="0" working_cardinality="93843" ];
window3 -> sum4 [processed="145863177"];

sum4 [avg_exec_time_ns="148.928µs" errors="0" working_cardinality="33327" ];
sum4 -> alert6 [processed="145863177"];
sum4 -> alert5 [processed="145863177"];

alert6 [alerts_inhibited="0" alerts_triggered="0" avg_exec_time_ns="53.506µs" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="33327" ];

alert5 [alerts_inhibited="0" alerts_triggered="0" avg_exec_time_ns="63.915µs" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="33327" ];
}

As previously mentioned, what we saw with this is that over time (pretty quickly) we ran out of memory. The following graph shows various tweaks to the aforementioned script changing things like the window and barrier periods didn't seem to make any difference to how fast the script/pipeline/Kapacitor consumed memory.

The various spikes in memory show me altering the tick script, removing the window, removing the barrier, changing the barrier from idle to period, changing the time of the barrier tick / window, etc... During these iterations I collected data. The data below is from engagement of the aforementioned tick script, with only changes to the window and barrier periods.
 The first, top_ips does no variable assignment in the tick script and things are piped together in a single flow. The second, top_stores has assignment and piping such that data streams to two alerts that do slightly different things with those triggers, like the aforementioned combined script.
Data to the measurement ips looks like:
ips,ip=<IP_ADDRESS>,role= ingresstype

Here's the show output for top_ips:
ID: top_ips
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 22 Jan 21 22:25 UTC
Modified: 26 Jan 21 06:52 UTC
LastEnabled: 26 Jan 21 06:52 UTC
Databases Retention Policies: ["toptraffic"."autogen"]
TICKscript:
dbrp "toptraffic"."autogen"

stream
    |from()
        .groupBy('ip')
        .measurement('ips')
    |barrier()
        .period(1m)
        .delete(TRUE)
    |window()
        .period(1m)
        .every(5s)
        .align()
    |sum('count')
        .as('totalCount')
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "totalCount" > 17500)
        .crit(lambda: "totalCount" > 22500)
        .message('''Observed  {{ index .Fields "totalCount" }} requests to Production IP {{ index .Tags "ip" }} within the last 1 minute.''')
        .stateChangesOnly(5m)
        .slack()
        .channel('#ops-noise')
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')
        .log('/var/log/kapacitor/alerts.log')

DOT:
digraph top_ips {
graph [throughput="18076.66 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="1891796886"];

from1 [avg_exec_time_ns="45.655µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="1891796886"];

barrier2 [avg_exec_time_ns="22.507µs" errors="0" working_cardinality="58218" ];
barrier2 -> window3 [processed="1891721166"];

window3 [avg_exec_time_ns="251.156µs" errors="0" working_cardinality="58218" ];
window3 -> sum4 [processed="376239068"];

sum4 [avg_exec_time_ns="101.993µs" errors="0" working_cardinality="34455" ];
sum4 -> alert5 [processed="376239068"];

alert5 [alerts_inhibited="0" alerts_triggered="835" avg_exec_time_ns="58.686µs" crits_triggered="101" errors="0" infos_triggered="0" oks_triggered="367" warns_triggered="367" working_cardinality="34455" ];
}

... and for top stores the data looks like:
stores,id=123456789,role=ingresstype

with a evaluated script like:
ID: top_stores
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 22 Jan 21 22:30 UTC
Modified: 26 Jan 21 06:05 UTC
LastEnabled: 26 Jan 21 06:05 UTC
Databases Retention Policies: ["toptraffic"."autogen"]
TICKscript:
dbrp "toptraffic"."autogen"

var stores = stream
    |from()
        .groupBy('id')
        .measurement('stores')
    |barrier()
        .period(1m)
        .delete(TRUE)
    |window()
        .period(1m)
        .every(5s)
        .align()
    |sum('count')
        .as('totalCount')

stores
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "totalCount" > 17500)
        .crit(lambda: "totalCount" > 22500)
        .message('''Observed  {{ index .Fields "totalCount" }} requests to Production Store ID {{ index .Tags "id" }} within the last minute.''')
        .noRecoveries()
        .stateChangesOnly(5m)
        .slack()
        .channel('#ops-noise')

stores
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "totalCount" > 17500)
        .crit(lambda: "totalCount" > 22500)
        .message('''Observed  {{ index .Fields "totalCount" }} requests to Production Store ID {{ index .Tags "id" }} within the last minute.''')
        .stateChangesOnly(5m)
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')
        .log('/var/log/kapacitor/alerts.log')

DOT:
digraph top_stores {
graph [throughput="15742.66 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="1816122105"];

from1 [avg_exec_time_ns="25.922µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="1816122105"];

barrier2 [avg_exec_time_ns="16.675µs" errors="0" working_cardinality="19560" ];
barrier2 -> window3 [processed="1816013270"];

window3 [avg_exec_time_ns="164.84µs" errors="0" working_cardinality="19560" ];
window3 -> sum4 [processed="191193880"];

sum4 [avg_exec_time_ns="592.492µs" errors="0" working_cardinality="12185" ];
sum4 -> alert6 [processed="191193879"];
sum4 -> alert5 [processed="191193879"];

alert6 [alerts_inhibited="0" alerts_triggered="1375" avg_exec_time_ns="93.317µs" crits_triggered="206" errors="0" infos_triggered="0" oks_triggered="586" warns_triggered="583" working_cardinality="12185" ];

alert5 [alerts_inhibited="0" alerts_triggered="789" avg_exec_time_ns="229.573µs" crits_triggered="206" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="583" working_cardinality="12185" ];
}

Note the cardinality of these, at least at the time sampled, was ~12K for store IDs and ~34k for IPs. These on their own seem small potatoes, and, even in the combined script where a group by splits first by the IP, then the Store, shouldn't be too much data for a one or two minute window.
At first this seemed to be a more stable approach, memory didn't seem to grow as fast and I thought we'd level off. Unfortunately, as the graph shows below, we did not.

 The data, while constantly flowing the Kapacitor doesn't cause memory budge from about a gigabyte if all the tick scripts are disabled / inhibited from processing.
A few questions:

Am I correctly configuring Kapacitor to do what I want here for data directly sent to it, that we don't care about at all past the window (again, 1-2 minutes)? That is, the only way to purge data once you open a stream and consume from it is to have barrier events remove them -- this seems to be adding high CPU load and potentially accounting for memory when you get over a size of a certain number, even if cardinality is in check.
Configuring the barrier to emit delete on idle causes quicker growth, a steeper graph, but that's probably because it's not the option for that node we want ... there will essentially never be an idle period in the data Kapacitor receives for these measurements in Production. That said, a lot of time and overhead seem to be spent with the tickers responsible for purging the data.
The carnality does fluctuate and stay within a reasonable size when a tick script is example, as the various aforementioned outputs show. So why the growth till OOM of Kapacitor?
Though sum doesn't really seem to be anywhere near the problem with this configuration and the growth issue, is there a cleaner way of identifying the count of points in the stream? Is it possible for me to drop the value count=1 given that's the only purpose it serves?
Retention in this situation -- where data never interacts with InfluxDB in any way -- is moot, no where in Kapacitor is retention honored, exhibited by the fact that Kapacitor allows you to place already-existing-in-Influx retention periods on data in Kapacitor. Is that right?

I've attached (top_combined_and_top_ip_and_store_kapacitor_1.5.7_growth.tar.gz) the various dumps / profile captures, etc... from the time each of these steps were in place, an output of the structure is:
tree -D
.
├── top_combined
│   ├── [Jan 25 19:31]  allocs?debug=1
│   ├── [Jan 25 19:31]  goroutine?debug=1
│   ├── [Jan 25 19:33]  goroutine?debug=2
│   ├── [Jan 25 19:31]  heap?debug=1
│   ├── [Jan 25 22:52]  index.html
│   ├── [Jan 25 19:32]  mutex?debug=1
│   ├── [Jan 25 19:32]  profile
│   ├── [Jan 25 19:32]  show_top_combined
│   ├── [Jan 25 19:32]  threadcreate?debug=1
│   └── [Jan 25 19:32]  trace
├── top_ip_and_store_id
│   ├── [Jan 27 11:26]  allocs?debug=1
│   ├── [Jan 27 11:23]  goroutine?debug=1
│   ├── [Jan 27 11:23]  goroutine?debug=2
│   ├── [Jan 27 11:25]  heap?debug=1
│   ├── [Jan 27 11:26]  index.html
│   ├── [Jan 27 11:24]  mutex?debug=1
│   ├── [Jan 27 11:25]  profile
│   ├── [Jan 27 11:27]  show_top_ips
│   ├── [Jan 27 11:27]  show_top_stores
│   ├── [Jan 27 11:26]  threadcreate?debug=1
│   └── [Jan 27 11:24]  trace
└── top_ip_and_store_id_last
    ├── [Jan 27 14:18]  allocs?debug=1
    ├── [Jan 27 14:19]  goroutine?debug=1
    ├── [Jan 27 14:19]  goroutine?debug=2
    ├── [Jan 27 14:19]  heap?debug=1
    ├── [Jan 27 14:24]  index.html
    ├── [Jan 27 14:19]  mutex?debug=1
    ├── [Jan 27 14:20]  profile
    ├── [Jan 27 14:20]  threadcreate?debug=1
    └── [Jan 27 14:20]  trace

3 directories, 30 files

With the files in top_ip_and_store_id and top_ip_and_store_id_last taken a few hours apart as the ^^^ shows.

If you don't care about data outside the window then your alert should stop keeping data so old, right now it keeps quite a bit of data in its history to prevent flapping etc.
You don't need a barrier, unless new data for a tagset stops coming in.
Are you using docker?
The carnality does fluctuate and stay within a reasonable size when a tick script is example, as the various aforementioned outputs show. So why the growth till OOM of Kapacitor?

I don't know for your example.

Since count is always 1, you should use a |count() instead of your |sum("count")
Your cardinality isn't insane, so you shouldn't be using anywhere near that much memory.  We did slightly reduce memory pressure in 1.5.8, an upgrade may mitigate your problem signicantly.  Also, if that doesn't work try adding the environmental variable GODEBUG=madvdontneed=1
Good luck, if this doesn't work, come back to me and we can try deeper debugging
The change in 1.5.8 significantly reduced memory pressure from github.com/influxdata/kapacitor/edge.(*pointMessage).GroupInfo
Good luck, if this doesn't work, feel free to poke me again.

Will do. Will try and make some changes in the next few days and report back. Cheers!

Since posting this we dialed back our monitoring to three tick scripts with a single measurement each:

ip
store ID
user agent

with scripts that look like:
dbrp "toptraffic"."autogen"

var windowedStream = stream
  |from()
    .groupBy('ip')
    .measurement('ips')
  |barrier()
    .period(2m)
    .delete(TRUE)
  |window()
    .period(2m)
    .every(5s)
    .align()

var storelbStream = windowedStream
  |where(lambda: "role" == 'storelb')
  |sum('count')
    .as('totalCount')

var sharedlbStream = windowedStream
  |where(lambda: "role" == 'sharedlb')
  |sum('count')
    .as('totalCount')

var joinStream = storelbStream
  |join(sharedlbStream)
    .as('storelb','sharedlb')
    .tolerance(1s)

joinStream
  |alert()
    .flapping(0.25, 0.5)
    .history(21)
    .warn(lambda: "storelb.totalCount" > 75000 OR "sharedlb.totalCount" > 75000 OR "storelb.totalCount" + "sharedlb.totalCount" > 75000)
    .crit(lambda: "storelb.totalCount" > 125000 OR "sharedlb.totalCount" > 125000 OR "storelb.totalCount" + "sharedlb.totalCount" > 125000)
    .message('''Observed a high rate of request volume in Production for IP {{ index .Tags "ip" }}. Requests within a 2m window at the Store LB are: {{ index .Fields "storelb.totalCount" }} and Shared LB: {{ index .Fields "sharedlb.totalCount" }}.''')
    .stateChangesOnly(2m)
    .slack()
    .channel('#ops-noise')
    .noRecoveries()

joinStream
  |alert()
    .flapping(0.25, 0.5)
    .history(21)
    .warn(lambda: "storelb.totalCount" > 75000 OR "sharedlb.totalCount" > 75000 OR "storelb.totalCount" + "sharedlb.totalCount" > 75000)
    .crit(lambda: "storelb.totalCount" > 125000 OR "sharedlb.totalCount" > 125000 OR "storelb.totalCount" + "sharedlb.totalCount" > 125000)
    .message('''Observed a high rate of request volume in Production for IP {{ index .Tags "ip" }}. Requests within a 2m window at the Store LB are: {{ index .Fields "storelb.totalCount" }} and Shared LB: {{ index .Fields "sharedlb.totalCount" }}.''')
    .stateChangesOnly(2m)
    .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')

We thought we were holding steady at around 5GB memory usage, but over 8-9 days we crept up to 9.5 or so.

We deployed the changes you recommended (excluding the count change) altering the script to look like:
dbrp "toptraffic"."autogen"

var windowedStream = stream
  |from()
    .groupBy('ip')
    .measurement('ips')
  |window()
    .period(2m)
    .every(5s)
    .align()

var storelbStream = windowedStream
  |where(lambda: "role" == 'storelb')
  |sum('count')
    .as('totalCount')

var sharedlbStream = windowedStream
  |where(lambda: "role" == 'sharedlb')
  |sum('count')
    .as('totalCount')

var joinStream = storelbStream
  |join(sharedlbStream)
    .as('storelb','sharedlb')
    .tolerance(1s)

joinStream
  |alert()
    .warn(lambda: "storelb.totalCount" > 75000 OR "sharedlb.totalCount" > 75000 OR "storelb.totalCount" + "sharedlb.totalCount" > 75000)
    .crit(lambda: "storelb.totalCount" > 125000 OR "sharedlb.totalCount" > 125000 OR "storelb.totalCount" + "sharedlb.totalCount" > 125000)
    .message('''Observed a high rate of request volume in Production for IP {{ index .Tags "ip" }}. Requests within a 2m window at the Store LB are: {{ index .Fields "storelb.totalCount" }} and Shared LB: {{ index .Fields "sharedlb.totalCount" }}.''')
    .slack()
    .channel('#ops-noise')
    .noRecoveries()

joinStream
  |alert()
    .warn(lambda: "storelb.totalCount" > 75000 OR "sharedlb.totalCount" > 75000 OR "storelb.totalCount" + "sharedlb.totalCount" > 75000)
    .crit(lambda: "storelb.totalCount" > 125000 OR "sharedlb.totalCount" > 125000 OR "storelb.totalCount" + "sharedlb.totalCount" > 125000)
    .message('''Observed a high rate of request volume in Production for IP {{ index .Tags "ip" }}. Requests within a 2m window at the Store LB are: {{ index .Fields "storelb.totalCount" }} and Shared LB: {{ index .Fields "sharedlb.totalCount" }}.''')
    .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')

...which produced rapid memory utilization up to about 35.5GB over 5 1/2 hours:

Now that we're a few hours out, here'a a memory graph with a wider timeline than the other two in the prior comment.

The graph starts with the tick scripts in place without the changes mentioned. The peaks after the yellow arrow indicate me making various changes to the alert node, dropping history/flapping/state change tracking and the barrier nodes. The red arrow is where we revert to the tick scripts that are in place prior to the yellow arrow.

@docmerlin any thoughts on those updates ^^^ ?

Yes, we found several memory leaks in JoinNode and UnionNode and are fixing them now,  That being said it is still possible for memory to grow depending on your data cardinality.

@joshdurbin here is a PR to fix some of the leakage.
https://github.com/influxdata/kapacitor/pull/2489

As those merged PRs expected in the next release?

And, yeah, we see that the cardinality controls aren't passing through he join node and the dependent nodes on our end too, in these use cases:
ID: top_ips
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 22 Jan 21 22:25 UTC
Modified: 12 Feb 21 01:40 UTC
LastEnabled: 12 Feb 21 01:40 UTC
Databases Retention Policies: ["toptraffic"."autogen"]
TICKscript:
dbrp "toptraffic"."autogen"

var windowedStream = stream
    |from()
        .groupBy('ip')
        .measurement('ips')
    |barrier()
        .period(2m)
        .delete(TRUE)
    |window()
        .period(2m)
        .every(5s)
        .align()

var storelbStream = windowedStream
    |where(lambda: "role" == 'storelb')
    |sum('count')
        .as('totalCount')

var sharedlbStream = windowedStream
    |where(lambda: "role" == 'sharedlb')
    |sum('count')
        .as('totalCount')

var joinStream = storelbStream
    |join(sharedlbStream)
        .as('storelb', 'sharedlb')
        .tolerance(1s)

joinStream
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "storelb.totalCount" > 75000 OR "sharedlb.totalCount" > 75000 OR "storelb.totalCount" + "sharedlb.totalCount" > 75000)
        .crit(lambda: "storelb.totalCount" > 125000 OR "sharedlb.totalCount" > 125000 OR "storelb.totalCount" + "sharedlb.totalCount" > 125000)
        .message('''Observed a high rate of request volume in Production for IP {{ index .Tags "ip" }}. Requests within a 2m window at the Store LB are: {{ index .Fields "storelb.totalCount" }} and Shared LB: {{ index .Fields "sharedlb.totalCount" }}.''')
        .stateChangesOnly(2m)
        .slack()
        .channel('#ops-noise')
        .noRecoveries()

joinStream
    |alert()
        .flapping(0.25, 0.5)
        .history(21)
        .warn(lambda: "storelb.totalCount" > 75000 OR "sharedlb.totalCount" > 75000 OR "storelb.totalCount" + "sharedlb.totalCount" > 75000)
        .crit(lambda: "storelb.totalCount" > 125000 OR "sharedlb.totalCount" > 125000 OR "storelb.totalCount" + "sharedlb.totalCount" > 125000)
        .message('''Observed a high rate of request volume in Production for IP {{ index .Tags "ip" }}. Requests within a 2m window at the Store LB are: {{ index .Fields "storelb.totalCount" }} and Shared LB: {{ index .Fields "sharedlb.totalCount" }}.''')
        .stateChangesOnly(2m)
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')

DOT:
digraph top_ips {
graph [throughput="4891.68 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="4940426264"];

from1 [avg_exec_time_ns="111.079µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="4940426264"];

barrier2 [avg_exec_time_ns="38.583µs" errors="0" working_cardinality="7172" ];
barrier2 -> window3 [processed="4940418579"];

window3 [avg_exec_time_ns="685.66µs" errors="0" working_cardinality="7172" ];
window3 -> where6 [processed="247104855"];
window3 -> where4 [processed="247104855"];

where6 [avg_exec_time_ns="177.822µs" errors="0" working_cardinality="2728" ];
where6 -> sum7 [processed="247104855"];

sum7 [avg_exec_time_ns="209.806µs" errors="0" working_cardinality="2728" ];
sum7 -> join9 [processed="247104855"];

where4 [avg_exec_time_ns="862.96µs" errors="0" working_cardinality="2728" ];
where4 -> sum5 [processed="247104855"];

sum5 [avg_exec_time_ns="218.497µs" errors="0" working_cardinality="2728" ];
sum5 -> join9 [processed="247104855"];

join9 [avg_exec_time_ns="919.745µs" errors="0" working_cardinality="749692" ];
join9 -> alert11 [processed="247104855"];
join9 -> alert10 [processed="247104855"];

alert11 [alerts_inhibited="0" alerts_triggered="73" avg_exec_time_ns="50.693µs" crits_triggered="1" errors="0" infos_triggered="0" oks_triggered="36" warns_triggered="36" working_cardinality="749692" ];

alert10 [alerts_inhibited="0" alerts_triggered="37" avg_exec_time_ns="261.104µs" crits_triggered="1" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="36" working_cardinality="749692" ];
}

I don't believe this comment on an issue from 2016 is correct. From what I can tell there is no situation, once a stream has been opened, where memory doesn't build to an OOM scenario.
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')

var sharedLBTraffic = traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

var storeLBTraffic = traffic
    |where(lambda: "src" == 2)
    |sum('src')
        .as('total')

##############
First is:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')

Second is:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')

var sharedLBTraffic = traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

Third is:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')

traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

Next up, test 4, is (ruling out discrepancy between sum and count:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')

traffic
    |where(lambda: "src" == 1)
    |count('src')
        .as('total')

Fifth test is reverting the count/sum thing and adding a 30 second barrier configured to delete:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(30s)
        .delete(TRUE)

traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

This does show a smoothing of memory usage.

Next up, sixth test/change is adding the counts to the other monitored system:
Tick script omitted here as its show in the exec outputs below.
We can confirm that the barrier node is reducing cardinality with two subsequent runs via kapacitor show ips_and_stores:
ID: ips_and_stores
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 11 Mar 21 18:05 UTC
Modified: 11 Mar 21 20:06 UTC
LastEnabled: 11 Mar 21 20:06 UTC
Databases Retention Policies: ["toptraffic"."autogen"]
TICKscript:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(30s)
        .delete(TRUE)

var storeLBTraffic = traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

var sharedLBTraffic = traffic
    |where(lambda: "src" == 2)
    |sum('src')
        .as('total')

DOT:
digraph ips_and_stores {
graph [throughput="14576.14 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="522683"];

from1 [avg_exec_time_ns="48.437µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="522683"];

barrier2 [avg_exec_time_ns="2.28µs" errors="0" working_cardinality="84561" ];
barrier2 -> where5 [processed="522683"];
barrier2 -> where3 [processed="522683"];

where5 [avg_exec_time_ns="3.735µs" errors="0" working_cardinality="84561" ];
where5 -> sum6 [processed="167322"];

sum6 [avg_exec_time_ns="14.734µs" errors="0" working_cardinality="7337" ];

where3 [avg_exec_time_ns="3.354µs" errors="0" working_cardinality="84561" ];
where3 -> sum4 [processed="355361"];

sum4 [avg_exec_time_ns="12.121µs" errors="0" working_cardinality="77277" ];
}

ID: ips_and_stores
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 11 Mar 21 18:05 UTC
Modified: 11 Mar 21 20:06 UTC
LastEnabled: 11 Mar 21 20:06 UTC
Databases Retention Policies: ["toptraffic"."autogen"]
TICKscript:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(30s)
        .delete(TRUE)

var storeLBTraffic = traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

var sharedLBTraffic = traffic
    |where(lambda: "src" == 2)
    |sum('src')
        .as('total')

DOT:
digraph ips_and_stores {
graph [throughput="16238.66 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="801608"];

from1 [avg_exec_time_ns="48.437µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="801608"];

barrier2 [avg_exec_time_ns="2.28µs" errors="0" working_cardinality="73055" ];
barrier2 -> where5 [processed="801608"];
barrier2 -> where3 [processed="801608"];

where5 [avg_exec_time_ns="3.735µs" errors="0" working_cardinality="73054" ];
where5 -> sum6 [processed="254519"];

sum6 [avg_exec_time_ns="14.734µs" errors="0" working_cardinality="6920" ];

where3 [avg_exec_time_ns="3.354µs" errors="0" working_cardinality="73055" ];
where3 -> sum4 [processed="547089"];

sum4 [avg_exec_time_ns="12.121µs" errors="0" working_cardinality="66199" ];
}

Seventh test/change is joining those two count streams where we see that the cardinality of the join node is never reduced.
ID: ips_and_stores
Error:
Template:
Type: stream
Status: enabled
Executing: true
Created: 11 Mar 21 18:05 UTC
Modified: 11 Mar 21 20:12 UTC
LastEnabled: 11 Mar 21 20:12 UTC
Databases Retention Policies: ["toptraffic"."autogen"]
TICKscript:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(30s)
        .delete(TRUE)

var storeLBTraffic = traffic
    |where(lambda: "src" == 1)
    |sum('src')
        .as('total')

var sharedLBTraffic = traffic
    |where(lambda: "src" == 2)
    |sum('src')
        .as('total')

var joinStream = storeLBTraffic
    |join(sharedLBTraffic)
        .as('storelb', 'sharedlb')
        .tolerance(1s)

DOT:
digraph ips_and_stores {
graph [throughput="15907.77 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="6765340"];

from1 [avg_exec_time_ns="9.93µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="6765342"];

barrier2 [avg_exec_time_ns="19.601µs" errors="0" working_cardinality="79006" ];
barrier2 -> where5 [processed="6765291"];
barrier2 -> where3 [processed="6765291"];

where5 [avg_exec_time_ns="5.58µs" errors="0" working_cardinality="79006" ];
where5 -> sum6 [processed="2127062"];

sum6 [avg_exec_time_ns="27.531µs" errors="0" working_cardinality="6877" ];
sum6 -> join8 [processed="2031335"];

where3 [avg_exec_time_ns="7.545µs" errors="0" working_cardinality="79006" ];
where3 -> sum4 [processed="4638228"];

sum4 [avg_exec_time_ns="32.777µs" errors="0" working_cardinality="72199" ];
sum4 -> join8 [processed="3627725"];

join8 [avg_exec_time_ns="19.833µs" errors="0" working_cardinality="627063" ];
}

So this all looks due to the sum and count operations on nodes.
The next iteration of something I'm trying to avoid the join is:
dbrp "toptraffic"."autogen"

var traffic = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(120s)
        .delete(TRUE)
    |stateCount(lambda: "src" == 1)
        .as('total_store_lb')
    |stateCount(lambda: "src" == 2)
        .as('total_shared_lb')
    |eval(lambda: if("total_store_lb" == -1, 0, "total_store_lb"), lambda: if("total_shared_lb" == -1, 0, "total_shared_lb"))
        .as('unsigned_total_store_lb','unsigned_total_shared_lb')
        .keep('total_store_lb', 'total_shared_lb', 'unsigned_total_store_lb', 'unsigned_total_shared_lb')
    |alert()
        .warn(lambda: "unsigned_total_store_lb" > 2500 OR "unsigned_total_shared_lb" > 2500 OR "unsigned_total_store_lb" + "unsigned_total_shared_lb" > 2500)
        .message('Observed a high rate of request volume from IP {{ index .Tags "ip" }} for Store ID {{ index .Tags "id" }} at the Shared LB: {{ index .Fields "unsigned_total_shared_lb" }} and the Store LB: {{ index .Fields "unsigned_total_store_lb" }}')
        .stateChangesOnly(2m)
        .log('/var/log/kapacitor/test.log')

It would be nice if we could change the "not found" value for the stateCount node. Of course, I could guard the stateCount node with a where cause, but then I have to split (considering I have two conditionals here) -- I need to count all those where the field src has the value 1 and 2, independently.

As suggested in this thread earlier, the alert() node takes considerable memory with its configured parameters to suppress x minutes of state changes, history, flapping, etc... Particularly since we know that barrier node signals don't make it through the join node at the moment.
Example tick scripts:
First round
dbrp "toptraffic"."autogen"

var trafficByIPAndStoreIDStream = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(121s)
        // the period for the barrier should be +1 unit over the period defined in the downstream window
        .delete(TRUE)
    |window()
        .period(120s)
        .every(5s)
    |default()
        // count is not set the filebeat-udp messenger, so we add it to each point coming through with a value of 1
        .field('count', 1)

var storeLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 1)
    // the filebeat-udp message source sets the `src` field key to the value 1 for the store LB
    |sum('count')
        // we sum on count here and not upstream because this operation drops all other fields from the forward point
        .as('totalCount')

var sharedLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 2)
    // the filebeat-udp message source sets the `src` field key to the value 2 for the shared LB
    |sum('count')
        // see the other sum message ^^^
        .as('totalCount')

var joinedTrafficStream = storeLBTrafficStream
    |join(sharedLBTrafficStream)
        .as('storelb', 'sharedlb')

joinedTrafficStream
    |alert()
        .warn(lambda: int("storelb.totalCount") > 50000 OR int("sharedlb.totalCount") > 50000 OR int("storelb.totalCount") + int("sharedlb.totalCount") > 50000)
        .crit(lambda: int("storelb.totalCount") > 75000 OR int("sharedlb.totalCount") > 75000 OR int("storelb.totalCount") + int("sharedlb.totalCount") > 75000)
        .message('Production IP {{ index .Tags "ip" }} has exceeded request thresholds for the Store ID {{ index .Tags "id" }} via the Shared LB: {{ index .Fields "sharedlb.totalCount" }} and the Store LB: {{ index .Fields "storelb.totalCount" }} within the last 2 minutes.')
        .stateChangesOnly(5m)
        .noRecoveries()
        .slack()
        .channel('#ops-noise')

joinedTrafficStream
    |alert()
        .warn(lambda: int("storelb.totalCount") > 50000 OR int("sharedlb.totalCount") > 50000 OR int("storelb.totalCount") + int("sharedlb.totalCount") > 50000)
        .crit(lambda: int("storelb.totalCount") > 75000 OR int("sharedlb.totalCount") > 75000 OR int("storelb.totalCount") + int("sharedlb.totalCount") > 75000)
        .message('Production IP {{ index .Tags "ip" }} has exceeded request thresholds for the Store ID {{ index .Tags "id" }} via the Shared LB: {{ index .Fields "sharedlb.totalCount" }} and the Store LB: {{ index .Fields "storelb.totalCount" }} within the last 2 minutes.')
        .stateChangesOnly(5m)
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')

Second Round
Here the join stream remains and the alert nodes are removed.
dbrp "toptraffic"."autogen"

var trafficByIPAndStoreIDStream = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(121s)
        // the period for the barrier should be +1 unit over the period defined in the downstream window
        .delete(TRUE)
    |window()
        .period(120s)
        .every(5s)
    |default()
        // count is not set the filebeat-udp messenger, so we add it to each point coming through with a value of 1
        .field('count', 1)

var storeLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 1)
    // the filebeat-udp message source sets the `src` field key to the value 1 for the store LB
    |sum('count')
        // we sum on count here and not upstream because this operation drops all other fields from the forward point
        .as('totalCount')

var sharedLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 2)
    // the filebeat-udp message source sets the `src` field key to the value 2 for the shared LB
    |sum('count')
        // see the other sum message ^^^
        .as('totalCount')

var joinedTrafficStream = storeLBTrafficStream
    |join(sharedLBTrafficStream)
        .as('storelb', 'sharedlb')

Third Round
Here the join stream is completely removed.
dbrp "toptraffic"."autogen"

var trafficByIPAndStoreIDStream = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(121s)
        // the period for the barrier should be +1 unit over the period defined in the downstream window
        .delete(TRUE)
    |window()
        .period(120s)
        .every(5s)
    |default()
        // count is not set the filebeat-udp messenger, so we add it to each point coming through with a value of 1
        .field('count', 1)

var storeLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 1)
    // the filebeat-udp message source sets the `src` field key to the value 1 for the store LB
    |sum('count')
        // we sum on count here and not upstream because this operation drops all other fields from the forward point
        .as('totalCount')

var sharedLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 2)
    // the filebeat-udp message source sets the `src` field key to the value 2 for the shared LB
    |sum('count')
        // see the other sum message ^^^
        .as('totalCount')

What I settled on, for now, is this:
dbrp "toptraffic"."autogen"

var trafficByIPAndStoreIDStream = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(121s)
        // the period for the barrier should be +1 unit over the period defined in the downstream window
        .delete(TRUE)
    |window()
        .period(120s)
        .every(5s)
    |default()
        // count is not set the filebeat-udp messenger, so we add it to each point coming through with a value of 1
        .field('count', 1)

var storeLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 1)
    // the filebeat-udp message source sets the `src` field key to the value 1 for the store LB
    |sum('count')
        // we sum on count here and not upstream because this operation drops all other fields from the forward point
        .as('totalCount')

var sharedLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "src" == 2)
    // the filebeat-udp message source sets the `src` field key to the value 2 for the shared LB
    |sum('count')
        // see the other sum message ^^^
        .as('totalCount')

var joinedTrafficStream = storeLBTrafficStream
    |join(sharedLBTrafficStream)
        .as('storelb', 'sharedlb')

joinedTrafficStream
    |alert()
        .warn(lambda: int("storelb.totalCount") > 50000 OR int("sharedlb.totalCount") > 50000 OR int("storelb.totalCount") + int("sharedlb.totalCount") > 50000)
        .crit(lambda: int("storelb.totalCount") > 75000 OR int("sharedlb.totalCount") > 75000 OR int("storelb.totalCount") + int("sharedlb.totalCount") > 75000)
        .message('Production IP {{ index .Tags "ip" }} has exceeded request thresholds for the Store ID {{ index .Tags "id" }} via the Shared LB: {{ index .Fields "sharedlb.totalCount" }} and the Store LB: {{ index .Fields "storelb.totalCount" }} within the last 2 minutes.')
        .stateChangesOnly(5m)
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')
        .slack()
        .channel('#ops-noise')

Which combines the alert nodes into one -- I had them broken out purely because I wanted recoveries to goto our pubsub channel but not to slack. This reduces the memory growth a bit. The bandaid I'll apply to this is service restarts at memory thresholds via systemd, I think.
That said, getting the barrier emission through the join node, the memory leak with join, etc... released should help.

The current and final iteration of this is:
dbrp "toptraffic"."autogen"

var trafficByIPAndStoreIDStream = stream
    |from()
        .groupBy('ip', 'id')
        .measurement('ips_and_stores')
    |barrier()
        .period(121s)
        // the period for the barrier should be +1 unit over the period defined in the downstream window
        .delete(TRUE)
    |window()
        .period(120s)
        .every(5s)

var storeLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "source" == 'storelb')
    |sum('count')
        // sum on count here as this operation drops all other fields from the point
        .as('totalCount')

var sharedLBTrafficStream = trafficByIPAndStoreIDStream
    |where(lambda: "source" == 'sharedlb')
    |sum('count')
        // sum on count here as this operation drops all other fields from the point
        .as('totalCount')

var joinedTrafficStream = storeLBTrafficStream
    |join(sharedLBTrafficStream)
        // join the sum streams together with their tags, reminder that fields other than totalCount are dropped due to the upstream
        .as('storelb', 'sharedlb')
        .tolerance(1s)

joinedTrafficStream
    |alert()
        .warn(lambda: "storelb.totalCount" > 50000 OR "sharedlb.totalCount" > 50000 OR "storelb.totalCount" + "sharedlb.totalCount" > 50000)
        .crit(lambda: "storelb.totalCount" > 80000 OR "sharedlb.totalCount" > 80000 OR "storelb.totalCount" + "sharedlb.totalCount" > 80000)
        .message('Production IP {{ index .Tags "ip" }} has exceeded request thresholds for the Store ID {{ index .Tags "id" }} via the Shared LB: {{ index .Fields "sharedlb.totalCount" }} and the Store LB: {{ index .Fields "storelb.totalCount" }} within the last 2 minutes.')
        .stateChangesOnly(5m)
        .slack()
        .channel('#ops-noise')
        .exec('/usr/bin/kapacitor_pubsub_stdin_invoker.sh')

with a dot graph of:
digraph ips_and_stores {
graph [throughput="16786.69 points/s"];

stream0 [avg_exec_time_ns="0s" errors="0" working_cardinality="0" ];
stream0 -> from1 [processed="128532482"];

from1 [avg_exec_time_ns="26.78µs" errors="0" working_cardinality="0" ];
from1 -> barrier2 [processed="128532482"];

barrier2 [avg_exec_time_ns="67.601µs" errors="0" working_cardinality="238931" ];
barrier2 -> window3 [processed="128532108"];

window3 [avg_exec_time_ns="93.931µs" errors="0" working_cardinality="238931" ];
window3 -> where6 [processed="33450748"];
window3 -> where4 [processed="33450748"];

where6 [avg_exec_time_ns="38.962µs" errors="0" working_cardinality="60604" ];
where6 -> sum7 [processed="33450748"];

sum7 [avg_exec_time_ns="46.81µs" errors="0" working_cardinality="60606" ];
sum7 -> join9 [processed="33450748"];

where4 [avg_exec_time_ns="43.106µs" errors="0" working_cardinality="60604" ];
where4 -> sum5 [processed="33450748"];

sum5 [avg_exec_time_ns="46.444µs" errors="0" working_cardinality="60604" ];
sum5 -> join9 [processed="33450748"];

join9 [avg_exec_time_ns="117.824µs" errors="0" working_cardinality="6803685" ];
join9 -> alert10 [processed="33450745"];

alert10 [alerts_inhibited="0" alerts_triggered="0" avg_exec_time_ns="51.397µs" crits_triggered="0" errors="0" infos_triggered="0" oks_triggered="0" warns_triggered="0" working_cardinality="6803683" ];
}

...showing high cardinality from the join, join9, forward. With the throughput rates shown in the dot graph our kapacitor instances need restarting about every 1 hour and 50 minutes with a 45GB memory limit set on the process defined by MemoryMax=45G on the systemd unit file.

I'm also seeing a similar behaviors using the latest release 1.7.1 here's a top of the heap hprof:
Showing nodes accounting for 9203.41MB, 97.93% of 9398.23MB total
Dropped 243 nodes (cum <= 46.99MB)
Showing top 10 nodes out of 40
      flat  flat%   sum%        cum   cum%
 3537.67MB 37.64% 37.64%  3537.67MB 37.64%  github.com/influxdata/influxdb/models.Tags.Map (inline)
 3410.08MB 36.28% 73.93%  3410.58MB 36.29%  github.com/influxdata/influxdb/models.(*point).unmarshalBinary
 1166.16MB 12.41% 86.33%  1166.16MB 12.41%  github.com/influxdata/kapacitor/edge.(*pointMessage).ShallowCopy
  448.08MB  4.77% 91.10%   448.08MB  4.77%  github.com/influxdata/kapacitor/alert.newHandler
  246.01MB  2.62% 93.72%   246.01MB  2.62%  strings.(*Builder).grow (inline)
  200.91MB  2.14% 95.86%   200.91MB  2.14%  github.com/influxdata/kapacitor.(*windowTimeBuffer).insert
  194.50MB  2.07% 97.93%  7157.76MB 76.16%  github.com/influxdata/kapacitor.(*TaskMaster).WritePoints
         0     0% 97.93%  3410.58MB 36.29%  github.com/influxdata/influxdb/models.(*point).Fields
         0     0% 97.93%   456.60MB  4.86%  github.com/influxdata/kapacitor.(*AlertNode).runAlert
         0     0% 97.93%  1415.18MB 15.06%  github.com/influxdata/kapacitor.(*FromNode).Point

I'm using a lot of stream queries based on this example

WritePoints seems to be causing the problem, where is it used?
File: kapacitord
Build ID: 7cdd357954d1cbca82a4f08b6fcbce65e372a1fe
Type: inuse_space
Time: Nov 30, 2023 at 7:06am (EST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 17.23GB, 98.79% of 17.44GB total
Dropped 232 nodes (cum <= 0.09GB)
Showing top 10 nodes out of 41
      flat  flat%   sum%        cum   cum%
    6.84GB 39.20% 39.20%     6.84GB 39.20%  github.com/influxdata/influxdb/models.Tags.Map (inline)
    6.48GB 37.18% 76.38%     6.49GB 37.18%  github.com/influxdata/influxdb/models.(*point).unmarshalBinary
    2.24GB 12.84% 89.21%     2.24GB 12.84%  github.com/influxdata/kapacitor/edge.(*pointMessage).ShallowCopy
    0.50GB  2.84% 92.05%     0.50GB  2.84%  strings.(*Builder).grow
    0.44GB  2.54% 94.59%     0.44GB  2.54%  github.com/influxdata/kapacitor/alert.newHandler
    0.37GB  2.10% 96.69%    13.74GB 78.80%  github.com/influxdata/kapacitor.(*TaskMaster).WritePoints
    0.24GB  1.40% 98.09%     0.24GB  1.40%  github.com/influxdata/kapacitor.(*windowTimeBuffer).insert
    0.12GB   0.7% 98.79%     0.12GB   0.7%  io.ReadAll
         0     0% 98.79%     6.49GB 37.18%  github.com/influxdata/influxdb/models.(*point).Fields
         0     0% 98.79%     0.45GB  2.57%  github.com/influxdata/kapacitor.(*AlertNode).runAlert


add antlr old wiki

added content for antlr to have a base to build on top so @Chris2011 could review on live site.
Skipped the integration https://web.archive.org/web/20100309115543/http://wiki.netbeans.org/AntlrInNetBeansJavaApplication as it needs rewrite for maven + antlr4 I guess.
Lots of missing image on syntaxAntlr wiki pages

merging to have base for improvment for @Chris2011

Thx, will do in a couple of days.


feat: Authentication using tokenization

Description
I'm trying to add authentication in an open source project which is developed using dart_frog and flutter. But I'm unable to find a proper way of using JWT token for this purpose.
I've tried to find a way online but failed, if there's any example I would love to take a look at that.
Link: https://github.com/mhmzdev/full-stack-flutter-app
Requirements

[x] dart_frog auth documentation
[x] other dart packages that will be used along side for JWT

We have just recently released a tutorial that covers that: https://dartfrog.vgv.dev/docs/tutorials/jwt_authentication
Let us know if there is anything else missing that we should cover.
Thanks!


Fonts are not exported when exporting excalidraw content with custom fonts

Describe the bug
1.Open the exalidraw page directly and the custom font is displayed damaged.
I took a look at this problem, because this plugin uses this interface to export svg images.
await view.svg(...);

However, the saveSVG interface of excalidraw-plugin will add the refs tag of the custom font.
2.excalidraw embedded in note does not display the three built-in fonts.
Because there is no corresponding css in the exported content.
Operating System
MacOS
To Reproduce
Steps to reproduce the behavior:

Set custom font.
Export.
Fonts are not displayed properly.

I'll look into this, thank you for the report and for looking into the issue

Excalidraw in canvas has already been reported before as not working

#265


freebsd: initialize count to 0 before procstat_getprocs()

This API will not touch *count in the error case, so we're
left with stack garbage.
Signed-off-by: Kyle Evans<EMAIL_ADDRESS>

Thanks!


sex of the organism being sequenced

New term details
Term name - sex
Structured comment name - sex
Definition - the sex of the organism sequenced
Expected value -
Value syntax - {[termID]}|{text}
Example - female
Package(s) - any

Additional context
Currently we have the term host_sex, which is misleading for any sequence that is actually of a large organism, e.g. if the sequence is a genome of a dog it would be misleading to use the term "host_sex" when there is no host. This is an issue for many of the terms when it comes to MIGS-EU checklists, afterall we are meant to be providing standards for ANY sequence, not just metagenomics.

Hi Chris,
I have much yet to learn in all this space, so please bear with me. :-)
In the MIGS-EU, there are obviously, many other entity terms prefixed by host_ , as it is an environmental checklist and as you allude to this has been much used for Metagenomics. If many of these host_* entity terms are needed in the non-prefixed form in the use case as you point out, are there plans to do detail these too?
Would you expect this use case to have its own checklist? An obvious thought is to reuse some of a relevant checklist entity terms (outwith the environmental checklists), plus adding some of the other environmental checklist relevant entity terms, then there is entity term harmonisation across the checklists.
BTW:  PATO is a well curated ontology that covers biological sex, e.g. http://purl.obolibrary.org/obo/PATO_0001894
Thanks,
Peter


[BUG] Custom Models Requires GUID to call StartRecognizeCustomFormsFromUriAsync

Library name and version
Azure.AI.FormRecognizer version 4.0.x
Describe the bug
When calling client.StartRecognizeCustomFormsFromUriAsync  I am getting an error returned advising that ModelID should be a Guid.  I am unable to track down the GUID via the Azure Portal.
If however you call the REST endpoint, https://xxxxxformrecogniserinstance.cognitiveservices.azure.com/formrecognizer/documentModels/**tmwOcrModel**:analyze?api-version=2022-06-30-preview
We are able to pass through the Model ID as a string.
Additionally if you use a predefined form, you can pass through the modelID as as string.
client.StartAnalyzeDocumentFromUriAsync("prebuilt-document", fileUri);
Expected behavior
Ability to call StartRecognizeCustomFormsFromUriAsync by passing through the ModelID as a string rather than a GUID
Actual behavior
Error thrown  System.ArgumentException: 'The modelId must be a valid GUID. Arg_ParamName_Name'
Reproduction Steps
Create Console Application
Install the Nuguet package.
using Azure;
using Azure.AI.FormRecognizer.DocumentAnalysis;
using Azure.AI.FormRecognizer;
using Azure.AI.FormRecognizer.Models;

string endpoint = "https://xxxx.cognitiveservices.azure.com/";
string apiKey = "xxxx";
var credential = new AzureKeyCredential(apiKey);
DocumentAnalysisClient client = new DocumentAnalysisClient(new Uri(endpoint), credential);

string modelId = "tmwOcrModel";

Uri formUri = new Uri("https://xxxxx.blob.core.windows.net/tmw2807blob/20220721_094536.jpg");
var options = new RecognizeCustomFormsOptions() { IncludeFieldElements = true };

var client2 = new FormRecognizerClient(new Uri(endpoint), credential);

RecognizeCustomFormsOperation operation = await client2.StartRecognizeCustomFormsFromUriAsync(modelId, formUri, options);`

Environment
Azure West Europe

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Hello @paragongithub,
The client you're trying to use, FormRecognizerClient, only supports old versions of the Form Recognizer service and, therefore, can only accept GUIDs as model IDs. If you use the DocumentAnalysisClient you showed in your snippet, it should work as expected:
using Azure;
using Azure.AI.FormRecognizer.DocumentAnalysis;

string endpoint = "https://xxxx.cognitiveservices.azure.com/";
string apiKey = "xxxx";
var credential = new AzureKeyCredential(apiKey);
DocumentAnalysisClient client = new DocumentAnalysisClient(new Uri(endpoint), credential);

string modelId = "tmwOcrModel";
Uri formUri = new Uri("https://xxxxx.blob.core.windows.net/tmw2807blob/20220721_094536.jpg");

AnalyzeDocumentOperation operation = await client.StartAnalyzeDocumentFromUriAsync(modelId, formUri);

Please let me know if that solves your problem.

Thank you for your response, I can confirm that works.


KAFKA-15129;[2/N] Remove metrics in GroupMetadataManager when shutdown

This pr is used to remove the metrics in GroupMetadataManager when shutdown.
This pr has passed the corresponding unit test, and it is part of KAFKA-15129.
A special advantage is that since the metric registered through metricsGroup is removed during shutdown, the original "recreateGauge" method (mentioned in https://github.com/apache/kafka/pull/3506#discussion_r128589927) is no longer needed.

In theory this change makes sense to me. As with the [1/N] one I would prefer if variable names start with a lowercase unless there is a good reason for them not to. I have reached out to @guozhangwang who was also wondering what the purpose of the recreateGauge method is. I thought that there is only ever one GroupMetadataManager so I do not understand the purpose of this method in the first place and I would like to get a confirmation before we remove it.

@clolov Constants (in the companion object) in Scala start with a capital letter in our code base.

Okay, that makes sense @dajac, do you happen to know (or are able to deduce) the answer to the other question about why we needed the recreateGauge method in the first place and is it safe to get rid of it now?

I was wondering if it is because we run multiple brokers in the same JVM in tests but I am not sure.

But if this is the case won't we run into the same problem for at least one other subset of metrics? Also if this is the case, that would mean that if we remove the method the tests running as part of the auto-build will start failing, no?

Found this: https://github.com/apache/kafka/pull/3506#discussion_r128589927.

Hudeqi mentioned this comment as well, but I still do not understand how this could happen - is it that we keep the same metric registry between individual unit tests? If this is the case, don't we have this problem for other groups of metrics as well?

Yeah, that seems to be a general issue with Yammer based metrics. It is not about individual unit tests. It is about integration tests that create multiple KafkaServers. In this case, the metric registry is shared by all instances:
    public final <T> Gauge<T> newGauge(String name, Gauge<T> metric, Map<String, String> tags) {
        return KafkaYammerMetrics.defaultRegistry().newGauge(metricName(name, tags), metric);
    }

That being said, it seem that newGauge here uses getOrAdd internally in the registry so it may be fine in the recent version of Yammer. It may be worth checking if this is always true (may depend on the version).

Combined with the explanation of https://github.com/apache/kafka/pull/3506#discussion_r128589927 and the results of my actual test, I think this is the case: All unit tests in GroupMetadataManagerTest involve many times of "new GroupMetadataManager" behavior , since "calls newGauge" is a global registry, it will affect the subsequent metric verification (testMetrics() method) in multiple unit tests.
I remember that I replaced "recreateGauge" directly before mentioning this PR. The unit test failed. Now because I added "removeMetrics()" to "groupMetadataManager.shutdown()"(also in@AfterEach), it will be the same as "recreateGauge" effect. @clolov @dajac

And this please @divijvaidya

Hello, please help to review this PR, we have doubts about removing the "recreateGauge" method, and the conversation here(https://github.com/apache/kafka/pull/3506#discussion_r128589927) is related to you. @cmccabe


[sf2.3] ServiceNotFoundException

Hi,
Your bundle uses an non existent service in Symfony 2.3. The stack error looks like this:
[Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]
The service "waldo_oic_rp.logout" has a dependency on a non-existent service "security.token_storage".

It seems that "security.token_storage" service comes from the Symfony 2.6 security improvements. I think the require symfony version should be update to >= 2.6 in composer.json file.

My bad,
I've updated the composer.json to fix this issue


Custom LAN

Mod name
Custom LAN
Curseforge link
https://www.curseforge.com/minecraft/mc-mods/custom-lan
Other links
https://modrinth.com/mod/custom-lan
https://github.com/DimiDimit/Custom-LAN
What it does
Minecraft Fabric mod that gives you more control over your integrated server through the Open to LAN menu.
Why should it be in the modpack
Mainly I was annoyed that online mode was on by default on LAN servers and you cannot change it.
Also, from the description:

Customize more of your integrated server (Online Mode, PvP, Port, Max Players, MOTD)
Change the settings mid-game (including the port) and stop the server without quitting the world
Change who can use cheats individually using the /op and /deop commands and cheat in singleplayer without opening to LAN (replaces the Allow Cheats button)

It also allows you to start the LAN world by pressing Enter, doesn't force the gamemode (e.g. anyone who left in Creative mode will still be in Creative when they join even if the world is set to Survival), and extends the /publish command, which can now change settings mid-game as well

Why shouldn't it be in the modpack
None to think of.
Categories
New feature
Additional details
No response

Cool idea, but I'm not so sure my target audience would actually care about any of that.

Seems niche, I don't think many people need such control on LAN (where you can literally speak to the people you're playing with)
Online mode toggle gives a bad example, FO does not support cracked players anyway
Changes some vanilla behaviours like cheats toggle


possible optimization for slice / concatenate operations over contiguous chunks

Dask's array.roll function shifts the positions of array elements along an axis, wrapping around the edge of the array. This operation is very important for many numerical calculations. It does this by slicing the array and then calling concatenate to piece it back together in the new order.
Xarray's roll method basically re-implements the same logic. In xgcm, we we also do something similar, but possibly using more complex topological connections between elements of the array than the simple periodicity assumed by roll. I am motivated to raise this issue here because of scalability challenges related to xgcm on very large datasets.
I think there is an opportunity for optimization of these operations in the special case where the roll occurs over a contiguous chunk. (In practice, this is often the case.) Consider the following example.
import numpy as np
import dask.array as dsa

nt = 2
nx = 500
data = dsa.random.random(size=(nt, nx), chunks=(1, nx))
dsa.roll(data, 1, axis=-1).visualize()

It is instructive to re-implement our own roll function the way dask does it to see that it works the same:
def roll_with_dask(array, split_point):
    left = array[..., :split_point]
    right = array[..., split_point:]
    return dsa.concatenate([right, left], axis=-1)
roll_with_dask(data, 1).visualize()

Now I implement the same function in numpy and apply it with map blocks:
def roll_with_numpy(array, split_point):
    left = array[..., :split_point]
    right = array[..., split_point:]
    return np.concatenate([right, left], axis=-1)
data.map_blocks(roll_with_numpy, 1).visualize()

These two give the same answer:
np.testing.assert_allclose(
    data.map_blocks(roll_with_numpy, 1),
    roll_with_dask(data, 1)
)

But the map_blocks version has fewer chunks and consequently is much more efficient. Furthermore, no rechunking is required down the line if we want to combine this rolled array with other non-rolled array (e.g. when taking a finite difference). These things make a big difference when working with very large arrays.
To generalize this example, it seems that all slice and concat operations over contiguous chunks should be able to be accomplished at the numpy level. Is this something that could conceivably be detected at the optimization stage and in-lined?

IIUC we want roll to not split a chunk if that chunk fills the axis being rolled, but instead we want it to perform the roll operation within the chunks to keep the chunks intact? If so, that sounds reasonable. Any interest in doing a PR?

IIUC we want roll to not split a chunk if that chunk fills the axis being rolled, but instead we want it to perform the roll operation within the chunks to keep the chunks intact? If so, that sounds reasonable. Any interest in doing a PR?

Yes this is what I meant. But I was suggesting something more ambitious that just modifying roll; I am suggesting to automatically detect such cases where the operations all occur on contiguous chunks and then fusing them into a single task. I recognize this may be too vague and complex to be actionable.
Updating roll will not help xarray or xgcm, which instead implement their own slightly different but fundamentally similar versions of roll. But automatic fusing of such operations would.

Using map_blocks when we roll over single-chunked dimensions cdwould be a welcome change.
If you're looking for fusion then you probably want to set dask.config.set(fuse_ave_width=5) or something similar.


A304 conflicts with flexible mesh conventions

UGRID conformance rule A304 states that no connectivity ending in _node_connectivity should have a _FillValue.
UGRID's 2D flexible mesh topology depends on using _FillValue for elements that connect to fewer than the maximum number of nodes.

#36 fixes this
N.B. also, the relevant new commit to the UGRID repo updates the conformance page (still in unmerged PR),
so those changes appear in the preliminary RTD pages latest build


Improvement suggestions

[x] Update README to mention that they can simply add LOGSNAG_API_TOKEN environment in .env instead of setting in nuxt.config
[x] Is the API token for log snag public? 🤔
[x] Is it necessary? https://github.com/Intevel/nuxt-logsnag/blob/master/src/runtime/plugin.ts#L4
[x] I would rename it to publish on https://github.com/Intevel/nuxt-logsnag/blob/master/src/runtime/composables/useLogSnag.ts#L26, like the npm module: https://www.npmjs.com/package/logsnag
[x] Rename #app to #imports on https://github.com/Intevel/nuxt-logsnag/blob/master/src/runtime/composables/useLogSnag.ts#L2

Hey @Atinux, thanks.
Improved your suggestions in the newest release. 💚


update tooling versions

upgrade Concourse to 7.11.2
upgrade Postgres to 14.11
upgrade Vault to 1.13.1

basically the same as we have in the CI

some minor cleanup

Thanks!


⚠ SceneTime has degraded performance

In 33a4b62, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 1610 ms

Resolved: SceneTime performance has improved in 7371d44 after 6 minutes.


MSID: 94616 Version: 2 DOI: 10.1101/2<IP_ADDRESS>6992

MSID: 94616
Version: 2
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>6992
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=94616
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>6992

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/94616v2
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>6992
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/94616/v2/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!


[Pairing Reliability] #1 Failure: Commission failed with src/app/ClusterStateCache.cpp:303: CHIP Error 0x00000010: Key not found

Description:
I have used python controller to run a stress test on my RPI sample dut (all-clusters-app) on Pair-Unpair test scenario for 10,000 iterations. The test passed in iteration 2763 without any error but the iteration 2764 is Failed to read the info such BasicCommissioningInfo, RegulatoryConfig , LocationCapability, Breadcrumb during commission the dut with the below error

2024-04-26 05:40:48,629 - chip.native.CTL - ERROR - init.py:_RedirectToPythonLogging:38 - Failed to read BasicCommissioningInfo: src/app/ClusterStateCache.cpp:303: CHIP Error 0x00000010: Key not found
2024-04-26 05:40:48,630 - chip.native.CTL - ERROR - init.py:_RedirectToPythonLogging:38 - Failed to read RegulatoryConfig: src/app/ClusterStateCache.cpp:303: CHIP Error 0x00000010: Key not found
2024-04-26 05:40:48,630 - chip.native.CTL - ERROR - init.py:_RedirectToPythonLogging:38 - Failed to read LocationCapability: src/app/ClusterStateCache.cpp:303: CHIP Error 0x00000010: Key not found
2024-04-26 05:40:48,630 - chip.native.CTL - ERROR - init.py:_RedirectToPythonLogging:38 - Failed to read Breadcrumb: src/app/ClusterStateCache.cpp:303: CHIP Error 0x00000010: Key not found
2024-04-26 05:40:48,631 - chip.native.CTL - ERROR - init.py:_RedirectToPythonLogging:38 - Error parsing commissioning information
2024-04-26 05:40:48,631 - chip.native.CTL - ERROR - init.py:_RedirectToPythonLogging:38 - Error on commissioning step 'ReadCommissioningInfo2': 'src/app/ClusterStateCache.cpp:303: CHIP Error 0x00000010: Key not found'

GitHub hash of the SDK that was being used: https://github.com/project-chip/connectedhomeip/commit/3718e996b56f36a553c1b4571f77728396590776
Platform
controller - python controller running on raspi,
DUT - all-cluster-app running on raspi
Provisioned using on-network
Platform Version(s)
RPI-4, 8GB RAM
Test Scenario
Pair/Provision the DUT (All-cluster-app running on raspi) using on-network
Read device information after the device is provisioned
sleep for 2 secs
Unpair the DUT (i.e. removing the fabric)
factory reset the DUT
repeat step1 - 6 for 10,000 iterations
Script reference: https://github.com/CHIP-Specifications/matter-qa/blob/main/src/matter_qa/scripts/reliability_scripts/TC_Pair.py
Reference log:
Example of Passed iteration details:
The iteration number 2763 is passed, below log files for the same
TH log: log_2024-04-26_05-36-23.log
DUT log: Dut_log_2763_2024-04-26T05_36_32_752483.log
Example of Failed iteration details:
The iteration number 2764 is failed with this error below the logfile
TH log : log_2024-04-26_05-36-46.log
DUT log: Dut_log_2764_2024-04-26T05_40_57_865104.log
For the detailed summary please reference this json: summary.json

The "Key not found" thing is a bit of a red herring.  The actual failure is here, from the TH log:
2024-04-26 05:40:18,613 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - <<< [E:59991i S:60974 M:30600750] (S) Msg TX to 0:FFFFFFFB00000000 [0000] [UDP:[fe80::dea6:32ff:feab:25e4%en0]:5540] --- Type 0001:02 (IM:ReadRequest)
...
2024-04-26 05:40:18,621 - chip.native.DMG - ERROR - __init__.py:_RedirectToPythonLogging:38 - Time out! failed to receive report data from Exchange: 59991i

2024-04-26 05:40:18,628 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - <<< [E:59992i S:60974 M:30600751] (S) Msg TX to 0:FFFFFFFB00000000 [0000] [UDP:[fe80::dea6:32ff:feab:25e4%en0]:5540] --- Type 0001:02 (IM:ReadRequest)
...
2024-04-26 05:40:19,177 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600750 on exchange 59991i Send Cnt 1
2024-04-26 05:40:19,265 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600751 on exchange 59992i Send Cnt 1
2024-04-26 05:40:19,840 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600750 on exchange 59991i Send Cnt 2
2024-04-26 05:40:19,882 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600751 on exchange 59992i Send Cnt 2
2024-04-26 05:40:20,765 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600750 on exchange 59991i Send Cnt 3
2024-04-26 05:40:20,925 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600751 on exchange 59992i Send Cnt 3
2024-04-26 05:40:22,339 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600750 on exchange 59991i Send Cnt 4
2024-04-26 05:40:22,415 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - Retransmitting MessageCounter:30600751 on exchange 59992i Send Cnt 4
2024-04-26 05:40:24,725 - chip.native.EM - ERROR - __init__.py:_RedirectToPythonLogging:38 - Failed to Send CHIP MessageCounter:30600750 on exchange 59991i sendCount: 4 max retries: 4
2024-04-26 05:40:24,784 - chip.native.EM - ERROR - __init__.py:_RedirectToPythonLogging:38 - Failed to Send CHIP MessageCounter:30600751 on exchange 59992i sendCount: 4 max retries: 4
2024-04-26 05:40:48,625 - chip.native.DMG - ERROR - __init__.py:_RedirectToPythonLogging:38 - Time out! failed to receive report data from Exchange: 59992i

So our reads timed out and things failed.  I am not 100% sure why the read on exchange 59991i timed out so quickly, by the way; that's a bit odd.
Looking at the other side, at the DUT log, we have:
[1714135007.042325][500980:500980] CHIP:EM: >>> [E:59990r S:0 M:183265092 (Ack:84098056)] (U) Msg RX from 0:6949780F7315A42B [0000] --- Type 0000:24 (SecureChannel:PASE_Pake3)
[1714135007.042690][500980:500980] CHIP:EM: <<< [E:59990r S:0 M:84098057 (Ack:183265092)] (U) Msg TX to 0:0000000000000000 [0000] [UDP:[fe80::f:2352:63b5:7bd%eth0]:63338] --- Type 0000:40 (SecureChannel:StatusReport)
...
[1714135007.043119][500980:500980] CHIP:IN: New secure session activated for device <FFFFFFFB00000000, 0>, LSID:37850 PSID:60974!
...
[1714135007.385579][500980:500980] CHIP:EM: Retransmitting MessageCounter:84098057 on exchange 59990r Send Cnt 1
[1714135007.742411][500980:500980] CHIP:EM: Retransmitting MessageCounter:84098057 on exchange 59990r Send Cnt 2
[1714135008.334451][500980:500980] CHIP:EM: Retransmitting MessageCounter:84098057 on exchange 59990r Send Cnt 3
[1714135009.307984][500980:500980] CHIP:EM: Retransmitting MessageCounter:84098057 on exchange 59990r Send Cnt 4
[1714135010.769943][500980:500980] CHIP:EM: Failed to Send CHIP MessageCounter:84098057 on exchange 59990r sendCount: 4 max retries: 4
[1714135067.101502][500980:500980] CHIP:FS: Fail-safe timer expired
...
[1714135218.736037][500980:500980] CHIP:EM: >>> [E:59990r S:0 M:183265093 (Ack:84098057)] (U) Msg RX from 0:6949780F7315A42B [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
[1714135218.742592][500980:500980] CHIP:IN: Data received on an unknown session (LSID=37850). Dropping it!

OK, so we established PASE, then we waited 60s on the DUT, then the fail-safe expired, then another 151 seconds later (!) we started getting packets on our PASE session, as well as an ack for the StatusReport we had sent a long time before.  What happened during those 200-plus seconds?
Well, going back to the TH log we have:
2024-04-26 05:36:46,946 - chip.native.CTL - INFO - __init__.py:_RedirectToPythonLogging:40 - Sending read request for commissioning information
2024-04-26 05:36:46,946 - chip.native.DMG - DEBUG - __init__.py:_RedirectToPythonLogging:42 - SendReadRequest ReadClient[0x299d109f0]: Sending Read Request
...
2024-04-26 05:36:46,948 - chip.native.ATM - INFO - __init__.py:_RedirectToPythonLogging:40 - 					"Anonymous<4>" :
2024-04-26 05:40:18,601 - chip.native.ATM - INFO - __init__.py:_RedirectToPythonLogging:40 - 					{
...
2024-04-26 05:40:18,613 - chip.native.EM - INFO - __init__.py:_RedirectToPythonLogging:40 - <<< [E:59991i S:60974 M:30600750] (S) Msg TX to 0:FFFFFFFB00000000 [0000] [UDP:[fe80::dea6:32ff:feab:25e4%en0]:5540] --- Type 0001:02 (IM:ReadRequest)

Note the two consecutive tracing log lines that claim timestamps that are 304s apart.
So as far as I can tell at least from the data here, the process running on the TH "just" lost the timeslice for 5 minutes or so, if the timestamps are not lying to us.  This seems like an odd thing to have happen.  If it's running on a laptop, I would guess "laptop went to sleep and then got woken up".  That doesn't seem like something a raspi would do, though....

@cjandhyala can you please look into what's going on with the TH here?

That doesn't seem like something a raspi would do, though....

Yeah, so.  Issue says "controller - python controller running on raspi," but the TH log says:
2024-04-26 05:36:46,897 - chip.native.DIS - ERROR - __init__.py:_RedirectToPythonLogging:38 - Mdns: Browse failure (src/platform/Darwin/DnssdImpl.cpp:412: CHIP Error 0x00000074: The operation has been cancelled)

so this is probably not so much a raspi.  And if it's an actual laptop, then who knows what it did in terms of sleep.


Update rimraf dependency

Rimraf uses an outdated glob version. This PR fixes that.
Note that this marks mv as not supported for Node.js < 20, which means that it only supports currently supported Node.js versions.
@andrewrk I see you are busy doing zig and this project still uses travis. If you're open for it, I'd volunteer moving it to GH Actions in a separate PR (maybe to even merge it before this one, so we can have a working CI again).

What's the benefit of using glob v6 vs v2, when it forces a breaking change?

Installing mv yields 3 deprecation warnings:
$ npm i mv
npm warn deprecated<EMAIL_ADDRESS>This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated<EMAIL_ADDRESS>Rimraf versions prior to v4 are no longer supported
npm warn deprecated<EMAIL_ADDRESS>Glob versions prior to v9 are no longer supported

$ npm ls inflight
a@ /tmp/a
└─┬<EMAIL_ADDRESS>  └─┬<EMAIL_ADDRESS>    └─┬<EMAIL_ADDRESS>      └──<EMAIL_ADDRESS>
I'm converting this to a draft, so we can make sure the change is minimal.

Transitive deprecation warnings should be ignored anyways, and npm has an approved RFC to start hiding them. If that’s the only benefit then I’m not sure it’s worth the cost.

Is there an option to ignore transitive dependency warnings? I know that they don't mean much. This is why resolving them removes noise from the stuff that actually matters in current npm.
I am assuming this is the RFC:
https://github.com/npm/rfcs/blob/main/accepted/0044-deprecation-ux-revamp.md
The RFC doesn't give any status, but it seems that it will be fixed eventually.

I’m not sure it’s worth the cost

Just to be clear: The cost is creating a new major version that supports the current supported node version (in contrast to 0.x with no actual tests on the current versions, as it currently does) while keeping the same API.


ner_model(['Bob Ross lived in Florida']) is giving error

raise type(e)(node_def, op, message)
InvalidArgumentError: Requested more than 0 entries, but params is empty.  Params shape: [1,7,0]

Hi!
Can you show us how you initialized ner_model and a full stack trace?


[WIP] Add a Contributing Guide

This PR:

adds instructions showing how to contribute to the project.

:information_desk_person: As part of the overhaul of the documentation, I want to make it as easy as possible for others to know how to contribute to the project.

@shochdoerfer, this is still a work-in-progress, as there's a bit of extra information still required. But should be finished relatively quickly.

Good starting point! For the ci tasks we have some phing tasks which you should refer to in the documentation:

To run CodeSniffer use: ./vendor/bin/phing sniff
To run PHPUnit use: ./vendor/bin/phing unit
To lint the PHP code use: ./vendor/bin/phing lint

Before sending a PR one should run composer.phar validate as the Travis build will also run the command and will fail if the composer.lock file is not up-to-date with the changes in the composer.json file.

Ok, the initial draft's now done and it's ready for review.

@settermjd Could you apply the few changes I mentioned above so that I can merge the PR?

@shochdoerfer done!

Thank you @settermjd for your first Disco PR!

Not a problem at all. Here's to many more!


AnyHashable tests for Foundation types: add tests for bridging back to Swift types + fixes that make tests pass

Add another batch of tests for AnyHashable.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci Please test and merge

Why is this not using a smoke test? Is a full test necessary?

If I new this would pass the tests, I would not need to run them.

These tests used to pass, but now master moved forward, and fixes by @jckarter are needed.  Included them in this PR.

@swift-ci Please test and merge

@swift-ci Please test and merge

@swift-ci Please test

@swift-ci Please smoke test and merge

OS X tests passed, Linux tests failed because of infrastructure reasons.
@swift-ci Please test Linux platform

OS X tests and Linux tests passed, merging.


groupStart() refactorization

Description
Since we have now groupStart() and havingGroupStart() it's a good moment to refactor the code responsible for those methods a bit.
In this PR I want to introduce two new protected methods: groupStartPrepare() and groupEndPrepare(). These will take over the responsibility for handling all other group* methods.
Checklist:

[x] Securely signed commits
[x] Component(s) with PHPdocs
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

It even looks like the user guide doesn't need updating ... groupStart() there doesn't show parameters :-/
Are you planning unit tests for this?
I don't see this PR as urgent as 2269, as there doesn't appear to be any BC here. Is that right?

I like this. As long as we have existing tests in place for the groups then this should be good and doesn't need any additional tests.

The parameters for groupStart() were marked in code as "internal use only" so we should be good - no BC changes.
We have tests for existing group methods and I think it should be enough.


Cri-Containerd and IPv6

Hi,
I have tried to deploy a IPv6-only cluster using cri-containerd, but I was not able to make it work,
It work at glances using Docker but I really would like to migrate that to cri-containerd.
Here is the log that get droped :
 failed to get IP addresses for \"eth0\": <nil>"

I have no more investigations to find what happend ...
Any idea ?

@valentin2105 What CNI network plugin are you using? Actually cri-containerd only creates the network namespace. And actual network setting is handled by cni plugins.

I see. The issue is in ocicni. https://github.com/cri-o/ocicni/blob/master/pkg/ocicni/ocicni.go#L345
It only tries to get -4 ipv4 address.
However, cni in Kubernetes also tries -6 https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/network/plugins.go#L290.

@valentin2105 I sent out a fix in https://github.com/cri-o/ocicni/pull/16. And will update vendor after it is merged.

@Random-Liu  I use Calico as CNI provider who work well using Docker.
I have tried the latest release of cri-containerd (cri-containerd v1.0.0-beta.1 release)
Thanks for your work, really looking forward put these dope in production !
As I understanded Cri-o doesn't support IPv6 too ? (because you send the link from cri-o)
Thanks !

As I understanded Cri-o doesn't support IPv6 too ? (because you send the link from cri-o)

@valentin2105 We all use that package. And yeah, I think so.

Thanks for your support, I will try that soon ;)

@valentin2105 BTW, we disabled the IPv6 DAD by default because it slows down pod creation a lot. You may want to enable it if you need it --enable-ipv6-dad.

Great !!


Add corpus of crates to rustfmt's CI

rustfmt upgrades break stdsimd too often. Skimming through this repo I cannot find integration tests in which rustfmt reformats already existing crates and check that they still compile and pass tests afterwards.
I think rustfmt should at least do this for some of the nursery crates:

[x] rustfmt itself: this seems obvious, but if after reformatting itself rustfmt fails to compile then it should definitely not be shipped to users
[ ] stdsimd
[ ] futures-rs
[ ] rand
[ ] chalk
[ ] failure
[ ] crater
[ ] glob
[ ] cargo
[ ] clippy
[ ] error-chain
[ ] mdbooks
[ ] tempdir
[ ] bitflags
[ ] rust-semverver
[ ] log

That should provide a large enough corpus to check that rustfmt does indeed work properly.

We already do Rustfmt - in fact we have the stronger constraint that it must be char-for-char the same before and after formatting. Doing some of the other crates is definitely a good idea.

This would be a pretty big first issue, but it doesn't require knowledge of Rustfmt's internals, so it would be a good issue to work on.


Shutdown timeout cleaner as far as possible

Why are the changes needed?

If some ExecuteStatement are canceled before timeout in a short time, the timeout cleaners will hold the resource until timeout.
This PR aims to release the timeout cleaner as far as possible.
How was this patch tested?
Pass org.apache.kyuubi.engine.spark.SparkEngineSuites

Codecov Report

Merging #735 (0297ba4) into master (164bd03) will decrease coverage by 0.20%.
The diff coverage is 100.00%.

:exclamation: Current head 0297ba4 differs from pull request most recent head 92bc29a. Consider uploading reports for the commit 92bc29a to get more accurate results

@@            Coverage Diff             @@
##           master     #735      +/-   ##
==========================================
- Coverage   80.70%   80.50%   -0.21%
==========================================
  Files         122      122
  Lines        4748     4749       +1
  Branches      576      576
==========================================
- Hits         3832     3823       -9
- Misses        594      605      +11
+ Partials      322      321       -1

Impacted Files
Coverage Δ

...uubi/engine/spark/operation/ExecuteStatement.scala
86.15% <100.00%> (+0.21%)
:arrow_up:

...kyuubi/engine/spark/operation/SparkOperation.scala
70.14% <0.00%> (-7.47%)
:arrow_down:

...c/main/scala/org/apache/kyuubi/schema/RowSet.scala
84.35% <0.00%> (-3.41%)
:arrow_down:

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 164bd03...92bc29a. Read the comment docs.


Fixed #27906 -- Fixed count of subset of children in test.html.count().

ticket-27906

Thanks for the review!

Improved comments throughout
moved my new if branch below the existing code
added a comment over the old code to clarify the difference
moved all tests to test_count()
added a test for no match found
added a test for a match found as both child and grandchild that would fail if someone turns my if branch to elif


'React/RCTViewManager.h' file not found

Hi,
I cloned the repo and tried to run the example but the build fails on xcode with this error:
'React/RCTViewManager.h' file not found
Can you please help?

@pjustino are you using Pods for React?
I started using RN 0.60.5. wasn't able to add react-native-3d-model-view via pods, so linked manually. had same issue. needed to:

go to RCT3DModel project
build settings
in Header Search Paths add $(SRCROOT)/../../../ios/Pods/Headers/Public

since my React headers are coming from Pods

I also face that issue. adding the header paths didnt solve it. Is there another solution?


4.10.0 badly tagged ? (still scrollbar issues, but on chrome OSX)

Hey Marijnh, it seem like the scrollbar fix : https://github.com/codemirror/CodeMirror/commit/198d00f80882e80e0f5cd4f4dff1249541e36ed8 for  https://github.com/codemirror/CodeMirror/issues/3009
Did not make it to the tagged version: https://github.com/codemirror/CodeMirror/blob/4.10.0/lib/codemirror.js#L778-L783
(still named plus gap instead of total)
Which make 4.10 still have the scrollbar issue in some cases eg: https://github.com/ipython/ipython/issues/7395
Any chance to have a 4.10.1 ?
Thanks !

Yes, I found a few more problems after tagging 4.10, but wasn't sure whether they'd be major enough to warrant yet another tagged release. I guess they were. I pushed 4.11.0.

I guess it was a bad start for 2015... Thanks a lot, should have reviewed beta more carefully.


changelog and cleanup

PR Summary
It's getting a little tough to keep track of all changes that go into the code. This adds a changelog, based on the way we do things in Parthenon. I also cleaned up the docs and READMEs a little while I was at it.

PR Checklist

[x] Adds a test for any bugs fixed. Adds tests for new features.
[x] Format your changes by using the make format command after configuring with cmake.
[x] Document any new features, update documentation for changes made.
[x] Make sure the copyright notice on any files you modified is up to date.
[x] After creating a pull request, note it in the CHANGELOG.md file

Looks good to me


Tracking bootstrapping.conf and package.conf.d directories

@kgardas reports the following, https://github.com/snowleopard/shaking-up-ghc/issues/174#issuecomment-172203788:

I usually hit following error when rm -rf .build inplace and when starting build without -B option:

user error (Development.Shake.cmd, system command failed
Command: /opt/ghc-7.10.1-i386/bin/ghc -hisuf hi -osuf o -hcsuf hc -static -no-user-package-db -package-db /tmp/shake-test/.build/stage0/bootstrapping.conf -i -i.build/stage0/utils/hp2ps/build -i.build/stage0/utils/hp2ps/build/autogen -I.build/stage0/utils/hp2ps/build -I.build/stage0/utils/hp2ps/build/autogen -odir .build/stage0/utils/hp2ps/build -hidir .build/stage0/utils/hp2ps/build -stubdir .build/stage0/utils/hp2ps/build -rtsopts -H32m -O -no-auto-link-packages -optl-lm -optl-lgmp .build/stage0/utils/hp2ps/build/AreaBelow.o .build/stage0/utils/hp2ps/build/Curves.o .build/stage0/utils/hp2ps/build/Error.o .build/stage0/utils/hp2ps/build/Main.o .build/stage0/utils/hp2ps/build/Reorder.o .build/stage0/utils/hp2ps/build/TopTwenty.o .build/stage0/utils/hp2ps/build/AuxFile.o .build/stage0/utils/hp2ps/build/Deviation.o .build/stage0/utils/hp2ps/build/HpFile.o .build/stage0/utils/hp2ps/build/Marks.o .build/stage0/utils/hp2ps/build/Scale.o .build/stage0/utils/hp2ps/build/TraceElement.o .build/stage0/utils/hp2ps/build/Axes.o .build/stage0/utils/hp2ps/build/Dimensions.o .build/stage0/utils/hp2ps/build/Key.o .build/stage0/utils/hp2ps/build/PsFile.o .build/stage0/utils/hp2ps/build/Shade.o .build/stage0/utils/hp2ps/build/Utilities.o -o inplace/bin/hp2ps -no-hs-main
Exit code: 1
Stderr:
ghc: can't find a package database at /tmp/shake-test/.build/stage0/bootstrapping.conf
)

this is very reproducible. Perhaps also pointing to a need to have proper shake clean way...
The problem is: at the moment we don't track bootstrapping.conf and package.conf.d directories in a correct way. The wrong solution, which is currently in place, is to use files package-configuration-initialised-stageN stored in Shake's database as indicators of whether the directories have been initialised by ghc-pkg init. In this way if one deletes one of these directories, but doesn't delete the corresponding indicator file, the build system gets confused.
It would be great if Shake supported need on a directory and corresponding build rules. However, as I understand this is currently not supported. @ndmitchell Any comments on this? Having first class support for directory targets may be useful I think.
One possible solution: Move the indicator files into the directories they track. This might work, although not sure it's completely reliable.
Note, we can't track this using doesDirectoryExist as this would lead to a Shake's lint error. We also can't track any existing files inside the directories, because the only file which is created together with the directory (package.cache) is updated multiple times during the build by ghc-pkg, which would also lead to a Shake's lint error.

I've implemented the only solution I can see: moved the indicator files into the directories they track. I'll keep this open for a while, maybe someone will come up with a better approach.

What would need on a directory do? I can't think of any semantics beyond need =<< getDirectoryFiles dir ["**"]. And that's not going to help you anyway.

Here is what I would like to do: If the directory does not exist, run the build rule that will create it.
Here is what my workaround does: If the indicator file in the directory does not exist or is not fresh, run the build rule that will create both the directory and the indicator file.
(Note, the freshness check is redundant as the timestamp & contents of the indicator file are irrelevant.)
Maybe calling this need is wrong, because no freshness check should be involved.
@ndmitchell Do you see any problem with my workaround? Would you solve this problem differently?

Stamps inside the directory seems a very good way to go. You aren't really needing the directory, you need a file inside it. You could track the creation of the file with a special type of rule that does not look at timestamp, but that's way too much hassle.

In fact, an oracle which creates if necessary and returns () perfectly captures the dependency and is fully robust.

Aha, sounds good. Something like this?
addOracle $ \PackageDb dir -> unlessM (doesDirectoryExist dir) $ createPackageDb dir

initialisePackageDb :: Stage -> Action ()
initialisePackageDb stage = askOracle . PackageDb $ packageDb stage

Use doesDirectoryExist in IO not Action to avoid the lint failure. Probably use doesFileExist on the .cache file for more robustness if someone just deletes the file.

M-m, I'm a bit confused now. Since this always runs and never invalidates the build, then why use oracles? I guess the following Action will do:
initialisePackageDb :: Stage -> Action ()
initialisePackageDb stage = unlessM (liftIO $ IO.doesDirectoryExist dir) $ createPackageDb dir
  where
    dir = packageDb stage

That action does one directory check every time (probably not actually expensive in practice) and might have a race - if you use a db while being created (not sure if the db rules).

Aha, so the difference is: the oracle action will run every build but only once, while the non-oracle action will run every time it is called, in particular the file/directory check will be done each time.
For me that's a good enough reason to prefer the oracle solution.

Fix delayed as I came across a nasty import cycle:

Action.Rules.build requires getArgs from Settings.Args to determine the list of arguments to pass to the builder.
getArgs is computed by collecting arguments for all builders, in particular ghcCabalBuilderArgs living in Settings.Builders.GhcCabal.
ghcCabalBuilderArgs needs to call the PackageDb oracles that in turn relies on Action.Rules.build for running GhcPkg builder (to initialise the package database).

Not sure how to get rid of the cycle.

OK, I managed to break the cycle. An oracle-based fix is now submitted.


Caching

Should be able to cache

Could you please provide more details as to why your request is different from #411 and #412?


compatible with R version 3.4.4 (2018-03-15)?

Hello, thanks for you nice and useful work!
I have installed R  version 3.4.4 (2018-03-15) on Ubuntu 16.04.5 LTS. I have installed your class trough composer and upgrade it to the dev-master version.
I then run a basic php script:
`ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
require 'vendor/autoload.php';
use Kachkaev\PHPR\RCore;
use Kachkaev\PHPR\Engine\CommandLineREngine;
$args = array();
$args['pathToErrorFile'] = '/home/marco/logs/errors.txt';
$prog = new CommandLineREngine('/usr/bin/R', $args);
$r = new RCore($prog);
echo $r->run('exp(1)');`
but the page enter in a infinite loop when I try to make the run function. no log file is created.
I have also tried to run the following code with the same result:
$rProcess = $r->createInteractiveProcess(); $rProcess->start(); $rProcess->write('x = 100'); $rProcess->write('x * x'); echo $rProcess->getAllResult();
if I run R as apache (sudo -u www-data /usr/bin/R) I am able to run correctly all the comands on R
thank-you
Marco

Hi @marco86to, sorry to hear this! I believe that the issue is to do with I/O between PHP and R and unfortunately I don't know how to fix it. A similar problem was reported recently by @dipenpatel235 in https://github.com/kachkaev/php-r/issues/41.
Could you please help me with investigating? I'll be happy to accept a PR with the fix!

Hi @kachkaev,  thanks for your fast reply. I have done some tests and just comment the following while circle on https://github.com/kachkaev/php-r/blob/master/src/Kachkaev/PHPR/Process/CommandLineRProcess.php:
// Skip the startup message (if any)         do {             $out = fread($this->pipes[1], $this->infiniteLength);             usleep($this->sleepTimeBetweenReads);         } while ($out !== '> ' && substr($out, -3) !== "\n> ");
if I comment that everything is working well
thanks
Marco


feat(docs): contribute site for documentation

This gets all the documentation available on our contribute site. Eventually we will add guides for contributing to all platforms be it translations, adding subtitles, or moderating forums.

Things that can be handled eventually:

[ ] Cleanup the CSS that I have shamelessly copied over from Netflix's project.
[ ] Fix routing to the i18n versions of the docs.