Memory leak

Frankenphp seems to be leaking memory (at least in my specific configuration). I first noticed it when benchmarking it. It would staircase to heaven with each request passing through it, eventually getting killed by OOM killer. Just now I noticed that its memory usage keeps growing while idle as well (well, almost idle; it still handles healthchecks). Below you'll find a screenshot showing an idle frankenphp pod growing both in memory usage and CPU usage while receiving 1 request every 5 seconds from an ELB. Whatever is leaking is also adding on the CPU workload.
Screenshot:
https://imgur.com/a/a6wbI2A
Setup:

custom docker image built from the official one
arm64
worker mode (I think only worker mode exhibits this behavior, but I haven't really checked)
FrankenPHP v1.0.0 PHP 8.3.0 Caddy v2.7.5 h1:HoysvZkLcN2xJExEepaFHK92Qgs7xAiCFydN5x5Hs6Q=
Symfony app (api platform) w/ frankenphp-runtime (a fork, actually)

[PHP Modules]
amqp
apcu
bcmath
calendar
Core
ctype
curl
date
dom
exif
FFI
fileinfo
filter
ftp
gd
gettext
hash
iconv
imagick
intl
json
ldap
libxml
mbstring
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
random
readline
redis
Reflection
session
SimpleXML
soap
sockets
sodium
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zlib

[Zend Modules]
Zend OPcache

Let me know how can I help to get to the bottom of this. I'm not really familiar with the development tools involved in golang/caddy/frankenphp, but I'm a quick learner.

Thanks for the report. May it be a duplicate of https://github.com/dunglas/frankenphp/issues/280?
Could you try without the worker mode?
Could you also try to check where is the memory leak by following the steps described in the issue mentioned above?
It would help a lot to understand what's going on.
Thank you.

when reaching the configured limit (1 GB).

1 GB is too low a limit with the default GC settings of Go (Go is designed for running on servers, which usually have gobs of memory, fast networks, etc.). I usually see ~3-5 GB of usage before GC starts to kick in with the default settings. You may need to tune Go's GC for such low memory allocations using the GOMEMLIMIT environment variable.
Give that a try and see if it does any better.
See: https://tip.golang.org/doc/gc-guide#Memory_limit

Thanks for the tip! This may mean we need a performance tuning guide.
Running in k8s, I'd rather have a lot of smaller pods instead of few huge pods. There's also the issue of staging environment (where I'm currently testing in) where I'd want to use as few resources as possible.
I've read most of the linked documentation. I'm going to keep the hard 1GiB limit on the container, set GOMEMLIMIT to 1GiB as well and set GOGC to 70%. As I understand it, when usage hits GOGC (=70%), it runs the GC.
Another thing that I gleaned from the doc is that Go's GC is aware of all the memory usage (that includes Cgo/php), but obviously can't do anything about it. So, when I set the memory limit to 1 GiB, that limit will also include whatever php is using, which is exactly what I would want/expect (e.g: when php starts hogging memory, Go should try to free its own, to respect the limit). Can you guys confirm this is correct?
... a while later...
I've ran some stress testing... Setting the memory limit to 1GiB didn't seem to have an (obvious) impact, so I lowered it to 512MiB. The memory usage still grew, but at ~384MiB (70%*512) it would start growing slower, thanks to the GC. I disabled the worker mode and it still grew. A lot slower, but it did. I noticed at some point the CPU throttling in effect, correlated with hitting the 384 MB point (GC in full swing, eating precious CPU cycles from the workload). And then some very odd stuff happend. The pods kinda froze, stopped processing requests (timeout). They were running and the memory usage would grow, but no responses. I tried redeploying and the new pods (while the older ones were still active) were not starting up with an error "PHP Fatal Error: Could not create timer" (something like that; I'm sorry, I didn't copy the exact message).
I'll need to take a break now. I'll get back to it later today, trying to capture the profiles using the same methodology as yesterday so that we can compare them. Speaking of pprof, I don't need to run pprof twice, do I? I was running it once for heap and second for allocs but I have a feeling the exports are actually the same.

Running in k8s, I'd rather have a lot of smaller pods instead of few huge pods.

A little off-topic, but generally the only things (IRL) running out there with that little memory are IoT devices, most machines these days have at least 4GB of memory (I don't even think you can buy a 1GB stick of RAM anymore).
Remember that software is built and optimized on developer machines, that usually have at least 4GB of memory on them. Go's philosophy tends to be: memory is cheap, CPU is not (adding more memory is a simple hardware swap in physical machines, up to a limit, while a new CPU tends to also require swapping an entire mainboard as well).
Back on topic, you'll need to leave enough memory for PHP to operate as well (maximum number of workers + baseline worker memory + per-request memory). It appears you might be "deadlocking" due to Go being unable to give up more memory due to PHP hogging memory.
I have a test-harness that allows running your code in worker mode via frankenphp-cli to test for memory leaks and send it fake requests. I'll clean it up tonight and make it public. I use it to hunt down memory leaks in my app and provide some metrics/suggestions (baseline worker memory, optimum number of workers, per-request memory) to provide some tuning variables.

A little off-topic, but generally the only things (IRL) running out there with that little memory are IoT devices, most machines these days have at least 4GB of memory (I don't even think you can buy a 1GB stick of RAM anymore).

To continue this off-topic point (that intrigues me for personal reasons), a Raspberry Pi Zero 2 W would be a low end target and has 512MB total memory.  I'm not sure that a production server targeted project should aim quite that low, but it is a bottom end to consider.  I suspect it is probably below a reasonable threshold and 4GB is likely the next "category" step up.

A little off-topic, but generally the only things (IRL) running out there with that little memory are IoT devices, most machines these days have at least 4GB of memory (I don't even think you can buy a 1GB stick of RAM anymore).

To add we are all no running on bare hardware, in a containerized environment 4GB can be a pretty large container for smaller services.
Perhaps I misread and you are specifically directing this at development environments and not production.  Your comment kind of states this but not clearly as I read it.

Ok, cleaned it up and put the script here. Basically, it's a self-contained PHP file that can be copied into a running container (such as a production one) to measure some basic things.

Perhaps I misread and you are specifically directing this at development environments and not production. Your comment kind of states this but not clearly as I read it.

Sorry, I get annoyed at Go sometimes. I was ranting a bit. It's a good language, but some of the very low-level defaults are ... interesting.
Anyway, using that small bit of code can possibly help you narrow down if your code is leaking memory (I usually run it once for 100 requests, then again for 1000. If it isn't leaking memory then the numbers should come out almost -- if not exactly -- the same).

I'm happy to see such a lively debate and, before I go any further, I'd like to thank you all for your input and @withinboredom for the nice script. I've only read it, didn't use it yet.
I was going to respond later today, after I got the chance to gather more data but the offtopic branch of this thread does interest me. I'm going to defend the "a hello world app should be able to run on a 512 MiB rPI." side of the conversation. If I need more than 512 MiB of RAM, it must be because of the app is a huge beast and/or gets a lot of traffic, not because the HTTP parser needs 1 GB of RAM to handle some TCP streams.
What I expect from caddy is to consume a small-ish amount of RAM per connection and/or request. We can't pretend webservers need gigs of RAM to work when a few days ago we were happily running nginx with thousands of rps on an rPI. Maybe caddy has more features. We can explain some more memory usage that way, but we can't explain gigs worth of RAM... Caddy is written in Go, it's garbage collected. We all know how GC impacts memory usage, but we also know we can tune that and have it work fairly predictably. GC means more memory usage, but it doesn't account for that much.
What I expect from the frankenphp side of things is:

some (very little) overhead from its own processing (unless otherwise justified)
for each worker, a sizable chunk of reserved RAM (I actually don't know exactly how much RAM an empty php VM uses; I should look it up)
for each worker, a chunk of RAM used by my booted app
for each worker, another chunk of RAM used by each request

The last 2 points, maybe 3, are my concern. If my app is poorly written, it's going to leak memory in the worker. If the framework I'm using is not optimised for long running processes, it may leak memory over time. If I'm using some poorly written PHP extension, again, it may leak memory. Those things are my responsibility and I can control them. I expect whatever memory leaks happen, to be from my codebase, not the harness (frankenphp, or caddy).
Assuming every part of this system is leak proof, I should be able to run my new API platform app in a predictable manner with even 512 MiB of RAM, right? It may not be able to process more than 10-20 rps, but it should be able to run without getting killed by the kernel.
I'm running my app in k8s. I'd rather have HPA spawn more pods to handle the demand instead of having a few large pods happily idling with a few gigs of reserved RAM. My staging environment reserves about 2 GB of RAM for mercure+redis+rabbit+mysql. I'm not willing to reserve another 2 GB on just the API platform pod.
A fresh API platform can definitely run on an rPI using nginx and php-fpm. Why should it need more running under caddy?
That being said, let's figure out where's the memory leak (if any) and let this topic be a starting point for a future "frankenphp production tuning guide" :)

Sorry, I was very busy today and didn't have the time to reproduce, but I'm pretty sure that the "create timer" error you got is the symptom of a leak.
Basically, that means that timers created by PHP aren't released, while they should at the end of the request. The default limit is quite high in most environments, so it means that we don't finish the (PHP, and so maybe Go) request, or not finish it properly.

A fresh API platform can definitely run on an rPI using nginx and php-fpm. Why should it need more running under caddy?

It probably doesn't, but worker mode is a totally different beast than cgi-mode. It does use more memory because there is more accounting, things held in memory between requests, etc. This is a trade-off (as everything is) for more speed. If you want more speed, you need to give up something, and in this case, it's memory.
A fresh (example) API platform uses ~150 mb per worker (~50mb per worker&request + 100mb worker), which means you can realistically expect about 5 workers using 750mb under load (which is about 5 concurrent requests). In CGI mode, you can handle quite a bit more than that (in concurrent requests) but give up quite a bit of speed.

@withinboredom yeah, I totally get your point, while I also stand by mine: we need to think critically about the resource usage, not just throw RAM at the problem. Thinking critically, you can find performance optimization opportunities, or you can find the assurance that the system is as good as it gets. I'm okay with throwing RAM only after deciding the system is as good as it gets, or any remaining optimization opportunities are not worth it.
I may be biased from "the good ol' days", on php5.4, symfony2.x, reporting just a few MBs of memory usage. I may need an "update" on the memory requirements of today's apps.
That being said, I'm going to use your script to figure out how much memory I need per worker, per request and figure out how to tune this.

I had to change the script a bit but after running it looks fairly stable.
Running it with 100 requests yields
Starting with 2.00MB memory
Running request....................................................................................................Done
Stats:
Initial bootstrap: 6.00MB
Average memory usage per request: 184.32KB
Max memory usage per request: 16.00MB
Min memory usage per request: 0.00B

I had it run 10k loops and then i watchd ps -o pid,user,rss,vsz,comm yielding
PID   USER     RSS  VSZ  COMMAND
  183 root      61m 162m php

So, the actual memory usage while working is 61 MiB. I then tried to measure the memory usage while sleeping, before doing any work -- the baseline memory usage -- and found 29m. So that's PHP's minimal memory usage. The actual app is thus using 32 MiB.

That's awesome! So, 10 workers should be using a steady ~300mb in the perfect world (and scaling up linearly), which we are (clearly) not seeing.
I wonder if we could make some kind of status page or API call (similar to fpm's, maybe) that shows per-request memory usage, post-bootstrapped memory usage, current memory usage (since end of last request), number of requests processed, etc. Once we instrument it, then it would be a lot easier to actually locate where in the code to start searching...

A status page would certainly be useful. Earlier today I was wondering if it'd be possible to weave frankenphp metrics in caddy's prometheus metrics endpoint (which I'm already happily scraping). I tried 2-3 searches and I couldn't find much on the topic of a module exposing own metrics (that doesn't mean it's impossible, it just means 3 minutes of superficial searching didn't reveal a path for this). When that didn't pan out, I was thinking maybe I could change the frankenphp runtime to capture some metrics (I already kinda forked it). It wouldn't be pretty, or accurate, but it may be doable and good-enough™.
I've seen a symfony prometheus implementation that cleverly used redis for collecting the data (you update redis anytime you want to store a metric and later prometheus would scrape /metrics and you'd serve it the data from redis). That could work.
TLDR; Frankenphp could really use some instrumentation.
Again, thank you so much for the tool :) Maybe you should upstream it in frankenphp's repo? I may be the first (well, second) to need it, but I can't possibly be the last. Maybe upstream it into the runtime repo, as a tool attached to the runtime instead of the webserver.

It's possible to add metrics to the existing Prometheus endpoint.
Here is how I've done that for Mercure:

https://github.com/dunglas/mercure/blob/main/metrics.go#L39
https://github.com/dunglas/mercure/blob/main/caddy/caddy.go#L28

I created a tiny load test using K6 to try to reproduce the issue: https://github.com/dunglas/frankenphp/pull/392
So far, with a very minimal Caddyfile (included in the PR), I didn't manage to reproduce the issue (on Mac).
Maybe it will appear by adding extra options like compression.
Would you mind trying this load test on your machine/config to see if you're able to reproduce the problem?

heaptrack.frankenphp.24362.gz
You can use heaptrack_gui (available on linux, probably mac too, possibly) to view this. This shows where the memory is leaking in cgo/go (looks like there may be a minor leak in worker.go since a "dummy request" is created each time a worker restarts).
Gist of leaks detected:

mostly in frankenphp_update_server_context: specifically in regards to ts_resource (leaks somewhere in zend_ini_refresh_caches, and zend_hash_copy -- so it might be a PHP leak).
if I'm reading correctly, allocations in Go for C datastructures that are not freed. (such as the root directory to chdir to)

unfortunately, it doesn't appear to be capturing all the proper threads, so it's missing request handling and such. I'll see if I can work that out if someone doesn't beat me to it. hmmm. I managed to get some of the request threads, but they are too big to upload here. I'll try to take some smaller ones tomorrow or later this week.

Thanks @withinboredom, it's super helpful!
For 1, the PHP executor is known to be complex and it's hard to track how it manages allocations. Not sure if it's a real leak or not. Don't hesitate to report to the PHP project so they will be able to figure this out.
For 2, do you have identified which data structures?

Actually. Yes.
For (2), it's a red herring because I wrote up something that panics if something isn't freed by the end of the request. It makes the code rather messy because each pointer has to be "registered" with it, but I'd be happy to push it if it might be helpful. But anyway, it was all freed.
I managed to find out where all those gigabytes of memory are; they are in Caddy request contexts. So, I suspect we may be reusing request contexts from other requests, but I'm still chasing that down. I'll make sure to report back when I find something interesting.

So, there are indeed some small memory leaks, but I'm still trying to narrow them down (like 100kb-ish per request using echo "Hello world" as a test script and the executor script for worker mode). For some good news, generally restarting a worker every ~200 or so requests seems to help:
// random jitter to prevent all workers from restarting at the same time during load tests
$jitter = random_int(190, 220);
for($counter = 0; $counter < $jitter; $counter++, frankenphp_handle_request($fn)) {
}
exit 0;

It's possible to get it to fit into 2Gi, but it is quite a challenge because Go is designed for something other than this use case. Once the available memory is used up, the GC thrashes, dropping max requests to 2% of the maximum.
So, why is nginx "so much more performant" in low-memory situations? It's likely because Nginx has complete control over memory. It is usually more efficient to reuse memory than to free and re-acquire the same memory repeatedly (which is what Go is doing and makes sense for general-purpose applications). However, memory is pretty cheap (unless you are in the cloud), so we can forego doing anything with it and sacrifice memory for speed.
 I'm back with more news!
During the investigation into the elusive memory leak in FrankenPHP, I discovered two underlying issues (the Create Timer crash in #440 and a fun one in #439), yet the mystery wasn't entirely done. I've been slamming FrankenPHP with load tests to discover all the different ways it can break, mostly in an attempt to discover the conditions in which it becomes the OOM Killer's best friend.
It appears (for lack of other evidence) that there is potentially a memory leak in Go's http2 implementation (or Caddy isn't handling something correctly) that is causing http2 frames to hang around way too long. This heap profile was taken after a few GCs and had previously handled ~100k requests. It was idle at the time.
With only 2GB of memory available, using http1 (SERVER_NAME=":80"), worker mode, disabling the docker healthchecks, and applying the GC settings above, can let you handle over half a million requests without an issue (with an elementary PHP file).
FrankenPHP and Caddy are using the rest of the memory via request contexts, as each time a request context is modified, an entirely new copy is created.
I'm no Go genius, nor am I entirely familiar with how to hunt down memory leaks in Go, and what I do know are things I've learned over the past week. So, potentially, these graphs just show us something that maybe, someday, hopefully, will be GC'd, yet as far as I can tell, are never actually GC'd. However, I'm reasonably sure there are one of two things going on:

Some objects hold onto http2 request frames/contexts that are no longer useful. These could be in logging objects, original request variables (I know caddy puts a reference to an original request in the context, which could hold a circular reference, but I only just thought of this and didn't investigate it), etc.
During cgi-mode requests, far less memory is utilized, and no memory leak seems apparent (though until #440 is fixed, we can't run it long enough to tell for sure). Since worker mode is processing a request in a CGO callback, the memory being utilized (aka, the "request object") may become "tainted," and Go won't ever GC that memory. Only when #440 is fixed will it be easier to tell.

I'm leaning more towards (2), and this is why:
Go does some shenanigans via syscalls. Thus, I greatly suspect that all requests received by the FrankenPHP handler cannot be freed until the worker fully dies. I cannot find any documentation on that though...
While writing this, I had a eureka moment and opened a PR with a straightforward fix because we don't need caddy's context. I've opened PR #442 with the changes. It doesn't remove the memory leak entirely but gets rid of a large chunk of it.

@ovrflo i do have a question but it's not related to this issue but maybe you can help me anyways. i've seen you ware able to build your frankenphp with the amqp extension - can you give me a hint on how to do that?

It's in the docs @bitbirddev:

for docker: https://frankenphp.dev/docs/docker/
for single-binary: https://frankenphp.dev/docs/static/

@withinboredom i've already tried it with
export PHP_EXTENSIONS=amqp
./build-static.sh

but it gives me an error
[09:56:10] [CRIT] ext [php-amqp] is not supported yet

amqp is also not listed here in the  available extensions list thats why is was wondering...
can you maybe give me another hint?

@withinboredom got your point, i'm sorry. i was just curious because in the first post from @ovrflo he lists his php modules and amqp is in the list - so i thought there has to be a way to do it.


Adding audience

This filters out this pane for normal users - we want to improve it before reintroducing it

This is part of fixing https://github.com/solid/solid-panes/issues/167


node tests: Improve coverage of people.js

Automated message from Dropbox CLA bot
@showell, it looks like you've already signed the Dropbox CLA. Thanks!

Looks great, merged, thanks @showell!


[Webpack 5] ContextModuleFactory - RangeError: Maximum call stack size exceeded

Bug report

What is the current behavior?
The software crashes with stack overflow.
If the current behavior is a bug, please provide the steps to reproduce.
git clone https://github.com/petermetz/blockchain-integration-framework.git
cd blockchain-integration-framework
git checkout -b build/webpack-optimization-139
npm i
./node_modules/.bin/webpack --env-csv=dev --target-csv=node

# To observe the effective webpack config that was returned by the config file
# (which has an entry point and TS-loader rule per each package sub-directory)
# You can check out the contents of the webpack.config.json file =>
cat webpack.config.json

Observe the crash:

$$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:352
                                                        if (item) flattenedResult.push(...item);
                                                                                ^
RangeError: Maximum call stack size exceeded
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:352:34
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)
    at $$PROJECT_ROOT$$/node_modules/webpack/lib/ContextModuleFactory.js:355:7
    at done ($$PROJECT_ROOT$$/node_modules/webpack/node_modules/neo-async/async.js:2931:13)

What is the expected behavior?
There is no stack overflow crash.

Other relevant information:
webpack version: 5.0.0-beta.28
Node.js version: v12.16.3
Operating System: Ubuntu 20.04
Additional tools: ts-loader
It's a mono-repo written in Typescript with packages being in sub-folders and some of them are dependent on others. I'm trying to have a separate bundle for each package and that's why I need Webpack 5 for the new, cool dependOn feature of the entry point object literal syntax. All the webpack config does is get a list of the packages in the mono-repo and their dependency graph, then transforms that into the webpack entry points and a list of ts-loader rules to use (one rule per package, specified via the include property of the rule).

Thanks for the issue

Looks like circular symlinks between two packages and a context dependencies in one of them.
This could be fixed by checking realpath in folders of ContextModuleFactory.resolveDependencies and avoiding visiting recursive symlinked directories. (add visited as Set<string> to addDirectory, do path.realpath before readdir and check if the realpath is in the visited Set.)
Send a PR

@sokra  realpath() is an optional property of InputFileSystem in utils/fs.js Is there any other way to get realpath?.

If this methods doesn't exist assume that the filesystem doesn't support symlinks and this is not an issue.


Cosmos: Explain semantics of the different PatchOperationTypes

It'd be really helpful if the reference documentation here could link to https://docs.microsoft.com/en-us/azure/cosmos-db/partial-document-update#supported-operations, which explains the semantics in detail. Or have the reference documentation explain the semantics in detail.
Same with most of the PatchOperation methods (e.g. PatchOperation.Add())

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4228262e-9067-8ed3-d14f-5329e6ea395e
Version Independent ID: 0f6e384d-d3a3-88ec-842f-7f1ee9a9447e
Content: PatchOperationType Enum (Microsoft.Azure.Cosmos) - Azure for .NET Developers
Content Source: xml/Microsoft.Azure.Cosmos/PatchOperationType.xml
Service: cosmos-db
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

@dotpaul Thanks for the feedback! We will review and update accordingly.


Config flow could not be loaded: undefined

Hi there
When i try to install the integration i get the following error "Config flow could not be loaded: undefined"
I can see the following in the log
Logger: homeassistant.util.package
Source: util/package.py:99
First occurred: 12:15:20 (3 occurrences)
Last logged: 12:16:07
Unable to install package grpcio==1.44.0: ERROR: Cannot install grpcio==1.44.0 because these package versions have conflicting dependencies. ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts WARNING: You are using pip version 22.0.3; however, version 22.0.4 is available. You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command.
System Health

version
core-2022.4.6

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.9.9

os_name
Linux

os_version
5.15.32-v8

arch
aarch64

timezone
Australia/Adelaide

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
5000

Installed Version
1.24.5

Stage
running

Available Repositories
1027

Downloaded Repositories
6

Home Assistant Cloud

logged_in
true

subscription_expiration
17 May 2022, 09:30

relayer_connected
true

remote_enabled
true

remote_connected
true

alexa_enabled
false

google_enabled
true

remote_server
ap-southeast-1-0.ui.nabu.casa

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 8.0.rc2

update_channel
beta

supervisor_version
supervisor-2022.04.2

docker_version
20.10.12

disk_total
58.0 GB

disk_used
7.7 GB

healthy
true

supported
true

board
rpi3-64

supervisor_api
ok

version_api
ok

installed_addons
Terminal & SSH (9.3.0), Node-RED (11.1.1), Studio Code Server (5.0.0), Home Assistant Google Drive Backup (0.106.2)

Dashboards

dashboards
3

resources
1

views
15

mode
storage

any help would be much appreciated

Getting the same thing here.
022-04-23 20:16:13 INFO (MainThread) [homeassistant.requirements] Multiple attempts to install grpcio==1.44.0 failed, install will be retried after next configuration check or restart

I just created a new release which should fix this. Sorry must have missed creating the release with the last update.

Trying the new version did not resolve this issue for me.


Using native ORM client to perform request to PlanetScale without using the CLI at first place

I can't find a clear way to run my queries on PlanetScale other than going through this library or should I use this library as a connection intermediary to power my existing ORM nodeJS (sequelize) without having to do the initial handshake with the CLI pscale connect <my-db> main --execute '<my-app-main>'?
Is there a reference for the correct way to do this?

We're working on it! Will share an update soon.

Thanks for the update!

Hi @dbrrt, we just shipped: https://planetscale.com/blog/connect-any-mysql-client-to-planetscale-using-connection-strings
Now you can generate a connection string and connect directly without using this library or pscale connect.


Tips for Enhance Project !

Hello @hfiref0x we have some tips to you consider change in some future update
Please consider make these changes:
Thanks !

Tip 1:
Add "%VM%" instead of "%1" in batch script

set /p VM="Input Name of VM: "

sample:  https://imgur.com/a/t44AIuD

Tip 2:
efi_amd64_fixed_6.1.2.fd Patched EFI module for some reason don't allow change string DmiSystemUuid
Please rool back to VBoxEFI64-6.0.10.fd version that allows change DmiSystemUuid
sample: https://github.com/hfiref0x/VBoxHardenedLoader/commit/2e364299b73e25ae937c941c8b5bb4a09bcd9d92#diff-03a551b86c64cdeb37a9ba33a0759da6

Tip 3:
Put back .bat script file to start and stop loader.exe
REM Append full patch to loader.exe and run this batch file elevated
@echo
echo Running loader
loader.exe

sample:  https://gofile.io/?c=v5a6nz

Tip 4:
Add anti_RTSC in batch script
sample:  https://github.com/vektort13/antiRTSC

Ok, this will be in next commit(s).
If it doesn't work then it is Oracle bug, using EFI rom from previous VBox version isn't wise as it contain a lot of various modules and they maybe heavily changed between 6.0.x and 6.1.x

I cannot reproduce this on test.
<ExtraDataItem name="VBoxInternal/Devices/efi/0/Config/DmiSystemUuid" value="80A3D0F4-9FAB-E211-8D78-8851FB5B5288"/>
Result from RWEverything
UUID	0x80 0xA3 0xD0 0xF4 0x9F 0xAB 0xE2 0x11 0x8D 0x78 0x88 0x51 0xFB 0x5B 0x52 0x88
Wakeup Type	0x06 - Power Switch
SKU Number	String5 - <censored>
Family	String6 - <censored>

Ok, I will add these scripts back in the next commit(s).
This works not as you expect it to be working. Practically this settings is almost useless.

Here is a simple test program.
https://gist.github.com/hfiref0x/e0eb1f7588613b01526efceb85cde80b
This is a test on real hardware (note that cpuid always add overhead)
host is Linux
guest is Windows 10, 1909
cpuid test
interval: 339
interval: 450
interval: 277
interval: 353
interval: 217
interval: 226
interval: 217
interval: 225
interval: 108
interval: 111
empty test
interval: 53
interval: 24
interval: 24
interval: 53
interval: 21
interval: 53
interval: 53
interval: 53
interval: 27
interval: 53

Result with default VM TSC config (2 CPU)
cpuid test
interval: 18159
interval: 18558
interval: 18424
interval: 16471
interval: 18199
interval: 17246
interval: 18184
interval: 16280
interval: 16175
interval: 19324
empty test
interval: 8608
interval: 7567
interval: 3583
interval: 7157
interval: 5957
interval: 7262
interval: 9246
interval: 8459
interval: 7151
interval: 8345

Result with RealTSCOffset set in VM (2 CPU)
cpuid test
interval: 17026
interval: 17377
interval: 17677
interval: 16687
interval: 17093
interval: 18623
interval: 17467
interval: 18390
interval: 12344
interval: 10089
empty test
interval: 53
interval: 35
interval: 21
interval: 53
interval: 28
interval: 51
interval: 53
interval: 53
interval: 46
interval: 46

With Dynamic set in VM (2 CPU)
cpuid test
interval: 17153
interval: 20085
interval: 16419
interval: 16500
interval: 15757
interval: 16659
interval: 10695
interval: 16110
interval: 18127
interval: 16424
empty test
interval: 24
interval: 24
interval: 53
interval: 49
interval: 44
interval: 53
interval: 36
interval: 28
interval: 53
interval: 53

Cpuid breaks this entirely, so it is almost useless.
These settings
VBoxInternal/CPUM/SSE4.1 1
VBoxInternal/CPUM/SSE4.2 1

are default VBox settings, e.g. output of lscpu on default Linux VM

fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm cr8_legacy abm sse4a misalignsse 3dnowprefetch ssbd vmmcall fsgsbase avx2 rdseed clflushopt arat

Quote

These are per-VM settings which are enabled by default.

https://www.virtualbox.org/manual/ch09.html#sse412passthrough
Additionaly these settings are completely unrelated / does not affect TSC in any way.
I don't think it is possible to completely evade detection of running in a VM.

See commit in dev branch. If it is Ok for you this will be merged later to the master.

All sounds very good changes, better than i expected
About issue number 2 using efi_amd64_fixed_6.1.2.fd
Are you able to change DmiSystemUuid  value GUID ?
For me is not possible, when i change this value him never refect in VM
Its remains unalterable, All VMs have same value GUID
"VBoxInternal/Devices/efi/0/Config/DmiSystemUuid" "B5FA3000-9403-81E0-3ADA-F46D045CB676"
The only way of modify this is using module EFI from the old version of the project.

The value "B5FA3000-9403-81E0-3ADA-F46D045CB676" is the UUID specified in patch scripts.
VBox UUID is 0x34 0x1E 0x2B 0xB8 0x80 0x2C 0x42 0x2B 0xBF 0xAD 0xAE 0x96 0x31 0x7F 0x09 0x01
I dont see any problem or bug here.

The value "B5FA3000-9403-81E0-3ADA-F46D045CB676" is the UUID specified in patch scripts.
VBox UUID is 0x34 0x1E 0x2B 0xB8 0x80 0x2C 0x42 0x2B 0xBF 0xAD 0xAE 0x96 0x31 0x7F 0x09 0x01
I dont see any problem or bug here.

Yes rigth, but if i need change this value im not able, im sticky in just this value: "B5FA3000-9403-81E0-3ADA-F46D045CB676"
I hope in future Oracle updates this issue has fixed
Until then i will have to use an old version of EFI module, because i need to constantly change the UUID value, this is very important for my tasks
Any EFI module VBoxEFI64-6.0.x.fd versions working fine.

Any chance to re-open this topic https://github.com/hfiref0x/VBoxHardenedLoader/issues/56
To i write a final solution for users with the same issue ?

Successfully changed it to "12345678-9403-81E0-3ADA-F46D045CB676". It is something on your side or how you change it. There is no bug.

Successfully changed it to "12345678-9403-81E0-3ADA-F46D045CB676". It is something on your side or how you change it. There is no bug.
I absolutely UNADVISE you use of EFI ROM from 6.0x on 6.1x. They are different, there will be setbacks where you can't expect.

These value UUID reflect in VM ?
Im using macOS Guest, and the value UUID dont reflect in VM
Still sticky in "B5FA3000-9403-81E0-3ADA-F46D045CB676"
No matter how many times I change it in the batch script and apply
In few hours i will create a screenshot to attach to this topic.

Up

You need to cross check UUID from different OS, for example by booting from CD-ROM in this VM. This thing maybe just remembered initial value.

You need to cross check UUID from different OS, for example by booting from CD-ROM in this VM. This thing maybe just remembered initial value.
P.S.
You may also try removing nvram file located in your VM directory (do the backup copy for sure).

Deleting nvram file fix issue temporary, but  if i need change UUID again i need delete nvram file again
This is a bug from oracle ?

Another issue i found:
If i put a USB Stick for start with VM ( in USB Settings )
The VM dont start, just a black screen is showed, when i remove USB Stick, VM Start normaly.
Using the latest version of module EFI, in old version this bug dont exists.

None of this are issues of this loader.


(Client=55) Indexed query takes 2.2s

Our main feed query takes 2.7s to complete. We get this query 10M+ times per month, and it is the first thing a user sees. Our entire goal with OrientDB was to make this query faster due to the heavy amount of joins it requires, so let's see how fast we can make it!
This query grabs a batch of 10 Posts:
SELECT
  @rid as @rid,
  @class,
  actionId,
  commentCount,
  facebook,
  featurePostOnDate,
  forcedPrivate,
  instagram,
  isReported,
  likeCount,
  note,
  photo,
  private,
  new,
  popular,
  twitter,
  createdAt,
  updatedAt,
  in_UserWrotePost
FROM indexvaluesdesc:Post.newFeed
WHERE new = true AND actionId IN [1,207,8,1300,2000,2001,2002,2003,2004] AND in_UserWrotePost.size() = 1 AND (private = false OR private IS NULL)
LIMIT 10
FETCHPLAN in_UserWrotePost.out:0 in_UserWrotePost.out.out_UserHasSettings:0 in_UserWrotePost.out.out_UserHasSubscription:0 in_UserWrotePost.out.out_UserHasPromoCode:0 in_UserWrotePost.out.out_UserAddedActivityLog:-2 in_UserWrotePost.out.out_UserAddedWeightLog:-2 in_UserWrotePost.out.out_UserAddedWorkoutLog:-2 in_UserWrotePost.out.out_UserBuiltWorkout:-2 in_UserWrotePost.out.out_UserClaimedPromoCode:-2 in_UserWrotePost.out.out_UserFollowsUser:-2 in_UserWrotePost.out.out_UserHadError:-2 in_UserWrotePost.out.out_UserLikesPost:-2 in_UserWrotePost.out.out_UserSentInvite:-2 in_UserWrotePost.out.out_UserWroteComment:-2 in_UserWrotePost.out.out_UserWrotePost:-2 in_UserWrotePost.out.in_NotificationIsFromUser:-2 in_UserWrotePost.out.in_NotificationIsToUser:-2 in_UserWrotePost.out.in_UserFollowsUser:-2

Here is the index:
CREATE INDEX Post.newFeed ON Post (new, actionId, createdAt) NOTUNIQUE

Simply selecting from the index is slow, as described at https://github.com/orientechnologies/orientdb/issues/3312, so I'm looking at any way to make this query faster. Without using the index directly, it is incredibly slow (I cut it off after 30s).
I'm also worried that query caching is not working, as running the query multiple times yields the same time (2.2s).
For some reason, since working on this query with @tglman a week ago, the speed of this query has more than doubled. I'm thinking this may be due to some recent changes, as we are using the latest commit in the develop branch.
This query speed for Binary Protocol is also dependent on https://github.com/orientechnologies/orientdb/issues/3248 and https://github.com/orientechnologies/orientdb/issues/3263, which are of higher priority, but this is next in line.

Hi @garrett-gottlieb
I remember I changed that index removing "actionId", this way:
CREATE INDEX Post.newFeed ON Post (new, createdAt) NOTUNIQUE
and it reduced execution time to ~1 sec
Is it possible that you re-created it? (maybe I'm wrong and I don't remember correctly...)

Hi @garrett-gottlieb
could you try my suggestion? Do you have a feedback about this?

@garrett-gottlieb I had no feedback about this, I'm closing.
Please re-open (or let's talk about it in chat) if needed


Fix interceptor if query have no query strings

If an interceptor has query parameters, requests with no query string must not be intercepted.
Fixes #610

Coverage increased (+0.01%) to 92.671% when pulling b9d2823fd984e28f91d1483d3960235d63a2b7db on yodeyer:fixQs into 719776976e742ad2e7917c83322241b84e3110f6 on node-nock:master.

@yodeyer is this supposed to address #610?

@ianwsperber yes

@iangreenleaf any news here? 😄

LGTM. Treating this as a bug and sending out in a patch release.


util:test(util/convertnhcb) add test cases with parallel

related to https://github.com/prometheus/prometheus/issues/15185
➜  prometheus git:(convertnhcbtest) go test -race --count=1 ./util/convertnhcb
ok      github.com/prometheus/prometheus/util/convertnhcb       1.397s

@bboreham - my bad was testing something and tracing changes got pushed - had removed them now.


refactor: use shared generator FST

The paradigm filler (the thing that fills in all the cells in a paradigm) used to instantiate its own copy of the normative generator (the thing that spits out perfect SRO, given an analysis). But only one copy is needed in the application, so use that one copy!

Codecov Report

Merging #617 (d206a02) into master (ebe35df) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #617      +/-   ##
==========================================
+ Coverage   86.70%   86.72%   +0.01%
==========================================
  Files          52       52
  Lines        2121     2124       +3
  Branches      335      336       +1
==========================================
+ Hits         1839     1842       +3
  Misses        214      214
  Partials       68       68

Impacted Files
Coverage Δ

CreeDictionary/utils/paradigm_filler.py
89.62% <100.00%> (+0.30%)
:arrow_up:

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 ebe35df...d206a02. Read the comment docs.

Codecov Report

Merging #617 (d206a02) into master (ebe35df) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #617      +/-   ##
==========================================
+ Coverage   86.70%   86.72%   +0.01%
==========================================
  Files          52       52
  Lines        2121     2124       +3
  Branches      335      336       +1
==========================================
+ Hits         1839     1842       +3
  Misses        214      214
  Partials       68       68

Impacted Files
Coverage Δ

CreeDictionary/utils/paradigm_filler.py
89.62% <100.00%> (+0.30%)
:arrow_up:

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 ebe35df...d206a02. Read the comment docs.

Can this be modified easily to use the normative generator with morpheme boundaries? Because it is the morpheme boundaries we'd want to eventually see in the paradigms, and in the standardized representation of the search string (as an option the user can choose to select).

Can this be modified easily to use the normative generator with morpheme boundaries? Because it is the morpheme boundaries we'd want to eventually see in the paradigms, and in the standardized representation of the search string (as an option the user can choose to select).

Can this be modified easily to use the normative generator with morpheme boundaries? Because it is the morpheme boundaries we'd want to eventually see in the paradigms, and in the standardized representation of the search string (as an option the user can choose to select).

Yes and no. It's out of the scope of this particular PR (the PR is already merged and running on Sapir!). We could plop in the FST with morpheme boundaries but nothing in itwêwina knows how to deal with morpheme boundaries, so it will treat it like alphabetic text (i.e., we'll see results like "ni<wâpam>âw" with no option to remove the "<" and ">). We could add some further hacks  to the FST loader code to remove morpheme boundaries before they make their way into the rest of itwêwina, but I'd like to get rid of existing hacks first! (see #620)
The better option is simply to integrate the FST with morpheme boundaries when we start to implement morpheme boundaries in itwêwina proper. That way, we wouldn't require any hacks!

Can this be modified easily to use the normative generator with morpheme boundaries? Because it is the morpheme boundaries we'd want to eventually see in the paradigms, and in the standardized representation of the search string (as an option the user can choose to select).

Yes and no. It's out of the scope of this particular PR (the PR is already merged and running on Sapir!). We could plop in the FST with morpheme boundaries but nothing in itwêwina knows how to deal with morpheme boundaries, so it will treat it like alphabetic text (i.e., we'll see results like "ni<wâpam>âw" with no option to remove the "<" and ">). We could add some further hacks  to the FST loader code to remove morpheme boundaries before they make their way into the rest of itwêwina, but I'd like to get rid of existing hacks first! (see #620)
The better option is simply to integrate the FST with morpheme boundaries when we start to implement morpheme boundaries in itwêwina proper. That way, we wouldn't require any hacks!

Ok.
My comment had the longer term in mind, when I'd think we could get by using only the normative generator FST with boundaries, and then have the code on the itwêwina side reinterpret the morpheme boundaries in whichever way in its internal structure, and then either represent the boundaries appropriately, e.g. with the middle-dot, or removing them entirely, based on user settings.

Ok.
My comment had the longer term in mind, when I'd think we could get by using only the normative generator FST with boundaries, and then have the code on the itwêwina side reinterpret the morpheme boundaries in whichever way in its internal structure, and then either represent the boundaries appropriately, e.g. with the middle-dot, or removing them entirely, based on user settings.


Run multi-tenant tests on CircleCI

I was wondering if someone has already tried running their tests on CircleCI.
I am having difficulties with setting the environment (nginx configurations, users etc) in the container so if someone has a config.yml that works it would be awesome.

This package already uses CircleCI (https://circleci.com/gh/hyn/multi-tenant), so perhaps you could reference that configuration?
Also, this question is best asked in our Discord chat.  Github is generally reserved for package issues and feature requests.


[ENG-6665] Add user messaging modal to user's tab on institutional dashboard

⚠ Needs https://github.com/CenterForOpenScience/osf.io/pull/10824 for API usaage.
Purpose
Adds a modal that allows an institutional admin to send a message through a text input as part of an email template.
Summary of Changes

add user-message modal
modifies component to allow for model logic
Add modal to template with styling

Screenshot(s)

Side Effects

QA Notes

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

2 of 18 (11.11%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.08%) to 64.754%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

app/adapters/user-message.ts
1
3
33.33%

app/institutions/dashboard/-components/institutional-users-list/component.ts
1
15
6.67%

Totals

Change from base Build<PHONE_NUMBER>7:
-0.08%

Covered Lines:
6935

Relevant Lines:
10295

💛  - Coveralls

@futa-ikeda Based on the ARB, we decided we wanted two additional features here:

a checkbox that CC you the email you sent
a checkbox that puts your email address as the reply-to header

So bare with me as I address your comments, but also add those two things in the next iteration.

@Johnetordoff This should be pointing to a feature branch based off of develop, please.


Adding support for Safety scans

Adds support for Saftey scanner released by pyup.io detailed here. I wasn't able to find the mentioned /docs folder so mentioned documentation has not been included. PR #7 has also been submitted to sample-scan-files with sample scan data.
Safety does not include severity levels for each finding, so all findings are being set to Info as is seen with other scanners. CVE data is not included in scan json data, so the Safety DB JSON is obtained to be included.

[X] Your code is flake8 compliant (Dojo's code isn't currently flake8 compliant, but we're trying to correct that)
[ ] If this is a new feature and not a bug fix, you've included the proper documentation under the /docs folder

we don't agree with their reasoning

Can you share their reasoning?

They don't want the database or any derivatives thereof to end up in commercial environments.
You can contact them at<EMAIL_ADDRESS>https://github.com/DefectDojo/django-DefectDojo/pull/5359

Pity, but fits the pattern. What I've read about their licensing, customer support and updates is enough for me to avoid them.


Attach DNS zone in App Routing add-on AKS CLI should check if the zone is a public or private zone

Describe the bug
The --attach-zone parameters of the az aks approuting command doesn't assign the right permissions when doing the role assignment.

For public/global Azure DNS zones, that should be DNS Zone Contributor, which is what it is doing right now.
For private Azure DNS zones, that should be Private DNS Zone Contirbutor, which is now being incorrectly set to DNS Zone Contributor.

This should be fixed for both the create and update functionality.
Related command
az aks approuting zone add
Errors
The created role assignment is incorrect, which leads External DNS on the cluster to not work properly.
Issue script & Debug output

Expected behavior

For public/global Azure DNS zones, that should be DNS Zone Contributor, which is what it is doing right now.
For private Azure DNS zones, that should be Private DNS Zone Contirbutor, which is now being incorrectly set to DNS Zone Contributor.

This should be fixed for both the create and update functionality.
Environment Summary
azure-cli                         2.54.0 *
core                              2.54.0 *
telemetry                          1.1.0
Extensions:
aks-preview                      1.0.0b4
alb                                1.0.0
amg                                1.2.9
connectedk8s                       1.5.3
containerapp                      0.3.43
fleet                              1.0.0
interactive                        0.5.3
k8s-extension                      1.5.2
load                               0.3.2
Dependencies:
msal                            1.24.0b2
azure-mgmt-resource             23.1.0b2
Python location '/opt/az/bin/python3'
Extensions directory '/home/asabbour/.azure/cliextensions'
Python (Linux) 3.11.5 (main, Nov  8 2023, 05:20:54) [GCC 11.4.0]
Legal docs and information: aka.ms/AzureCliLegal
Additional context
No response

Thank you for opening this issue, we will look into it.

Tagging @bosesuneha from app routing engineering.

I'll create a PR for the fix.


[WIP] Added BCQ

Stuff implemented:

Added BCQ under genrl/agents/offline
BCQ inherits from OffPolicyAgentAC. Architecture was very similar to TD3. Major differences were that the actor took in both state and action as input and the VAE obviously.
OfflineTrainer inherits from OffPolicyTrainer. Only difference is that it loads the buffer.
Refactored buffers and rollouts to inherit from BaseBuffer and remove redundant functions and converted all code to torch. No numpy is used in any of the buffer files now.

Stuff to do:

[ ] Haven't tested properly yet if it works. Currently created a toy replay buffer from DDPG on Pendulum-v0 with only 100 experiences
[ ] Will have to find a simple way to make the actor take in both state and action.

Buffers have been tested but not after the addition of BCQ so tests are failing rn


Add Cloud Foundry configuration

Is your feature request related to a problem? Please describe.
This project will be running on a Cloud Foundry instance, as such configuration for this environment is needed.
Describe the solution you'd like
Add a manifest.yml file similar to the one found in code-gov-api
Describe alternatives you've considered
Have the Cloud Foundry configuration live in the CircleCI config. This can be done by adding the config values to the cf push command. This is not Ideal IMO.
Additional context
The manifest.yml file is used to configure the runtime of the application in Cloud Foundry.

Hello Code.gov team @saracope @jcastle @AminPIC.
I was browsing around and noticed that this issues was still open. This should have been closed when the manifest.yml file was added. All Cloud.gov configuration should be there. 😃

As per Froi's comment above and updated manifest.yml with emailing and cflinuxfs3 stack, this issues can be closed.


Touch scrolling broken in Microsoft Edge

VSCode Version: 1.15.1
OS Version: Windows 10 - Build 16271+

Steps to Reproduce:

Open any Monaco test page in Edge
Attempt to scroll with touch

Reproduces without extensions: Yes

Monaco uses window.navigator.pointerEnabled to feature detect standard Pointer Events. This property was deprecated in the standard and is being removed from Microsoft Edge as of build 16271.
I have a PR coming shortly with a fix. Note that this also breaks the F12 tools in Edge (which use monaco-editor).

Moved to https://github.com/Microsoft/monaco-editor/issues/644


Change hardcoded occurrences of compass-system namespace in KEB

Description
Changes proposed in this pull request:

Change hardcoded occurrences of compass-system namespace

Related issue(s)
Follow-up issue regarding parameterization of these values: https://github.com/kyma-project/control-plane/issues/35

/test pre-control-plane-components-kyma-environment-broker

/retest


image name overwrites cover image

Describe the bug
the image name of cover images have a problem with each other which leads to no shown cover image (see steps:)
Steps To Reproduce

have a shelf with two books
add a cover image (with the name "test.png") to the first book
cover image is successfully shown
add a cover image (also with the name "test.png") to the second book
the second book gets no image, the first book looses its cover image

Expected behavior
obviously should not happen ;)
idea is to maybe rename the picture in the background
Screenshots
Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings):
PHP Version:
Hosting Method (Nginx/Apache/Docker):

Additional context

Hi @Smoin1,
Thanks for reporting this occurrence but I'm having trouble reproducing this issue. When I follow the provided steps my outcome is different, Both books receive the provided image, with the latter being stored with a prefixed name to avoid conflicts.  Could you confirm the following:

Are you using a non-default storage option?
Are you able to re-produce this on the demo site?

hm, damn. something in the steps is different from what I did and I cannot reproduce it currently... you can close this and I will reopen once I found out

Okay, Thanks for confirming.


DISCUSSION: context v3 - add issuer name

Discussion started here: https://github.com/Open-Attestation/open-attestation/discussions/186
this is workaround for https://github.com/w3c/json-ld-syntax/issues/361
I am unsure if it is a good idea to put this in the context. As a VC creator, I would prefer to customize the full url for issuer.name field in my own custom context so that I can give it more specific semantics, like restricting allowed characters, or omit it completely, only requiring an "id".

I think I get your point. One question, with the suggested context that means that as a user I need to add the type in the issuer property
"issuer": {
 "name": "whatever",
 "type": "OpenAttestationIssuer"
 }

As a user, if you want to redefine the context then you can change the type and not rely on OpenAttestationIssuer:
"issuer": {
 "name": "whatever",
 "type": "WhateverType"
 }

In this case, if we define our own definition it won't cause an issue for people redefining the context. Is that correct?

Yes, that's correct

In that case, as OA won't force any type use in the issuer property I guess it's fine to merge this. Any concern ?
Note: we are still in beta we can change this later if really

Ok, would work for me.

:tada: This PR is included in version 1.8.9 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Unable to acs-engine deploy with v0.17.0: 'The number of template variables limit exceeded. Limit: '256' and actual: '257'

Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
Issue
What version of acs-engine?:
v0.17.0

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes 1.10.2
What happened:
INFO[0004] Starting ARM Deployment (ad3-k8s-dev-west-a-989867831). This will take some time...
INFO[0006] Finished ARM Deployment (ad3-k8s-dev-west-a-989867831). Error: resources.DeploymentsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidTemplate" Message="Deployment template validation failed: 'The number of template variables limit exceeded. Limit: '256' and actual: '257'. Please see https://aka.ms/arm-template/#variables for usage details.'."
ERRO[0006] {"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The number of template variables limit exceeded. Limit: '256' and actual: '257'. Please see https://aka.ms/arm-template/#variables for usage details.'."}}
FATA[0006] resources.DeploymentsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidTemplate" Message="Deployment template validation failed: 'The number of template variables limit exceeded. Limit: '256' and actual: '257'. Please see https://aka.ms/arm-template/#variables for usage details.'."

What you expected to happen:
Deploy successfully
How to reproduce it (as minimally and precisely as possible):
☁  v0.17.0  ./acs-engine deploy --api-model ./_output/<REDACTED>/apimodel.json \
    --subscription-id <REDACTED> \
    --resource-group <REDACTED> \
    --ca-certificate-path <REDACTED>/ca.crt \
    --ca-private-key-path <REDACTED>/ca.key \
    --auth-method client_secret \
    --client-id <REDACTED> \
    --client-secret <REDACTED> \
    --location "westus" \
    --force-overwrite

Anything else we need to know:
cluster_definition.json
{
  "apiVersion": "vlabs",
  "properties": {
    "orchestratorProfile": {
      "orchestratorType": "Kubernetes",
      "orchestratorRelease": "1.10"
    },
    "masterProfile": {
      "count": 3,
      "dnsPrefix": <REDACTED>,
      "vmSize": "Standard_D11_v2"
    },
    "agentPoolProfiles": [
      {
        "name": "linuxpool1",
        "count": 5,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks"
      },
      {
        "name": "linuxpool2",
        "count": 5,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks",
        "extensions": [
          {
            "name": "prometheus-grafana-k8s"
          }
        ]
      },
      {
        "name": "windowspool1",
        "count": 3,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks",
        "osType": "Windows"
      },
      {
        "name": "windowspool2",
        "count": 3,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks",
        "osType": "Windows"
      }
    ],
    "windowsProfile": {
      "adminUsername": <REDACTED>,
      "adminPassword": <REDACTED>
    },
    "linuxProfile": {
      "adminUsername": <REDACTED>,
      "ssh": {
        "publicKeys": [
          {
            "keyData": "<REDACTED>"
          }
        ]
      }
    },
    "extensionProfiles": [
      {
        "name": "prometheus-grafana-k8s",
        "version": "v1",
        "rootURL": "https://raw.githubusercontent.com/Azure/acs-engine/master/"
      }
    ],
    "servicePrincipalProfile": {
      "clientId": <REDACTED>,
      "secret": <REDACTED>
    }
  }
}

Is this a regression from v0.16.0?

@jackfrancis I used this same definition in v0.16.2 successfully. Generated from scratch using this cluster definition.

Same failure running from master;
INFO[0004] Starting ARM Deployment (ad3-k8s-dev-west-a-1826111904). This will take some time...
INFO[0006] Finished ARM Deployment (ad3-k8s-dev-west-a-1826111904). Error: resources.DeploymentsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidTemplate" Message="Deployment template validation failed: 'The resource 'Microsoft.Compute/virtualMachines/k8s-linuxpool2-17595707-0/extensions/cse0' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'."
ERRO[0006] {"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Compute/virtualMachines/k8s-linuxpool2-17595707-0/extensions/cse0' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'."}}
FATA[0006] resources.DeploymentsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidTemplate" Message="Deployment template validation failed: 'The resource 'Microsoft.Compute/virtualMachines/k8s-linuxpool2-17595707-0/extensions/cse0' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'."
☁  bin [master] ⚡ ./acs-engine version
Version: canary
GitCommit: 6457e15b
GitTreeState: dirty

Yep, thanks. We'll look into how to deal with this for the next release. :(

@jackfrancis Something else may be broken with extensions entirely, I removed all references to extesnsions in my clusterdef, and am getting this;
{
  "apiVersion": "vlabs",
  "properties": {
    "orchestratorProfile": {
      "orchestratorType": "Kubernetes",
      "orchestratorRelease": "1.10"
    },
    "masterProfile": {
      "count": 3,
      "dnsPrefix": <REDACTED>,
      "vmSize": "Standard_D11_v2"
    },
    "agentPoolProfiles": [
      {
        "name": "linuxpool1",
        "count": 5,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "VirtualMachineScaleSets",
        "storageProfile": "ManagedDisks"
      },
      {
        "name": "linuxpool2",
        "count": 5,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "VirtualMachineScaleSets",
        "storageProfile": "ManagedDisks",
      },
      {
        "name": "windowspool1",
        "count": 3,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "VirtualMachineScaleSets",
        "storageProfile": "ManagedDisks",
        "osType": "Windows"
      },
      {
        "name": "windowspool2",
        "count": 3,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "VirtualMachineScaleSets",
        "storageProfile": "ManagedDisks",
        "osType": "Windows"
      }
    ],
    "windowsProfile": {
      "adminUsername": <REDACTED>,
      "adminPassword": <REDACTED>
    },
    "linuxProfile": {
      "adminUsername": <REDACTED>,
      "ssh": {
        "publicKeys": [
          {
            "keyData": "<REDACTED>"
          }
        ]
      }
    },
    "servicePrincipalProfile": {
      "clientId": <REDACTED>,
      "secret": <REDACTED>
    }
  }
}

INFO[0004] Starting ARM Deployment (ad3-k8s-dev-west-a-1296466505). This will take some time...
INFO[0860] Finished ARM Deployment (ad3-k8s-dev-west-a-1296466505). Error: resources.DeploymentsClient#CreateOrUpdate: Failure sending request: StatusCode=200 -- Original Error: Long running operation terminated with status 'Failed': Code="DeploymentFailed" Message="At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details."
ERRO[0860] {"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.","details":[{"code":"Conflict","message":"{\r\n  \"status\": \"Failed\",\r\n  \"error\": {\r\n    \"code\": \"ResourceDeploymentFailure\",\r\n    \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\",\r\n    \"details\": [\r\n      {\r\n        \"code\": \"VMExtensionProvisioningError\",\r\n        \"message\": \"VM has reported a failure when processing extension 'vmssCSE'. Error message: \\\"Enable failed: failed to execute command: command terminated with exit status=9\\n[stdout]\\n\\n[stderr]\\n\\\".\"\r\n      }\r\n    ]\r\n  }\r\n}"}]}}
FATA[0860] resources.DeploymentsClient#CreateOrUpdate: Failure sending request: StatusCode=200 -- Original Error: Long running operation terminated with status 'Failed': Code="DeploymentFailed" Message="At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details."

@CecileRobertMichon Interesting... I'm working from master after the PR just went through;
☁  acs-engine [master] ⚡ ./bin/acs-engine version
Version: canary
GitCommit: b0236c0e
GitTreeState: dirty

for the extensions fix, but I'm still seeing an ERRO[0007] {"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Compute/virtualMachines/k8s-linuxpool1-35976173-0/extensions/cse-master-0' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'."}}
Here's the cluster definition I'm using;
{
  "apiVersion": "vlabs",
  "properties": {
    "orchestratorProfile": {
      "orchestratorType": "Kubernetes",
      "orchestratorRelease": "1.10"
    },
    "masterProfile": {
      "count": 3,
      "dnsPrefix": <REDACTED>,
      "vmSize": "Standard_D11_v2"
    },
    "agentPoolProfiles": [
      {
        "name": "linuxpool1",
        "count": 5,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks"
      },
      {
        "name": "linuxpool2",
        "count": 5,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks",
        "extensions": [
          {
            "name": "prometheus-grafana-k8s"
          }
        ]
      },
      {
        "name": "windowspool1",
        "count": 3,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks",
        "osType": "Windows"
      },
      {
        "name": "windowspool2",
        "count": 3,
        "vmSize": "Standard_D11_v2",
        "availabilityProfile": "AvailabilitySet",
        "storageProfile": "ManagedDisks",
        "osType": "Windows"
      }
    ],
    "windowsProfile": {
      "adminUsername": <REDACTED>,
      "adminPassword": <REDACTED>
    },
    "linuxProfile": {
      "adminUsername": <REDACTED>,
      "ssh": {
        "publicKeys": [
          {
            "keyData": "<REDACTED>"
          }
        ]
      }
    },
    "extensionProfiles": [
      {
        "name": "prometheus-grafana-k8s",
        "version": "v1",
        "rootURL": "https://raw.githubusercontent.com/Azure/acs-engine/master/"
      }
    ],
    "servicePrincipalProfile": {
      "clientId": <REDACTED>,
      "secret": <REDACTED>
    }
  }
}

@neurot1cal the PR to fix VMSS and Windows isn't merged yet (#3031). The one that went in fixed Promotheus with k8s and Linux.

@CecileRobertMichon Not using VMSS here if you look at the Cluster Definition - This is using AvailabilitySet.

Hmm let me try to repro, thanks for catching that!

@CecileRobertMichon I was able to get the ARM deployment to actually go by modifying azuredeploy.json by changing;
      "name": "[concat(variables('masterVMNamePrefix'), copyIndex(variables('masterOffset')),'/cse', '-master-', copyIndex(variables('masterOffset')))]",

to
      "name": "[concat(variables('masterVMNamePrefix'), copyIndex(variables('masterOffset')),'/cse', copyIndex(variables('masterOffset')))]",

This caused template validate to stop failing, but once the cluster spun up all of the prometheus CSE's failed;

☁  acs-engine [master] ⚡ az group deployment create --name "ad3-k8s-dev-west-b" --resource-group "ad3-k8s-dev-west-b" --template-file ./_output/ad3-k8s-dev-west-b/azuredeploy.json --parameters ./_output/ad3-k8s-dev-west-b/azuredeploy.parameters.json
Deployment failed. Correlation ID: 778879ca-3f74-4688-90bf-fc93995a6477. {
  "status": "Failed",
  "error": {
    "code": "ResourceDeploymentFailure",
    "message": "The resource operation completed with terminal provisioning state 'Failed'.",
    "details": [
      {
        "code": "DeploymentFailed",
        "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.",
        "details": [
          {
            "code": "BadRequest",
            "message": "{\r\n  \"error\": {\r\n    \"code\": \"BadRequest\",\r\n    \"message\": \"Multiple VMExtensions per handler not supported for OS type 'Linux'. VMExtension 'cse-master-1' with handler 'Microsoft.Azure.Extensions.CustomScript' already added or specified in input.\"\r\n  }\r\n}"
          }
        ]
      }
    ]
  }
}

@CecileRobertMichon Awesome! Thank you

Hi @CecileRobertMichon,
Thanks for the fix.
It looks like the deployment is still failed.
OPERATION ID7D0BCEDB12F43E24
TRACKING ID5b69691b-120d-4f72-8189-a9220448301e
STATUSConflict
PROVISIONING STATEFailed
TIMESTAMP5/23/2018, 10:53:39 AM
DURATION36 minutes 27 seconds
TYPEMicrosoft.Compute/virtualMachines/extensions
RESOURCE ID/subscriptions/58043194-91b4-4390-be55-dd64251a67bd/resourceGroups/kzha_k8s_rg/providers/Microsoft.Compute/virtualMachines/k8s-agentpool1-35463463-0/extensions/cse-agent-0
STATUSMESSAGE{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "VMExtensionProvisioningError",
"message": "VM has reported a failure when processing extension 'cse-agent-0'. Error message: "Enable failed: failed to execute command: command terminated with exit status=4"."
}
]
}
}
RESOURCEk8s-agentpool1-35463463-0/cse-agent-0
I'm using 0.17.1 acs-engine: https://github.com/Azure/acs-engine/releases/tag/v0.17.1 and also regenerate the arm template, but the deployment still has the same issue.
Notes: I was performing this on China Azure.

@huajunzhao this looks like a separate issue. Please open a new issue and include the apimodel (make sure you remove secrets) you are using to create the cluster.

@neurot1cal can I close this issue?

Sounds good!
On Tue, May 29, 2018 at 4:33 PM Cecile Robert-Michon <
<EMAIL_ADDRESS>wrote:

@neurot1cal https://github.com/neurot1cal can I close this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/acs-engine/issues/3015#issuecomment-392981382,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK_WoCt7k7Yh7uC3gk1Pg33Kga-U9H8dks5t3drSgaJpZM4UFSzv
.

Same for acs-engine 0.19.2

Same for acs-engine 0.20.0.

getting this on 0.20.7 for a config that works in 0.18.8
I've paired the config down as far as I can go to get it under the 256 in 0.18.  but 0.20.7 generates 261 variables with the same script.  had to roll back to 0.18 for now.

@navicore https://github.com/Azure/acs-engine/pull/3649 will fix things


we need to bring back UUID on our metadata

Problem
Because all data is coming from osm, and it doesn't has UUID, and we we can't put it manually because the system is different, we need a method for bring it as metadata
Solution

Put UUID as non-osm tag
Find a method how to generate uuid

uuid already in metadataof healthsite


Virus total detects simple hello world program as a trojan on windows

What version of Go are you using (go version)?

$ go version
go version go1.20.5 windows/amd64

Does this issue reproduce with the latest release?
Yes. Also tried with 1.20.4.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=C:\Users\josew\go\bin
set GOCACHE=C:\Users\josew\AppData\Local\go-build
set GOENV=C:\Users\josew\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\josew\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\josew\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.5
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\josew\go\src\example.com\hola\go.mod
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\josew\AppData\Local\Temp\go-build888617517=/tmp/go-build -gno-record-gcc-switches

What did you do?

`go.mod` file:
module example.com/hola

go 1.20

`main.go` file
package main

import "fmt"

func main() {
	fmt.Println("hola mundo")
}

Compile with go build.
Upload your .exe to https://www.virustotal.com/gui
My exe: hola.zip (google chrome blocks the download).
What did you expect to see?
No virus nor trojan detection.
What did you see instead?

Idk if the url will be available for you but: https://www.virustotal.com/gui/file/2eb68957ba42d0aafcedcef515b0485b22e0dd9e2179081bae83328ff637ba71?nocache=1

https://golang.org/doc/faq#virus


[Python][CI] Tests on windows are running very slow

Appveyor is currently timing out (eg https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/46764558), and also the nightly crossbow wheel tests show very slow tests (eg wheel-windows-cp310-amd64 latest logs).
Going back a bit in time, the same crossbow build from April 1 was fast: logs (tests take about 5 minutes)

The first slow crossbow build seems to be 3 days ago: https://github.com/ursacomputing/crossbow/actions/runs/4649634532/jobs/8228109815

"raw logs" url seems expired, or just I didn't have authority to visit it?

Is it a timeout?  It's pretty consistent on test_conversion.  I assumed it was a segfault.

"raw logs" url seems expired, or just I didn't have authority to visit it?

@mapleFU
Here's a more recent slow build: https://github.com/ursacomputing/crossbow/actions/runs/4676300747/jobs/8282436089
I usually go to Zulip to find nightly test status: https://ursalabs.zulipchat.com/#narrow/stream/181017-nightlies/topic/report/near/348751506

Comparing the last fast and first slow crossbow build, the only external change in the python test environment was an update of pytest from 7.2.2 to 7.3.0, and that might actually be the culprit: https://github.com/pytest-dev/pytest/issues/10896

Sorry, wasn't aware that the raw logs urls expire so quickly. Updated the top post with linking to the normal github actions pages, where you can manually click on "View raw logs"

The new Pytest release fixes the issue. Appveyor is now passing and the wheel tests for Windows are back to ~10 minutes instead of 2hours :). I am closing the issue.


License Scanning

Adopt a license scanning tool, like FOSSA or Snyk

CNCF has requested that we use Snyk, but they are not ready. We should follow up later.


Release v1.2.2

Merged changes from master.

Force merging this since CI can't pass with test folder in yotta ignore list.


Update solution.test.ts

Codecov Report
Patch coverage: 80.76% and project coverage change: -5.61% :warning:

Comparison is base (501b818) 97.41% compared to head (26993ac) 91.81%.
Report is 6 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #23      +/-   ##
==========================================
- Coverage   97.41%   91.81%   -5.61%
==========================================
  Files          17       18       +1
  Lines         232      232
  Branches       49       48       -1
==========================================
- Hits          226      213      -13
- Misses          6       11       +5
- Partials        0        8       +8

Files Changed
Coverage Δ

src/test/ts/com_github_leetcode/linkedlistutils.ts
77.77% <77.77%> (-12.23%)
:arrow_down:

...0001_0100/s0021_merge_two_sorted_lists/solution.ts
82.35% <82.35%> (ø)

... and 16 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix(kube-lint): fix liveness-port check

Image doesn't have exposed ports for liveness and readiness probes.
Adding EXPOSE into image. Also changing tag of the image to latest as we don't use next anymore.
This also creates a chicken egg problem, where we have to build latest image first to make effect on kube-lint, sorry future generations, but this is the best effort/outcome ratio (once we move this check copletely into konflux, we can use currently built image there).
Maintainers will complete the following section

[ ] Commit messages are descriptive enough (hints)
[ ] Code coverage from testing does not decrease and new code is covered (check the PR coverage on codecov)
[ ] Controllers diagrams are updated when PR changes controllers code  (if applicable)

kill me, nothing is easy
check: latest-tag, remediation: Use a container image with a specific tag other than latest.

As I mentioned, this must be merged first to update latest image to have effect on kube-linter (or may not work at all and new fix would be needed :D)


Add statement about CVE-2022-42889 to frontpage

To put things into perspective since this is currently getting some attention.
Can be moved to the 'security' page later.

Thanks for the review, dropped the extra 'that'

-1 publishing the site is a manual process and a pain. We already have a security page which will be published soon
(already a pain) . Plus, moving content around at random times might mess up search engine results.

I find new vulnerability,But I submitted to security@commons.apache.org,No one replied to my email~

@wangdudu321123, from time to time the list gets a lot of traffic, and there may be internal discussion (e.g. someone trying to confirm if the issue can be reproduced, or looking at the archives for past open reports).. The project is also run by volunteers. With this in mind, please wait a while more as it may take some time until we can review all the messages. Finally, this issue is about the statement for an existing CVE, cross-posting unrelated issues is not really helpful.

I find new vulnerability,But I submitted to security@commons.apache.org,No one replied to my email~

@wangdudu321123, from time to time the list gets a lot of traffic, and there may be internal discussion (e.g. someone trying to confirm if the issue can be reproduced, or looking at the archives for past open reports).. The project is also run by volunteers. With this in mind, please wait a while more as it may take some time until we can review all the messages. Finally, this issue is about the statement for an existing CVE, cross-posting unrelated issues is not really helpful.

@kinow Thanks

I updated the security page https://commons.apache.org/proper/commons-text/security.html
I think we can close this PR IMO

I updated the security page https://commons.apache.org/proper/commons-text/security.html I think we can close this PR IMO

Yes, thanks a lot!


Drop creating event connections

Drop creating event connections due to possible large memory consumption and slow queries.

Different solution chosen.


[BUG] !poll reactions get removed

Expected behaviour
Poll reactions stay after voting
Current behaviour
After someone votes on the poll, the bot removes it's own reactions. This only seems to happen in ricing-theming.

sus

It's a mod doing this 🔫

@mTvare6 Free issue on my profile if so

i think this was user error


Triage JDK11 August 2023 respin

Platform
Comments
Status

aarch64_linux

aarch64_mac

arm_linux

✔

ppc64_aix

ppc64le_linux

s390x_linux

x86-32_windows

✔

x86-64_alpine-linux

✔

x86-64_linux

x86-64_mac

x86-64_windows

✔

Release Summary Report for release-openjdk11-pipeline
Report generated at: Thu, 24 Aug 2023 15:21:48 GMT
TRSS Build and TRSS Grid View
Jenkins Build URL https://ci.adoptium.net/job/build-scripts/job/release-openjdk11-pipeline/15/
Started by upstream project "build-scripts/utils/releaseTrigger_jdk11u" build number 1461 at 8/23/2023, 11:31:55 AM

create_installer_mac ❌ undefined ❌
create_installer_windows ❌ undefined ❌
jdk11u-release-aix-ppc64-temurin ⚠ UNSTABLE ⚠
jdk11u-release-linux-aarch64-temurin ⚠ UNSTABLE ⚠
jdk11u-release-linux-ppc64le-temurin ⚠ UNSTABLE ⚠
jdk11u-release-linux-s390x-temurin ⚠ UNSTABLE ⚠
jdk11u-release-linux-x64-temurin ⚠ UNSTABLE ⚠
jdk11u-release-mac-aarch64-temurin ⚠ UNSTABLE ⚠
jdk11u-release-mac-x64-temurin ⚠ UNSTABLE ⚠
sign_build ❌ undefined ❌
sign_installer ❌ undefined ❌
sign_temurin_gpg ❌ undefined ❌

Test_openjdk11_hs_extended.openjdk_aarch64_linux ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_aarch64_linux_testList_0 ⚠ UNSTABLE ⚠
jdk_beans_0 => deep history 6/17 passed | possible issues
jdk_imageio_0 => deep history 6/12 passed | possible issues
Test_openjdk11_hs_extended.openjdk_aarch64_mac ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_aarch64_mac_testList_0 ⚠ UNSTABLE ⚠
jdk_time_0 => deep history 3/15 passed | possible issues
Test_openjdk11_hs_extended.openjdk_aarch64_mac_testList_1 ⚠ UNSTABLE ⚠
jdk_time_1 => deep history 0/10 passed | possible issues
jdk_security3_1 => deep history 15/16 passed | possible issues
Test_openjdk11_hs_extended.openjdk_ppc64_aix ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_ppc64_aix_testList_0 ⚠ UNSTABLE ⚠
jdk_beans_0 => deep history 1/7 passed | possible issues
jdk_net_1 => deep history 0/7 passed | possible issues
jdk_rmi_0 => deep history 4/7 passed | possible issues
jdk_management_1 => deep history 4/7 passed | possible issues
jdk_tools_1 => deep history 4/7 passed | possible issues
Test_openjdk11_hs_extended.openjdk_ppc64_aix_testList_1 ⚠ UNSTABLE ⚠
jvm_compiler_0 => deep history 3/6 passed | possible issues
jvm_compiler_1 => deep history 3/6 passed | possible issues
jdk_security3_0 => deep history 4/7 passed | possible issues
jdk_tools_0 => deep history 4/7 passed | possible issues
jdk_nio_0 => deep history 3/6 passed | possible issues
jdk_beans_1 => deep history 0/6 passed | possible issues
Test_openjdk11_hs_extended.openjdk_ppc64_aix_testList_2 ⚠ UNSTABLE ⚠
jdk_net_0 => deep history 0/6 passed | possible issues
jdk_nio_1 => deep history 3/6 passed | possible issues
jdk_security3_1 => deep history 3/6 passed | possible issues
jdk_management_0 => deep history 3/6 passed | possible issues
jdk_rmi_1 => deep history 3/6 passed | possible issues
Test_openjdk11_hs_extended.openjdk_ppc64le_linux ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_ppc64le_linux_testList_1 ⚠ UNSTABLE ⚠
jvm_compiler_1 => deep history 13/17 passed | possible issues
Test_openjdk11_hs_extended.openjdk_s390x_linux ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_s390x_linux_testList_0 ⚠ UNSTABLE ⚠
jdk_tools_1 => deep history 4/15 passed | possible issues
jdk_imageio_0 => deep history 3/12 passed | possible issues
Test_openjdk11_hs_extended.openjdk_s390x_linux_testList_1 ⚠ UNSTABLE ⚠
jdk_beans_1 => deep history 9/12 passed | possible issues
jdk_tools_0 => deep history 3/15 passed | possible issues
jdk_security3_0 => deep history 3/12 passed | possible issues
jdk_imageio_1 => deep history 3/12 passed | possible issues
Test_openjdk11_hs_extended.openjdk_s390x_linux_testList_2 ⚠ UNSTABLE ⚠
jdk_security3_1 => deep history 2/15 passed | possible issues
Test_openjdk11_hs_extended.openjdk_x86-64_linux ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_x86-64_linux_testList_0 ⚠ UNSTABLE ⚠
jdk_time_1 => deep history 6/12 passed | possible issues
Test_openjdk11_hs_extended.openjdk_x86-64_mac ⚠ UNSTABLE ⚠
Test_openjdk11_hs_extended.openjdk_x86-64_mac_testList_0 ⚠ UNSTABLE ⚠
jdk_io_0 => deep history 11/12 passed | possible issues
jdk_tools_1 => deep history 13/15 passed | possible issues
jdk_other_1 => deep history 14/15 passed | possible issues
jdk_net_1 => deep history 14/15 passed | possible issues
jdk_security_infra_0 => deep history 6/12 passed | possible issues
Test_openjdk11_hs_extended.openjdk_x86-64_mac_testList_1 ⚠ UNSTABLE ⚠
jvm_compiler_1 => deep history 7/15 passed | possible issues
jvm_compiler_0 => deep history 9/18 passed | possible issues
jdk_time_1 => deep history 10/15 passed | possible issues
jdk_security3_0 => deep history 11/12 passed | possible issues
jdk_io_1 => deep history 11/12 passed | possible issues
jdk_tools_0 => deep history 14/15 passed | possible issues
jdk_jfr_0 => deep history 11/12 passed | possible issues
jdk_jdi_1 => deep history 11/12 passed | possible issues
jdk_security_infra_1 => deep history 6/12 passed | possible issues
Test_openjdk11_hs_extended.openjdk_x86-64_mac_testList_2 ⚠ UNSTABLE ⚠
jdk_other_0 => deep history 14/15 passed | possible issues
jdk_security3_1 => deep history 14/15 passed | possible issues
jdk_time_0 => deep history 7/15 passed | possible issues
jdk_net_0 => deep history 14/15 passed | possible issues
jdk_jfr_1 => deep history 14/15 passed | possible issues
jdk_jdi_0 => deep history 14/15 passed | possible issues
Test_openjdk11_hs_sanity.openjdk_aarch64_linux ⚠ UNSTABLE ⚠
Rerun failed
java -version
openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode)

jdk_lang_0 => deep history 41/46 passed | possible issues
jdk_lang_1 => deep history 40/46 passed | possible issues
Test_openjdk11_hs_sanity.openjdk_ppc64_aix ⚠ UNSTABLE ⚠
Rerun failed
java -version
openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode)

jdk_security4_0 => deep history 5/13 passed | possible issues
jdk_security4_1 => deep history 5/13 passed | possible issues
Test_openjdk11_hs_sanity.openjdk_ppc64le_linux ⚠ UNSTABLE ⚠
Rerun failed
java -version
openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode)

jdk_util_0 => deep history 43/45 passed | possible issues
jdk_util_1 => deep history 43/45 passed | possible issues
Test_openjdk11_hs_sanity.openjdk_s390x_linux ⚠ UNSTABLE ⚠
Rerun failed
java -version
openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode)

jdk_lang_1 => deep history 13/41 passed | possible issues
jdk_lang_0 => deep history 13/41 passed | possible issues
jdk_security1_0 => deep history 8/29 passed | possible issues
jdk_security1_1 => deep history 12/29 passed | possible issues
jdk_security2_0 => deep history 13/29 passed | possible issues
jdk_security2_1 => deep history 16/29 passed | possible issues
jdk_util_0 => deep history 2/41 passed | possible issues
jdk_util_1 => deep history 2/41 passed | possible issues
jdk11_tier1_pack200_1 => deep history 7/41 passed | possible issues
jdk11_tier1_pack200_0 => deep history 7/41 passed | possible issues
Test_openjdk11_hs_sanity.system_aarch64_mac ⚠ UNSTABLE ⚠
Rerun failed
java -version
openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode)

Jlink_ReqMod_0 => deep history 39/40 passed | possible issues
Test_openjdk11_hs_sanity.system_ppc64_aix ⚠ UNSTABLE ⚠
Rerun failed
java -version
openjdk version "<IP_ADDRESS>" 2023-08-24
OpenJDK Runtime Environment Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1)
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode)

MauveSingleThrdLoad_HS_5m_0 => deep history 9/16 passed | possible issues
MauveSingleThrdLoad_HS_5m_1 => deep history 9/16 passed | possible issues
MauveSingleInvocLoad_HS_5m_1 => deep history 9/16 passed | possible issues
MauveSingleInvocLoad_HS_5m_0 => deep history 9/16 passed | possible issues

x86-64_linux
Failed testcase rerun in: https://ci.adoptium.net/job/Grinder/7465

x86-64_mac
20 test targets fail (containing large number of testcase failures that do not appear to have been failing previously on the same machine, has there been machine changes recently?)

@smlambert Was that the test-macstadium-x64-4 machine? If so it's probably consistent with what I was seeing and talking about the aqa-test thread last week - it's a machine that went offline at some point and has just been recovered but potentially has some issues which @Haroon-Khel is doing some analysis of

aarch64_mac
on test-macstadium-macos11-arm64-2 sanity.system / Jlink_ReqMod_0 fails with
[2023-08-24T09:52:30.129Z] LIST stderr dyld: Library not loaded: @rpath/libjli.dylib
[2023-08-24T09:52:30.129Z] LIST stderr   Referenced from: /Users/jenkins/workspace/Test_openjdk11_hs_sanity.system_aarch64_mac/aqa-tests/TKG/output_16928681936511/Jlink_ReqMod_0/20230824-025227-JlinkTest/tmp/13.CRI1/bin/java
[2023-08-24T09:52:30.129Z] LIST stderr   Reason: no suitable image found.  Did find:
[2023-08-24T09:52:30.129Z] LIST stderr 	/Users/jenkins/workspace/Test_openjdk11_hs_sanity.system_aarch64_mac/aqa-tests/TKG/output_16928681936511/Jlink_ReqMod_0/20230824-025227-JlinkTest/tmp/13.CRI1/bin/../lib/jli/libjli.dylib: code signature invalid for '/Users/jenkins/workspace/Test_openjdk11_hs_sanity.system_aarch64_mac/aqa-tests/TKG/output_16928681936511/Jlink_ReqMod_0/20230824-025227-JlinkTest/tmp/13.CRI1/bin/../lib/jli/libjli.dylib'
[2023-08-24T09:52:30.129Z] LIST stderr

I think the TestUTCParse has been failing for a while based on what I'd seen last week.
I'll take a look at see if I can identify the issue on test-macstadium-macos11-arm64-2 which was one of the systems I was running some stuff on last week, but good to know that's not a blocker for release now.

aarch64_linux
sanity.openjdk / java/lang/ProcessHandle/InfoTest.java fails on test-docker-centos8-armv8-1 but appears to pass on other systems (deep history), rerun in Grinder/7471
extended.openjdk / jdk_beans
Failed test cases:
TEST: java/beans/PropertyChangeSupport/Test4682386.java
TEST: java/beans/PropertyEditor/TestFontClassJava.java
TEST: java/beans/PropertyEditor/TestFontClassValue.java
TEST: java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java
TEST: java/beans/XMLEncoder/javax_swing_JTree.java
TEST: java/beans/XMLEncoder/Test4631471.java
TEST: java/beans/XMLEncoder/Test4903007.java
Test results: passed: 356; failed: 7

extended.openjdk / jdk_imageio /
rerun extended.openjdk failed testcases in Grinder/7472

on test-macstadium-macos11-arm64-2 sanity.system / Jlink_ReqMod_0 fails with

I'll take a look at see if I can identify the issue on test-macstadium-macos11-arm64-2 which was one of the systems I was running some stuff on last week, but good to know that's not a blocker for release now.

@smlambert https://ci.adoptium.net/job/Grinder/7470/ is a re-run of your grinder on the machine that had the fault - can you confirm whether that looks like a valid re-run that passed and therefore potentially just a glitch rather than an underlying machine issue based on what we've seen so far?

ppc64le_linux
sanity.openjdk / jdk_util / java/util/concurrent/locks/Lock/TimedAcquireLeak.java fails on test-docker-debian11-ppc64le-2 and appears to pass on other machines (deep history)
java.lang.IllegalStateException: No match found
	at java.base/java.util.regex.Matcher.group(Matcher.java:645)
	at TimedAcquireLeak.match(TimedAcquireLeak.java:163)
	at TimedAcquireLeak.realMain(TimedAcquireLeak.java:214)
	at TimedAcquireLeak.main(TimedAcquireLeak.java:336)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:829)
java.lang.AssertionError: Some tests failed
	at TimedAcquireLeak.main(TimedAcquireLeak.java:338)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:829)

JavaTest Message: Test threw exception: java.lang.AssertionError
JavaTest Message: shutting down test

JavaTest Message: Problem cleaning up the following threads:
pool-10-thread-1
  at java.base@<IP_ADDRESS>/jdk.internal.misc.Unsafe.park(Native Method)
  at java.base@<IP_ADDRESS>/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  at java.base@<IP_ADDRESS>/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  at java.base@<IP_ADDRESS>/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
  at java.base@<IP_ADDRESS>/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
  at java.base@<IP_ADDRESS>/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
  at java.base@<IP_ADDRESS>/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base@<IP_ADDRESS>/java.lang.Thread.run(Thread.java:829)

pool-10-thread-2
  at java.base@<IP_ADDRESS>/jdk.internal.misc.Unsafe.park(Native Method)
  at java.base@<IP_ADDRESS>/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  at java.base@<IP_ADDRESS>/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  at java.base@<IP_ADDRESS>/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
  at java.base@<IP_ADDRESS>/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
  at java.base@<IP_ADDRESS>/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
  at java.base@<IP_ADDRESS>/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base@<IP_ADDRESS>/java.lang.Thread.run(Thread.java:829)

extended.openjdk / jvm_compiler / compiler/rtm/locking/TestRTMAbortRatio.java fails on test-docker-debian11-ppc64le-2
Rerun failed sanity testcases in Grinder/7473
Rerun failed extended testcase in Grinder/7474

s390x_linux

ppc64_aix

many test targets failing in sanity and extended openjdk with ZipException

This is interesting ... It's not consistent. Here are the results from the jdk_security1_1 target on various systems/versions:

Version
Machine
Result

<IP_ADDRESS>
test-docker-sles15-1
2 failures

<IP_ADDRESS>
test-marist-sles15-2
Pass

<IP_ADDRESS>
test-marist-ubuntu2204-1
1 failure

11.0.20
test-docker-sles15-1
???

<IP_ADDRESS>
test-docker-sles12-s390x-1
Pass

<IP_ADDRESS>
test-docker-sles15-1
???

<IP_ADDRESS>
test-marist-sles15-2
??? (10 iterations)

<IP_ADDRESS> test-marist-ubuntu2204-1
https://ci.adoptium.net/job/Grinder/7488/) (10 iterations)

This triage is now complete


Release Notes Change in format

Release notes

Last line = "See previous versions" - the line is the link to the file
Last line should not be a bullet on the list
Move version number to header - "Release Notes <IP_ADDRESS>" and delete the "Version" line
Feature names in bold
bugfixes i one word the name of the bug is a link to it on github

Example:

<IP_ADDRESS>


Add Sets Intersection and Union Operations

[x] All tests passed. If this feature is not already covered by the tests, I added new tests.
[x] This pull request is on the dev branch.
[x] I used gofmt for formatting the code before submitting the pull request.
[x] I labeled this pull request with one of the following: 'breaking change', 'new feature', 'bug', or 'ignore for release'

In the Gofrog package, sets data structures are exposed due to the absence of built-in sets in the Go language.