text:
test: Re-enable K8sValidatedKafkaPolicyTest KafkaPolicies

/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:270
Expected
    <*errors.errorString | 0xc4203b62a0>: {
        s: "ExecKafkaPodCmd: command 'kubectl exec -n default empire-hq-2687506128-k6wlc sh -- -c \"echo “Happy 40th Birthday to General Tagge” | ./kafka-produce.sh --topic empire-announce\"' failed '>>' || '[2018-03-31 05:50:21,834] ERROR Error when sending message to topic empire-announce with key: null, value: 42 bytes with error: (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)\norg.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.\n'",
    }
to be nil
/home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/k8sT/KafkaPolicies.go:223

Kafka runtime test hangs forever:
18:17:22 time="2018-03-31T18:17:21Z" level=debug msg="running command: sudo systemctl restart cilium"
18:17:22 time="2018-03-31T18:17:21Z" level=info msg=Starting testName=RuntimeKafka
18:17:22 time="2018-03-31T18:17:21Z" level=info msg="Vagrant: running command 'vagrant ssh-config runtime'"
18:17:22 time="2018-03-31T18:17:22Z" level=debug msg="generated SSHConfig for node runtime"
18:17:22 time="2018-03-31T18:17:22Z" level=debug msg="done importing ssh config"
18:17:22 time="2018-03-31T18:17:22Z" level=debug msg="running command: ls /tmp/"
18:17:28 time="2018-03-31T18:17:28Z" level=debug msg="running command: sudo cilium status"
18:17:28 time="2018-03-31T18:17:28Z" level=info msg="Cilium status is false" testName=RuntimeKafka
18:17:33 time="2018-03-31T18:17:33Z" level=debug msg="running command: sudo cilium status"
18:17:33 time="2018-03-31T18:17:33Z" level=info msg="Cilium status is true" testName=RuntimeKafka
18:17:33 time="2018-03-31T18:17:33Z" level=debug msg="running command: sudo docker network create --ipv6 --subnet ::1/112 --driver cilium --ipam-driver cilium cilium-net"
18:17:33 time="2018-03-31T18:17:33Z" level=info msg="setting PolicyEnforcement=default"
18:17:33 time="2018-03-31T18:17:33Z" level=debug msg="running command: sudo cilium config -o json | jq '.mutable.PolicyEnforcement'"
18:17:33 time="2018-03-31T18:17:33Z" level=debug msg="running command: sudo cilium config PolicyEnforcement=default"
18:17:33 time="2018-03-31T18:17:33Z" level=debug msg="spinning up container with command 'docker run -d --name zook --net cilium-net -l id.zook digitalwonderland/zookeeper'"
18:17:33 time="2018-03-31T18:17:33Z" level=debug msg="running command: sudo docker run -d --name zook --net cilium-net -l id.zook digitalwonderland/zookeeper"
18:17:34 time="2018-03-31T18:17:34Z" level=debug msg="spinning up container with command 'docker run -d --name client --net cilium-net -l id.client cilium/kafkaclient2'"
18:17:34 time="2018-03-31T18:17:34Z" level=debug msg="running command: sudo docker run -d --name client --net cilium-net -l id.client cilium/kafkaclient2"
18:17:36 time="2018-03-31T18:17:35Z" level=debug msg="running command: sudo docker inspect zook"
18:17:36 time="2018-03-31T18:17:35Z" level=debug msg="spinning up container with command 'docker run -d --name kafka --net cilium-net -l id.kafka -e KAFKA_ZOOKEEPER_CONNECT=10.15.129.91:2181 -e KAFKA_ZOOKEEPER_SESSION_TIMEOUT_MS=20000 -e KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS=20000 wurstmeister/kafka'"
18:17:36 time="2018-03-31T18:17:35Z" level=debug msg="running command: sudo docker run -d --name kafka --net cilium-net -l id.kafka -e KAFKA_ZOOKEEPER_CONNECT=10.15.129.91:2181 -e KAFKA_ZOOKEEPER_SESSION_TIMEOUT_MS=20000 -e KAFKA_ZOOKEEPER_CONNECTION_TIMEOUT_MS=20000 wurstmeister/kafka"
18:17:42 time="2018-03-31T18:17:41Z" level=debug msg="running command: cilium endpoint list -o jsonpath='{range [*]}{@.container-name}{\"=\"}{@.state}{\"\\n\"}{end}'"
18:17:42 time="2018-03-31T18:17:42Z" level=info msg="'0' containers are in a 'ready' state of a total of '4' containers." functionName=WaitEndpointsReady status="map[regenerating:4]" testName=RuntimeKafka
18:17:47 time="2018-03-31T18:17:46Z" level=debug msg="running command: cilium endpoint list -o jsonpath='{range [*]}{@.container-name}{\"=\"}{@.state}{\"\\n\"}{end}'"
18:17:47 time="2018-03-31T18:17:46Z" level=info msg="'4' containers are in a 'ready' state of a total of '4' containers." functionName=WaitEndpointsReady status="map[ready:4]" testName=RuntimeKafka
18:17:47 STEP: Setting up policy: /home/vagrant/go/src/github.com/cilium/cilium/test/runtime/manifests/Policies-kafka.json
18:17:47 time="2018-03-31T18:17:46Z" level=debug msg="running command: sudo cilium policy get -o json | jq '.revision'"
18:17:47 time="2018-03-31T18:17:47Z" level=info msg="before importing policy" file-path=/home/vagrant/go/src/github.com/cilium/cilium/test/runtime/manifests/Policies-kafka.json policyRevision=4 testName=RuntimeKafka
18:17:47 time="2018-03-31T18:17:47Z" level=debug msg="running command: sudo cilium policy import /home/vagrant/go/src/github.com/cilium/cilium/test/runtime/manifests/Policies-kafka.json"
18:17:53 time="2018-03-31T18:17:52Z" level=debug msg="running command: sudo cilium policy get -o json | jq '.revision'"
18:17:53 time="2018-03-31T18:17:52Z" level=debug msg="running command: sudo cilium policy wait 5"
18:17:53 time="2018-03-31T18:17:52Z" level=debug msg="running command: sudo cilium policy get -o json | jq '.revision'"
18:17:53 time="2018-03-31T18:17:52Z" level=info msg="policy import finished and revision increased" file-path=/home/vagrant/go/src/github.com/cilium/cilium/test/runtime/manifests/Policies-kafka.json policyRevision=5 testName=RuntimeKafka
18:17:53 time="2018-03-31T18:17:52Z" level=debug msg="running command: sudo cilium endpoint list -o json"
18:17:53 STEP: Creating kafka topics
18:17:53 time="2018-03-31T18:17:52Z" level=info msg="Creating new kafka topic allowedTopic" testName=RuntimeKafka
18:17:53 time="2018-03-31T18:17:52Z" level=debug msg="running command: docker exec -i  client /opt/kafka/bin/kafka-topics.sh --create --zookeeper zook:2181 --replication-factor 1 --partitions 1 --topic allowedTopic"
18:17:57 time="2018-03-31T18:17:56Z" level=info msg="Creating new kafka topic disallowTopic" testName=RuntimeKafka
18:17:57 time="2018-03-31T18:17:56Z" level=debug msg="running command: docker exec -i  client /opt/kafka/bin/kafka-topics.sh --create --zookeeper zook:2181 --replication-factor 1 --partitions 1 --topic disallowTopic"
18:18:00 STEP: Listing created Kafka topics
18:18:00 time="2018-03-31T18:18:00Z" level=debug msg="running command: docker exec -i  client /opt/kafka/bin/kafka-topics.sh --list --zookeeper zook:2181"
18:18:12 time="2018-03-31T18:18:10Z" level=debug msg="running command: docker exec -i  client echo \"Message 0\" | docker exec -i client /opt/kafka/bin/kafka-console-producer.sh --broker-list kafka:9092 --topic allowedTopic"
18:19:21 STEP: Allowed topic
18:19:21 STEP: Sending produce request on kafka topic `allowedTopic`
18:19:21 time="2018-03-31T18:19:12Z" level=debug msg="running command: echo Message 1 | docker exec -i client /opt/kafka/bin/kafka-console-producer.sh --broker-list kafka:9092 --topic allowedTopic"
18:20:19 time="2018-03-31T18:20:14Z" level=debug msg="running command: echo Message 2 | docker exec -i client /opt/kafka/bin/kafka-console-producer.sh --broker-list kafka:9092 --topic allowedTopic"
18:21:17 time="2018-03-31T18:21:15Z" level=debug msg="running command: echo Message 3 | docker exec -i client /opt/kafka/bin/kafka-console-producer.sh --broker-list kafka:9092 --topic allowedTopic"
18:22:26 time="2018-03-31T18:22:16Z" level=debug msg="running command: echo Message 4 | docker exec -i client /opt/kafka/bin/kafka-console-producer.sh --broker-list kafka:9092 --topic allowedTopic"
18:23:23 time="2018-03-31T18:23:18Z" level=debug msg="running command: echo Message 5 | docker exec -i client /opt/kafka/bin/kafka-console-producer.sh --broker-list kafka:9092 --topic allowedTopic"
18:24:21 STEP: Sending consume request on kafka topic `allowedTopic`
18:24:21 time="2018-03-31T18:24:19Z" level=debug msg="running command: docker exec -i  client /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server kafka:9092 --topic allowedTopic --max-messages 6 --timeout-ms 300000 --from-beginning"

WIP https://github.com/cilium/cilium/pull/3456
Already spoke with @rlenglet  around the issue

authors: eloycoto tgraf


text:
docs: Explain test-focus CI trigger

We've had test-focus for some time but haven't documented it.
One issue to consider: test-focus updates the PR such that if it passes, the PR can be merged without passing the full test suite. It might be best to create a new status field on the PR for focussed tests.

test-docs-please

Coverage decreased (-0.003%) to 45.425% when pulling 9bc6691cbc74b3a9ac701b5af8372acf25cd31d6 on raybejjani:docs-test-focus into 8fd7415406c0ac2ee93e74d36377f1e9dcf7e112 on cilium:master.

test-docs-please

@pchaigno I updated the job link in the table, if you wanted to take another look. test-focus now has it's own jenkins job to avoid confusion. I'll probably merge anyway at some point since any mistake I made can be fixed.

test-focus K8sDemosTest.*

Thanks for the ping! I wanted to re-review after the Slack message but forgot.
LGTM!

source: gharchive/pull-request

authors: coveralls pchaigno raybejjani

repo: cilium/cilium

license_type: permissive

license_source: github-api


text:
docs: remove misplaced sentence from Quick Installation guide

Hi there 👋 , while following the Cilium installation guide I noticed that in the Install Cilium step, there seems to be a sentence that belongs to the previous step. This PR removes that sentence to avoid confusion. No need to move the sentence to the previous step as it is already clear.
Fixes: #15970
Signed-off-by: Lorenzo Fundaró lorenzofundaro@gmail.com

Good catch, thank you for your contribution!

happy to help ! 😄


text:
Revert "config: Fix incorrect packet path with IPsec and endpoint rou…

…tes"
This reverts commit 7ef59aa9d7d059998ad1a8b4e1c552447090c3d1.
After performing a git bisect where connectivity test had to pass 3
times consecutively this commit was the first that hit the current
ci-aks failures that we have been having in our CI, thus it is being
reverted.
Signed-off-by: André Martins andre@cilium.io
cc @pchaigno

ci-aks

ci-aks has passed https://github.com/cilium/cilium/runs/3247037335

test-me-please

/mlh new-flake Cilium-PR-K8s-1.16-net-next

Merging to unblock other PRs that are blocked by https://github.com/cilium/cilium/issues/17022 and opened https://github.com/cilium/cilium/issues/17060 to track the current flake.


text:
Upgrade ginkgo

Signed-off-by: pigletfly wangbing.adam@gmail.com
Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[ ] Thanks for contributing!

Fixes: https://github.com/cilium/cilium/issues/19687

Thanks for your contribution! It looks like some of the failures are legit, e.g.:
 #27 10.69 ../test/ginkgo-ext/scopes.go:78:58: cannot use ginkgo.Context (variable of type func(text string, args ...interface{}) bool) as type func(string, func()) bool in argument to wrapContextFunc

Thanks for your contribution! It looks like some of the failures are legit, e.g.:
 #27 10.69 ../test/ginkgo-ext/scopes.go:78:58: cannot use ginkgo.Context (variable of type func(text string, args ...interface{}) bool) as type func(string, func()) bool in argument to wrapContextFunc

yes, I am working on this. It seems there are some incompatible changes.

@pigletfly Are you still working on this? It looks like the branch picked up a merge conflict and needs a rebase. I'll mark the PR as draft until this is resolved. Please feel free to mark the PR ready to review once the merge conflicts and the build failures are resolved.

@pigletfly Are you still working on this? It looks like the branch picked up a merge conflict and needs a rebase. I'll mark the PR as draft until this is resolved. Please feel free to mark the PR ready to review once the merge conflicts and the build failures are resolved.

rebased, and I will finish the ginkgo upgrade ASAP.

authors: pigletfly rolinh tklauser


text:
users/exoscale

Add Exoscale SKS to users list
Signed-off-by: Antoine Coetsier acr@exoscale.ch
Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[ ] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[x] Thanks for contributing!

Adds Exoscale SKS to the list of users following the official integration and announcement https://changelog.exoscale.com/en/cilium-cni-sks
Support for Cilium in Exoscale SKS

Thanks for adding @retrack 🐝

authors: retrack xmulligan


text:
Fix compilation error when enabling Wireguard and XDP

This PR fixes the compilation failure of bpf_xdp.o when enabling Wireguard with XDP by adding a guard for Wireguard and XDP. Also, it shows a warning message to alert users about certain traffic(between an intermediate node and a backend node)
not being encrypted.
Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[x] Are you a user of Cilium? Please add yourself to the Users doc
[x] Thanks for contributing!

Fixes: #25354

It seems that we need to exclude cilium_wg0 from the target devices when XDP acceleration is enabled
level=fatal msg="Failed to compile XDP program" error="program cil_xdp_entry: attaching XDP program to interface cilium_wg0: operation not supported" subsys=datapath-loader

/test

ConformanceKindEnvoyDaemonSet seems to be stabilized by https://github.com/cilium/cilium/pull/26260

K8sUpstreamNetConformance is unstable. It has been reported here
https://cilium.slack.com/archives/C7PE7V806/p1686843215310069

/test

/ci-multicluster

/ci-multicluster

I don't see any jenkins jobs. Do we no longer run the Jenkins jobs?

I don't see any jenkins jobs. Do we no longer run the Jenkins jobs?

Noup, they got moved to the new ci-ginkgo GHA :sunglasses:

Noup, they got moved to the new ci-ginkgo GHA 😎

Great! It's a tremendous boost to development productivity, isn't it?

/test

Hit https://github.com/cilium/cilium/issues/25816

/ci-multicluster

authors: brb ysksuzuki


text:
Documentation: Fix Envoy LB docs incorrect supported annotation values

There is a one-liner example that advices adding correct service.cilium.io/lb-l7=enabled annotation, but the table with supported annotations has a typo with incorrect envoy option instead of enabled.

Could you please rebase on top of the current main branch? I believe the documentation builds were broken (then fixed) recently, and it would be nice to ensure the Netlify preview builds correctly before merging this PR.

I messed it up with the merge commit, that's what you get for using github UI. Will try to fix the tree.

Nice. https://deploy-preview-26867--docs-cilium-io.netlify.app/network/servicemesh/envoy-load-balancing.html#supported-annotations

authors: qmonnet rauanmayemir


text:
fqdn: avoid converting from netip.Addr to net.IP and back

Change (*DNSCache).Lookup and (*DNSCache).LookupByRegex to return netip.Addr. This avoids a back-and-forth conversion to net.IP and allows to drop some now unused helper functions in pkg/ip.
See commits for details.
Towards: #24246

/test

/test

Dropped the backport labels based on https://github.com/cilium/cilium/pull/29863#issuecomment-1854108601


text:
Centralize configuration of kind version/image in GitHub Action workflows

Let's define kind-related variables (i.e., version, k8s image and k8s version) inside the set-env-variables action. This ensures consistency across workflows, simplify version bumps as well as the introduction of new workflows depending on them. One extra byproduct is that renovate updates will also stop requesting reviews from all the different teams owning each specific workflow. Additionally, let's also stop waiting for kind clusters to become ready, as they will never, because no CNI is present at that point.
Note: a few pull-request based workflows are currently failing, because they use the set-env-variables checked out from the main branch, which doesn't contain the additional variables. This will be fixed after merging this PR.
Centralize configuration of kind version/image in GitHub Action workflows

/test

/test

/test

/ci-e2e-upgrade

Converting back to draft. The image seems not to be correctly picked by LVH-based workflows.

/test

/ci-e2e-upgrade

Fixed. Back to reviewable

LGTM but I would like to have @brlbil's review to check if this affects the fact that ariane skips test runs because we will start to only modify .github/actions/set-env-variables/action.yml instead of the specific workflows.

My understanding is that tests are not skipped if any file in addition to workflow files is modified, as it would be necessary to start tracking dependencies. And the same would have applied today as well, as most workflows relied on the image hard-coded in the kind config file, rather than specifying it themselves.

/test

/ci-e2e-upgrade

Reviews are in, workflow failures are either expected (as changes need to land on main first) or unrelated. Marking ready to merge.


text:
ingress: Support headless service

Currently, we don't inject headless endpoints into envoy XDS, hence the response is coming with error no healthy upstream. This commit is to explicitly handle headless service in CEC controller.

/ci-ingress


text:
ci: Disallow parallel execution of privileged test

Please ensure your pull request adheres to the following guidelines:

[ ] For first time contributors, read Submitting a pull request
[ ] All code is covered by unit and/or runtime tests where feasible.
[ ] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[ ] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[ ] All commits are signed off. See the section Developer’s Certificate of Origin
[ ] Provide a title or release-note blurb suitable for the release notes.
[ ] Are you a user of Cilium? Please add yourself to the Users doc
[ ] Thanks for contributing!

Fixes: #issue-number
<!-- Enter the release note text here if needed or remove this section! -->

/ci-runtime


text:
Add helm schema

This PR is a requirement for https://github.com/cilium/cilium/pull/30631
Changes

Update golang to 1.21.7 (required for building helm-schema)
Install ubergesundheit/helm-schema

I've pushed the container image to quay.io/geraldpape/helm-toolbox:v1.1.0 to work with it in the other PR

The required functionality was released as version 0.9.0 in dadav/helm-schema
I've built and published the container image as quay.io/geraldpape/helm-toolbox@sha256:44006b7a4ff1efa57cd3100369bd6ff39e9f2de6340594a596bfce3e954d1a36

repo: cilium/helm-toolbox


text:
Avoid deprecation warning in Target

Target#notice still called the deprecated Target#msg.

Merged as e4e33ce, thank you.

authors: britishtea dominikh

repo: cinchrb/cinch

license: mit

license_source: bigquery


text:
🛑 CHPL Main Web Site / BiblioWeb is down

In b274247, CHPL Main Web Site / BiblioWeb (https://cincinnatilibrary.org/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CHPL Main Web Site / BiblioWeb is back up in b6e8f16.

source: gharchive/issue

repo: cincinnatilibrary/uptime-reports

license: MIT


text:
⚠ Cioos Pacific CKAN Sitemap has degraded performance

In 9ed4f78, Cioos Pacific CKAN Sitemap (https://catalogue.cioospacific.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 12018 ms

Resolved: Cioos Pacific CKAN Sitemap performance has improved in 4e9f608 after 48 minutes.

repo: cioos-siooc/cwatch-upptime


text:
🛑 Cioos Atlantic CKAN Sitemap is down

In ff24a7b, Cioos Atlantic CKAN Sitemap (https://catalogue.cioosatlantic.ca/sitemap/sitemap-1.xml) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Cioos Atlantic CKAN Sitemap is back up in 31c246f after 6 minutes.


text:
Update sbt to 1.7.2

Updates org.scala-sbt:sbt from 1.6.2 to 1.7.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scala-sbt", artifactId = "sbt" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #209.

repo: circe/circe-golden


text:
Introduce gotestsum for the golang images

Checklist

[x] I've run make from the root directory to see all Dockerfiles are created successfully.
[x] I've updated the documentation if necessary.

Motivation and Context
This PR relates to https://github.com/circleci/circleci-images/issues/259
Description
We are now installing gotestsum v0.3.1(https://github.com/gotestyourself/gotestsum/releases) in our Golang images in /go/bin.

@ryanwohara This ready to merge?

Everyone has approved this so I'm merging. Feel free to revert if there's a serious reason against.

authors: felicianotech ryanwohara

repo: circleci/circleci-images


text:
Enable Synthetic Spreads for the Kobo Forma.

Rotating the device into landscape mode will cause it to display two
pages side by side. This is particularly useful for input comics whose
spreads are already split into two files.
See https://github.com/kobolabs/epub-spec#synthetic-spreads for
additional information on synthetic spreads.
(Tiny drive-by: Add Kobo format to list of profiles for which the AUTO
format is EPUB)

Open question: Should we enable this for other Kobo devices?
I hope they would fallback gracefully if they don't fully support the spec, but I've excluded them from this commit since I don't have any to test one.

Thanks I will investigate this topic during refactoring.
I don't have access to any Kobo hardware so entire Kobo support is dry coded.

@shavitmichael
thanks
merged in v5.6.1
I don't own a Kobo Forma to test though

authors: AcidWeb darodi shavitmichael

repo: ciromattia/kcc

license: ISC


text:
Create Assessment Data Export VM from code

🚀 Feature Proposal
Write code to create a VM whose sole purpose is to export assessment data.
Motivation
The current VM that is used for this purpose was built manually and it must be manually maintained (security patches, etc.)  Automating the creation of this VM will allow us to quickly and regularly create and deploy an up-to-date, secure VM.
Example
Write packer/ansible/terraform code to build/deploy a vSphere VM with only the bare minimum software needed to run the assessment data export code.
Pitch
Having hand-crafted "artisanal" instances is old-school and lame (a.k.a. inefficient and insecure).  Infrastructure-as-code is the New Hotness. 🔥

Instead of a new instance to run the code, converting the code to run in a Lambda would be better

repo: cisagov/assessment-data-export


text:
changed a couple of link targets in the README table

Related issues
Refs: none
Describe the changes made in this pull request

The CLI row, validation and conversion columns in the README table now point to PyPI for cffconvert
The GitHub action row, conversion column in the README table now point to GitHub Actions Marketplace for cffconvert

Instructions to review the pull request

click the links in the table in the README.md

Thanks for reviewing!


text:
Ensure ASCII citekeys for BibTeX entries

This PR ensures that the citekey (formerly 'reference') for a BibTeX entry only has ASCII characters in it, as per the spec. It does not encode the citekey string in ASCII; it remains encoded as UTF-8. It only really handles Latin and Latin-like characters properly, but seeing as we're firmly in the realms of academic literature here - which is mostly in English - this is more than likely OK.
This code provides a simplified reimplementation of parameterize from ActiveSupport::Inflector backed up by a simplified reimplementation of I18n.transliterate. In #96 we talked about providing a best-effort solution to this issue by default, and using ActiveSupport when available, but really I think this implementation is so similar that this is no longer necessary. All that using ActiveSupport would give us extra is the ability to override certain localized transliterations, which, for the purposes of a auto-generated citekey, are almost certainly overkill. We certainly don't want to add ActiveSupport as a required dependency.
Fixes #96

Coverage remained the same at 100.0% when pulling dd7e13de808a531a35210706c4619f83f62da195 on ascii-citekeys into abf1f14dc59f06e4ac939a17921ee5d5db202e5d on main.

Ace, thanks @arfon!

There is no special handling for ö as in Schrödinger. Is this implicit?

ö is converted to o. I realise that ö has different conversions depending on the locale, including in some cases oe, but for the purposes of auto-generating a citekey, keeping the code as simple as possible, and not adding dependencies to the library, we can't take every transliteration into account, sorry.

@hainesr this PR and https://github.com/citation-file-format/ruby-cff/pull/95 are now live in production on GitHub.

authors: arfon coveralls hainesr nschloe

repo: citation-file-format/ruby-cff


text:
Refactor JsonExporter

Description
Please explain the changes you made here.
Release notes
The title of the pull request will be used as the default release notes description. If more detail is needed to communicate to partners the scope of the PR's changes, use this release notes section.
Checklist
General
Read the full guidelines for PRs here

[ ] Added the correct label: < feature | bug | dependencies | infrastructure | ignore-for-release | database >
[ ] Created unit and/or browser tests which fail without the change (if possible)
[ ] Performed manual testing (Chrome and Firefox if it includes front-end changes)
[ ] Extended the README / documentation, if necessary

User visible changes

[ ] Followed steps to internationalize new strings
[ ] Wrote browser tests using the validateAccessibility method
[ ] Tested on mobile view. See mobile device mode
[ ] Manually tested at 200% size
[ ] Manually evaluated tab order

New Features

[ ] Add new FeatureFlag env vars to server/conf/helper/feature-flags.conf
[ ] Conditioned new functionality on a FeatureFlag
[ ] Wrote browser tests with the feature flag off and on, etc.

Instructions for manual testing
If instructions are needed for manual testing by reviewers, include them here.
Issue(s) this completes
Fixes #<issue_number>; Fixes #<issue_number>...

Current dependencies on/for this PR:

main

PR #5444   👈

This comment was auto-generated by Graphite.

repo: civiform/civiform


text:
Remove unnecessary call to syncProgramDefinitionQuestions(ProgramDefinition programDefinition)

Description
Please explain the changes you made here.
Release notes
The title of the pull request will be used as the default release notes description. If more detail is needed to communicate to partners the scope of the PR's changes, use this release notes section.
Checklist
General
Read the full guidelines for PRs here

[ ] Added the correct label: < feature | enhancement | bug | dependencies | infrastructure | ignore-for-release | database >
[ ] Assigned to a specific person, civiform/developers, or a more specific round-robin list.
[ ] Created unit and/or browser tests which fail without the change (if possible)
[ ] Performed manual testing (Chrome and Firefox if it includes front-end changes)
[ ] Extended the README / documentation, if necessary

User visible changes

[ ] Followed steps to internationalize new strings
[ ] Wrote browser tests using the validateAccessibility method
[ ] Tested on mobile view. See mobile device mode
[ ] Manually tested at 200% size
[ ] Manually evaluated tab order

New Features

[ ] Add new FeatureFlag env vars to server/conf/helper/feature-flags.conf
[ ] Conditioned new functionality on a FeatureFlag
[ ] Wrote browser tests with the feature flag off and on, etc.

Instructions for manual testing
If instructions are needed for manual testing by reviewers, include them here.
Issue(s) this completes
Fixes #<issue_number>; Fixes #<issue_number>...

Current dependencies on/for this PR:

main

PR #6244   👈

PR #6245

This stack of pull requests is managed by Graphite.


text:
Add error messages to file upload

Description
Please explain the changes you made here.
Release notes
The title of the pull request will be used as the default release notes description. If more detail is needed to communicate to partners the scope of the PR's changes, use this release notes section.
Checklist
General
Read the full guidelines for PRs here

[ ] Added the correct label: < feature | enhancement | bug | under-development | dependencies | infrastructure | ignore-for-release | database >
[ ] Assigned to a specific person, civiform/developers, or a more specific round-robin list
[ ] Added an additional reviewer from outside your organization as FYI (if the primary reviewer is in the same organization as you)
[ ] Created unit and/or browser tests which fail without the change (if possible)
[ ] Performed manual testing (Chrome and Firefox if it includes front-end changes)
[ ] Extended the README / documentation, if necessary

Database evolutions
Read the guidelines here

[ ] Assigned two reviewers
[ ] Guarded against already existing resources using IF NOT EXISTS and IF EXISTS
[ ] Downs created to undo changes in Ups

User visible changes

[ ] Followed steps to internationalize any new strings

[ ] Added context strings to new messages
[ ] Didn't use a message in applicant facing code that isn't translated yet (unless behind a flag)

[ ] Wrote browser tests using the validateAccessibility method
[ ] Tested on mobile view. See mobile device mode
[ ] Manually tested at 200% size
[ ] Manually evaluated tab order

New Features

[ ] Add new FeatureFlag env vars to server/conf/helper/feature-flags.conf
[ ] Conditioned new functionality on a FeatureFlag
[ ] Wrote browser tests with the feature flag off and on, etc.

Instructions for manual testing
If instructions are needed for manual testing by reviewers, include them here.
Issue(s) this completes
Fixes #<issue_number>; Fixes #<issue_number>...

#7940  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @greg-hyde and the rest of your teammates on  Graphite


text:
Can we use julia functions with ! postfix in python calls to julia functions

Hopefully clear in the title. It seems python does not like the ! postfix in function names and I wonder if there is a pythonic way to call a julia function with ! char e.g jl.update!(p) ? I guess using seval would be an option but I would like to pass in a python variable to the julia function.

As a special case, the suffix _b is translated to ! so you can do jl.update_b(p) (b is for bang).
You could also do getattr(jl, "update!") or jl.getproperty(jl, jl .Symbol("update!")).

Or jl.seval("update!")(b).

Thanks very much, that works well.

authors: cjdoris markNZed


text:
Configuration architecture ideas

Thinking about how the user will interact with configuring the gem, my current thought is to have one generator that, when run, will  create a single initializer file at:
# app/config/initializers/petri_dish.rb

which will populate the file with a call to configure the gem, this has all options enabled by default, and users can change any options to false that they don't desire to use. Here is an example of how that file would look:
# app/config/initializers/petri_dish.rb

PetriDish.configure do |config|
  config.request_specimen = true
  config.query_specimen = true
  config.another_specimen = false
  config.another_specimen = true
  ...
end

Here is an initial layout of the main PetriDish module that would live in lib/petri_dish.rb in the gem.
module PetriDish
  class << self
    attr_accessor :request, :query

    def configure
      yield self
      process_configuration
    end

    def configure_request
      # Perfom Request Specimen setup work i.e. setup the ActiveSupport::Instrumentation subscription
    end

    def configure_query
      # Perfom Query Specimen setup work i.e. setup the ActiveSupport::Instrumentation subscription
    end

    # Other specimen objects setup methods

    private

    # Just a thought of what needs to happen to use the configuration options to call the configure_ methods
    def process_configuration
      instance_variables.each do |ivar|
        if instance_variable_get(ivar)
          method_name = "configure_" + ivar.slice(1..-1)
          send(method_name)
        end
      end
    end
  end
end

Hey Collin, I've been  going over the gem and your notes. Seems like setting PetriDish components to truth in petri_dish.rb will call their given methods and in turn set up the given Specimen?
Will these setting will be done after the generator has been runned?
I'm thinking that at this point the generator has already generated views and links?
And if so, is it better to generate all views by default?
If user wants to customize, aside from petri_dish.rb,  they'll have to 'comment out' whatever views/links?

So after quickly refreshing myself on things here, I'm thinking that perhaps the flow may be to have two generators. One that creates the default initializer file with everything enabled by default. This will let the user go into that file and turn off what they don't want if anything, and then run the second generator that would look at what features (specimens) are enabled (set to true) and then create views, etc for only those.

This approach makes sense to me. I was thinking about a Devise approach where we have the install generator and then a generator per specimen. Your approach is much better, though.
But thinking about the next step/PR, it seems like it could be a number of different things.
Should I work on the specimens_generator? From the top of my head

change the petri_dish initializer to false by default.
the specimen_generator looks into the petri_dish initializer and generate the controllers and views of specimens set to true


text:
improve handling of noscript (related to #349)

This is a rough attempt at improving the behavior of cla-assistant as seen by browsers that render <noscript>
Currently the rendering looks like this:

(That the username disappears long before the brand logo is a little odd, but we can cross the mobile bridge later.)

@KharitonOff : the message can be adjusted...

Ok, I see. If we make it clear in a  tag that CLA assistant needs JS in order to work properly, then it makes sense for me.

If you want to write that text, I can integrate it, or you can merge this and work from it.

authors: KharitonOff jsoref

repo: cla-assistant/cla-assistant


text:
41 display highlight area on the minimap

resolves #41
Description
This ticket is the second part of the previous issue 12. This PR implements the feature to add a highlight area on the minimap, which can be adjusted in size and position based on normalized coordinates calculated in Ticket #65.
Changes
The following changes were made in cellpose/gui/guiparts.py:

Added set_highlight_area method to the MinimapWindow class:

Calculates the position and size of the highlight area based on normalized coordinates.
Caps the width and height of the highlight area to ensure it does not exceed the minimap size.
Sets the position and size of the highlight area on the minimap.

Integrated the highlight area into the minimap as a pg.RectROI object:

Created and added a rectangle highlight area to the minimap.
Set the highlight area with an initial position of [0, 0] and size [100, 100], outlined in white with a 3-pixel width.

Testing
To test the highlight area, you can change the normalized values for the coordinates and dimensions in the method call self.set_highlight_area(normalized_x, normalized_y, normalized_width, normalized_height) within the MinimapWindow(QDialog) class to draw a rectangle at the corresponding position and size.

Thank you for your review. I have fixed the issues. The only remaining issue might be the error message: "An error occurred while changing the view: 'NoneType' object has no attribute 'shape'." This started to occur after the merge commit d79395e.

repo: claassenlab/cellpose


text:
Can not identify C++ standard in STL headers when using MSVC compiler

I use clangd and CMake Tools in VScode. And I found clang can't identify C++ standard (e.g. macro _HAS_CXX17, _HAS_CXX23 ...) in STL headers when using MSVC compiler (but can identify when using Clang and GCC compilers) which is inconsistent and affects view and study the source code.
Simple reproduce codes
// main.cpp
#include <filesystem>
#include <iostream>
#include <string_view>

int main(int argc, const char **argv) {
  std::cout << std::string_view("string_view test") << std::endl;
  std::cout << std::string_view("filesystem test ")
            << std::filesystem::exists("main.exe") << std::endl;
  std::cout << std::string_view("__cplusplus test ") << __cplusplus
            << std::endl;
#ifndef __GNUG__
  std::cout << std::string_view("_HAS_CXX17 ") << _HAS_CXX17
            << std::endl; // ONLY FOR MSVC AND CLANG
  std::cout << std::string_view("_HAS_CXX23 ") << _HAS_CXX23
            << std::endl; // ONLY FOR MSVC AND CLANG
#endif                    // __GNUG__

  return 0;
}

# CMakeLists.txt
project(app LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)

if(CMAKE_CXX_COMPILER_ID MATCHES "MSVC")    # ONLY FOR MSVC AND YOU CAN DELETE THESE
    add_compile_options("-Zc:__cplusplus")
endif()

add_executable(main main.cpp)

Screenshots

Using MSVC

Using Clang or CGG

Logs

compile_commands.json when using MSVC

[
{
  "directory": "E:/Workspace/CPP/CPP-T001/.out/build/MSVC-x64-REL",
  "command": "C:\\PROGRA~1\\MIB055~1\\2022\\PROFES~1\\VC\\Tools\\MSVC\\1434~1.319\\bin\\Hostx64\\x64\\cl.exe  /nologo /TP /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -MD -Zc:__cplusplus -std:c++latest /FoCMakeFiles\\main.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB /FS -c E:\\Workspace\\CPP\\CPP-T001\\main.cpp",
  "file": "E:\\Workspace\\CPP\\CPP-T001\\main.cpp"
}
]

compile_commands.json when using clang

[
{
  "directory": "E:/Workspace/CPP/CPP-T001/.out/build/CLANG-x64-REL",
  "command": "C:\\PROGRA~1\\LLVM\\bin\\CLANG_~1.EXE -O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -std=gnu++2b -o CMakeFiles\\main.dir\\main.cpp.obj -c E:\\Workspace\\CPP\\CPP-T001\\main.cpp",
  "file": "E:\\Workspace\\CPP\\CPP-T001\\main.cpp"
}
]

compile_commands.json when using GCC

[
{
  "directory": "E:/Workspace/CPP/CPP-T001/.out/build/GCC-x64-REL",
  "command": "C:\\DEV\\TDM-GCC-64\\bin\\g++.exe -O3 -DNDEBUG -std=gnu++2a -o CMakeFiles\\main.dir\\main.cpp.obj -c E:\\Workspace\\CPP\\CPP-T001\\main.cpp",
  "file": "E:\\Workspace\\CPP\\CPP-T001\\main.cpp"
}
]

System information
Output of clangd --version:
clangd version 15.0.7
Features: windows
Platform: x86_64-pc-windows-msvc

Editor/LSP plugin:
VScode, clangd, CMake Tools

Operating system: Windows 11 22621.1105

I'm not sure to what extend clangd supports interpreting cl.exe compile commands.
Is there an issue with just using the clang version of the compile_commands.json? It does not mean you have to build with clang.

I'm not sure to what extent clangd supports interpreting cl.exe compile commands.
Is there an issue with just using the clang version of the compile_commands.json? It does not mean you have to build with clang.

Is this??
[
{
  "directory": "E:/Workspace/CPP/CPP-T001/.out/build/CLANG-x64-REL",
  "command": "C:\\PROGRA~1\\LLVM\\bin\\CLANG_~1.EXE -O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -std=gnu++2b -o CMakeFiles\\main.dir\\main.cpp.obj -c E:\\Workspace\\CPP\\CPP-T001\\main.cpp",
  "file": "E:\\Workspace\\CPP\\CPP-T001\\main.cpp"
}
]

I've got it.
I think it is the problem of -std:c++latest in compile_commands.json when using MSVC.
The -std:c++latest in compile_commands.json is generated when I use CMakeLists.txt set(CMAKE_CXX_STANDARD 23) with compiler MSVC. And when I changed it to set(CMAKE_CXX_STANDARD 20), in compile_commands.json generate -std:c++20, and the problem (STL headers can't identify C++ standard) solved.
So I think clangd can't parse this -- -std:c++latest.

So I think clangd can't parse this -- -std:c++latest.

Indeed: https://github.com/clangd/clangd/issues/527

Indeed: #527

Thank you!

repo: clangd/clangd


text:
Type information in hover response useless in some cases

Right now clangd just echoes the declaration line, which is mostly fine, except in two cases:

auto it = some_struct_type.member_array.begin();

Echoing this line is not very useful, because the user wouldn't find out what is the actual type of the iterator and so it becomes hard to find out what is the type returned by operator*.
Discovering the value_type of member_arry isn't that difficult, unless it's defined in some large generated file that makes every editor choke (except vim in compatible mode).

Another case where hover response is not very useful is with super long braced init-lists.

More specifically, on this line, the hover response is completely useless, because code_points is declared like this.
On the other hand, ycmd's libclang based completer can retrieve type with auto resolved.  https://github.com/Valloric/ycmd/blob/master/cpp/ycm/ClangCompleter/TranslationUnit.cpp#L308

Agree, returning the type as written is nice in some cases (it's usually terse!) but is catastrophically bad for auto and... mixed at best for things like value_type.
The YCM + libclang logic looks more sensible at first glance, we may also be able to enhance some cases further with access to the C++ API.

Ah, so I'd forgotten the tricky issue here.
As you've seen there's no "type information" request in LSP, just the "hover" request with as unstructured response.
I think the idea behind our current hover responses is that pretty-printing the decl gives a sense of:

the kind of thing that's being hovered (a variable?)
a sense of where it came from (namespace?)
its type (int?)
its definition (= 42)
its documentation, maybe

But it's not doing a great job of any of these, and then we've bound the response to :YcmCompleter GetType where users rightly expect a detailed type and nothing else.
I think we need to internally build a structured representation of the hover information, with proper detailed type info. Then we can render a nicer hover response, and probably also provide something more suitable for GetType as an extension.
Assigning to @kadircet as he's starting to look at improving hover.

Yes, textDocument/Hover is one of my least favourite parts of the protocol in general.
Here's a proposal how structuring Hover could work:

Return an array of MarkedStrings
First MarkedString can be a dictionary { "language": "cpp", "value": type_information }
Every other MarkedString should be used for documentation (YCM's GetDoc)

Alternatively, instead of sending an array of strings, send one large string with embedded new lines.

That is what jdt.ls returns when both type and documentation information is available. When one of those isn't available, it might return just the dictionary or just the list of strings.

We'll need to make sure that as well as having accessible structure, they look good when rendered by clients naive to that structure.
There's also the issue that the MarkedString[] response is deprecated, so a MarkupContent might be preferable.
So another option would be to add extensions to MarkupContent like:
  "kind": "markdown",
  "value": "function ns::**foo**(v)\n\nsome doc\n\n```cpp\nvoid foo(int v);",
   "name": "foo",
   "scope": "ns::",
   "type": "void(int)",
   "category": "function",
   "definition": "void foo(int v);",
   "documentation": "some doc",
}```

That way we can still provide a nicely-formatted string and tweak the layout over time, but YCM can properly support `GetType` without any brittle parsing.

Alternatively, we could hide all this extra structure in clangd and just define new methods to get at the type.

I don't see MarkedString declared deprecated anywhere in the protocol specifications, even though it is older than MarkupContent.
I'm personally not a fan of markup hover response, because the editor I care about (vim) doesn't have a markup parser (at least by default).

I see this on the definition of MarkedString: @deprecated use MarkupContent instead.
MarkupContent can be plain text (and will be if the client doesn't advertise markdown support via capabilities)

This is partially addressed in https://github.com/llvm/llvm-project/commit/287a874d1c460302677a1530a75d94bae4d4a348.
I say partially because we still miss pretty printing for auto types and handling of long initializer lists.
but at least, we know print the underlying type when hovering over auto typed variables.
Note that this also changes the hover output, so with next clangd release :YcmCompleter GetType functionality might need to be adjusted, happy to chat about it more.

Is there any chance to resolve the type of a lambda auto parameter?
foo([](auto p){});

Btw is this a duplicate of #58?

Is there any chance to resolve the type of a lambda auto parameter?
foo([](auto p){});

I believe that depends on the signature of foo. If the parameter type is a concrete function pointer type (e.g. void(*)(int)) and the lambda has no captures (so that it can be converted to a function pointer), then yes, we should be able to determine what the type of the instantiated parameter p for the call will be.
It's probably worth having this case on file as a separate issue, as it's kind of a special case / not the typical case of deducing auto from an initializer.

As Kadir mentioned, type information is now split out from the declaration (for quite a while now!). I think that's the core issue here, so we should close this bug.
I've opened separate bugs for the other issues raised here:

huge initializers #710
sugar on auto variables #709


text:
🛑 Data Portal is down

In e792393, Data Portal (https://data.nsercresnet.ca) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Data Portal is back up in 8ef2eb5 after 9 minutes.

repo: clarkwrks/resnet-status


text:
Slash-command Framework

Working on a command framework to automatically accept message and slash commands, but Serenity/Rust is making this so much harder than I thought it would.
UNObot (C# via Discord.NET) has a generic-based framework but involves a ton of reflection, which isn't viable in Rust. https://github.com/DoggySazHi/UNObot/blob/master/src/UNObot/Services/CommandHandlingService.cs
It might be easier to re-implement most of the StandardFramework but replace the dispatch function. But then we would need a unified way for the framework to emit messages (interaction response, channel message, or reply). I've tried making a mixin for the Message class, but I'm not proficient enough with dealing with async lifetime bounds for this. Todo...

I'll take a look on Friday.

Yeah... I'm having a hard time with this. Each command would need to know if it's a slash command, meaning either we add a field to the Context or Message, or we add an extra argument to the command's function.
As for unifying the command's responses, I was thinking on just using a ton of macros, given that we know if a command was invoked as a slash command.
How are you creating a mixin for Rust structs?

We can make it an attribute, annotating each function with a custom
#[SlashCommand] annotation. Then we can load functions that have such
attributes and create the commands in Discord.
For mix-ins, I just defined a trait (AutoResponse) and made Message
impl the trait. Basically a mix-in. But I guess a macro would work as
well. I just want to reuse the same implementation but add extra attributes
to make it a slash command, so it must be aware of the context (how it was
invoked).
On Fri, Sep 2, 2022, 7:00 PM Andrew Lin @.***> wrote:

Yeah... I'm having a hard time with this. Each command would need to know
if it's a slash command, meaning either we add a field to the Context or
Message, or we add an extra argument to the command's function.
As for unifying the command's responses, I was thinking on just using a
ton of macros, given that we know if a command was invoked as a slash
command.
How are you creating a mixin for Rust structs?
—
Reply to this email directly, view it on GitHub
https://github.com/classAndrew/cow/issues/7#issuecomment-1236024703, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKCD7WGH7XJYOI2HKRJSCYTV4KWMZANCNFSM6AAAAAAQC6TPAQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Turns out there's a semi-official way to make slash commands (https://docs.rs/poise/latest/poise/) using Serenity, although it's still experimental. I've continued work on our own command handler, but it may be easier to use something else.

OK, so I've got Poise to work (see 1ff12acb) and I'm currently testing it out. Embeds aren't overwritten for some reason, so I'll have to debug it even further. Hopefully I'll merge it into main soon.

authors: DoggySazHi classAndrew

repo: classAndrew/cow


text:
fix: build failed  from source on macos

/kind cleanup
/kind bug

Hey @TinySong, thanks for opening your first PR for Capsule!
Could you elaborate a bit more what's the issue you faced? Actually, we got CI and automated tests and expect Capsule to run on Linux-based machines.

authors: TinySong prometherion

repo: clastix/capsule


text:
Console error when unmounting a DndContext

Hi, great work with dnd-kit, I really like it.
I'm experiencing the console error "Can't perform a React state update on an unmounted component" every time I unmount a DndContex containing a SortableContext with some items. I don't know if I'm missing something or if it is a DndContex issue.
I created a siple app to reproduce the bug: https://codesandbox.io/s/dnd-kit-unmount-issue-2kmpjw?file=/src/App.js
Thanks!

I have the same problem.

Somebody have any ideas to fix it?

Me too, please fix it!

Hi !
I have the same problem.
It is reproduced without SortableContext.
I created a app to reproduce: https://codesandbox.io/s/dnd-kit-unmount-issue-forked-rm0p7u

+++

I could prevent that error by putting DndContext outside the unmounted component.
This is an example app.
https://codesandbox.io/s/trusting-chandrasekhar-1sn9fe
I'm going to try it with using SortableContext.

I found that only useDraggable reproduce the error while unmounting.
https://codesandbox.io/s/xenodochial-volhard-ldy93r
So it might be required to fix useDroppable.

This is fixed as of @dnd-kit/core^5.0.3

authors: Manganumapp cantoniriccardo clauderic kiselyou sawadyecma skyliwq yankovichv

repo: clauderic/dnd-kit


text:
Login failed after creating new account

I just created an account as a new member, then return to the sign in and the login fails with error please validate login. I tried to reset the password thinking I possibly fat fingered, and now I get an error stating "There was an error in resetting your password."

Resolved.... was not advised to confirm email address.... and if you have a slow email client, like I do, the notification takes some time to come to your inbox :)
Verified email and now I'm in


text:
🛑 livevault is down

In 2f0f7a1, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 4e67aaa.

repo: claytonplong/backup-uptime


text:
🛑 livevault is down

In 4a781be, livevault (https://livevault.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: livevault is back up in 313621f.


text:
Using for functions does not recognise all local definitions

E.g., fix is indexed as being used by setNeedSave in clean-ide's Ed.EdMonad while it is a local definition there.

Fixed in 0e7f534c08512a3ff11d7b23842d972dfc2ee3b7.

repo: clean-cloogle/Cloogle


text:
Resolve #105 (sharing library browser) and change share UI

On the main page, let an input field appear with the shortened URL
On the main page, remove text-decoration and pointer cursor when the URL is being shortened
Adds a share button to the library browser that turns into a text input field with the shortened URL

I'm not fond of the button on the source page. Moreover the text shown when making a shortlink on the frontpage is also a bit strange. Do we even need to change the text? Maybe we can let it be Share

I'm not fond of the button on the source page.

What do you suggest?

Moreover the text shown when making a shortlink on the frontpage is also a bit strange.

Would removing "Done, ", i.e. just "See URL below" help? If not: what exactly do you find strange about it?

Do we even need to change the text? Maybe we can let it be Share

I don't think this is a good idea, then it is not clear for the user that something is happening. Also, on slow internet, you will see a text between sending the request and receiving the response; "Contacting cloo.gl server". This text should remain there, because otherwise on slow connections you will not see anything happening until the response is received. If the text then changes back to "Share" that would be unlogical.

Just leave the text as Share. Something like this: https://cloo.gl/MTEz

On src it might be better to not remove the button and just make the text Share

authors: camilstaps dopefishh

repo: clean-cloogle/cloogle


text:
Update composer dependencies

The version of guzzle has changed and with the newest the package doesn't work at all. I've forced it to download the latest good version.

@piotrpasich thanks for your contribution and sorry for the late reply!
I will be making a proper fix for Guzzle after I have worked through all the issues and PRs of the last few months. I will comment here when I got it fixed for you

Guzzle version requirement has been changed to 6, run composer update to automatically use the new implementation.

authors: cleentfaar piotrpasich

repo: cleentfaar/slack


text:
ci(repo): Version packages

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@clerk/astro@1.0.6
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/backend@1.5.1
Patch Changes

Retry handshake in case of handshake cookie collision in order to support multiple apps on same-level subdomains (#3848) by @nikosdouvlis

@clerk/express@0.0.23
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/fastify@1.0.25
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/nextjs@5.2.11
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/remix@4.2.9
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/clerk-sdk-node@5.0.22
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/tanstack-start@0.1.13
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

@clerk/testing@1.2.5
Patch Changes

Updated dependencies [992e5960c]:

@clerk/backend@1.5.1

!snapshot multiapp

!snapshot multiapp

!snapshot multiapp

authors: clerk-cookie nikosdouvlis

repo: clerk/javascript


text:
[Suggestion] Add a keybind for playback

Please add a keybind for audio playback for better compatibility with other quest UI addons

Do you mean to toggle the functionality on and off?

To activate the playback, as opposed to autoplay or clicking the button that isn't visible in say for example DialogUI

This has been added to the code and will likely be merged in soon!

license: Unlicense


text:
Feature/pdct 1603 render mcf metadata on family projects page

What's changed
Update Projects/Family Page with an addition of a metadata render which renders the metadata items for the project depending on the fund/corpus.
Proposed version
Please select the option below that is most relevant from the list below. This
will be used to generate the next tag version name during auto-tagging.

[ ] Skip auto-tagging
[x] Patch
[ ] Minor version
[ ] Major version

Visit the Semver website to understand the
difference between MAJOR, MINOR, and PATCH versions.
Notes:

If none of these options are selected, auto-tagging will fail
Where multiple options are selected, the most senior option ticked will be
used -- e.g. Major > Minor > Patch
If you are selecting the version in the list above using the textbox, make
sure your selected option is marked [x] with no spaces in between the
brackets and the x

Tested with multi geos

Updated Order

Handle cases of multi geogrpahies overflowing and coming out of the div.

repo: climatepolicyradar/navigator-frontend


text:
💚 (src/core/assistant-message/parse-assistant-message.ts): improve as…

Added docs to parse-assistant-message

Appreciate the PR! I should have merged this in sooner before all the latest changes to parse-assistant-message, my apologies.

authors: bramburn saoudrizwan

repo: cline/cline


text:
[RFC] Subpackages for pykeyvi

For a new feature I like to discuss modularization. I like to put the new feature into a subpackage ('pykeyvi.index'). Playing a bit with cython it unfortunately turns out, cython does not support it easily:
https://github.com/cython/cython/wiki/FAQ#how-to-compile-cython-with-subpackages
There is a recommendation on the wiki:
https://github.com/cython/cython/wiki/PackageHierarchy
which would build a 'so' for every subpackage, which would mean a lot of wasted space and higher memory usage.
RFC: Move the cython extension into a hidden namespace ('pykeyvi._core') keeping the flat structure, create a python module structure and import accordingly, this would keep a single so file but still provide subpackages:
 - pykeyvi
  - __init__.py
  - index
   - __init__.py

pykeyvi/init.py:
from pykeyvi._core import JsonDictionaryCompiler, ...

pykeyvi/index/init.py:
from pykeyvi._core import IndexReader, IndexWriter

In the longer run this also solves 2 problems:

cleanup existing structure
create python code extensions (like the keyvicli library)

@narekgharibyan

@hendrikmuhs sounds good!
Have you tried to implement it already, to see how it works with packaging ?

authors: hendrikmuhs narekgharibyan

repo: cliqz-oss/keyvi


text:
Add a values to set both JVM heap and memory resource request

Currently memory allocation is defined exclusively using the ES_JAVA_OPTS env property, which on memory constrained systems can lead to crash looping as pods are scheduled onto nodes with less available memory than specified in the JVM options, causing a swift and sometimes vague crash due to insufficient memory (issue https://github.com/clockworksoul/helm-elasticsearch/issues/28).
This PR defines a values setting that jointly defines both the ES_JAVA_OPTS property and a resource request value
values.yaml:
  requests:
    # Specifies the memory requested for the JVM heap.
    # Requires a decimal unit (M = 1000^2 bytes, G = 1000^3 bytes).
    memory: 256M

Templates:
env:
  - name: ES_JAVA_OPTS
  value: "-Xms{{ .Values.data.requests.memory | default "256m" | lower }} -Xmx{{ .Values.data.requests.memory | default "256m" | lower }}"

and
resources:
  requests:
    memory: {{ .Values.data.requests.memory | default "256m" | upper }}

@mikn This update allows the user to specify the magnitude of the memory request, but it does force the base-10 convention.
I do see your point with respect to allowing the values to be modified independently however. Taking a step back to an earlier thought: How do you feel about splitting them with something like this for a values.yaml?
data:
  requests:
    heapMemory: 256m
    containerMemory: 256Mi

data:
  requests:
    heapMemory: 256m
    containerMemory: 256Mi

This is better, yes, but requests key is in most helm charts mapped straight into the requests section of the container spec, so I would keep heapMemory/heapSize outside of it and map it back in, so it would look like:
data:
  heapMemory: 256m
  resources:
    requests:
      memory: 256Mi
      cpu: 100m
    limit:
      memory: 512Mi
      cpu: 500m

You will see this pattern applied in most official charts. :)

There you go, being all reasonable again. 🙂
Your suggestion is a big improvement. I’ll update the PR (probably) tonight.

On Nov 21, 2017, at 7:29 PM, Mikael Knutsson notifications@github.com wrote:
data:
requests:
heapMemory: 256m
containerMemory: 256Mi
This is better, yes, but requests key is in most helm charts mapped straight into the requests section of the container spec, so I would keep heapMemory/heapSize outside of it and map it back in, so it would look like:
data:
heapMemory: 256m
resources:
requests:
memory: 256Mi
cpu: 100m
limit:
memory: 512Mi
cpu: 500m
You will see this pattern applied in most official charts. :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Changes made. How's that look?

Looks sweet!

@sagikazarmark Are there any other changes that you’d like to see?

No, I think it looks good.

Cool. I'm going to take that as an "accepted" 🙂

Wonderful!

authors: clockworksoul mikn sagikazarmark

repo: clockworksoul/helm-elasticsearch


text:
Add pod-density scenarios

This scenarios is useful when you only care about creating a  lot of
pods in a namespace and don't care about distribution across worker nodes.
This is similar to what used to be called pod-vertical.
Signed-off-by: Sai Sindhur Malleni smalleni@redhat.com

Can one of the admins verify this patch?

Hey @smalleni !,
Can you make reference of this new workload in the docs?

Thanks for the reminder Raul, can you take a look now?

Hey @smalleni !,
Can you make reference of this new workload in the docs?

Thanks for the reminder Raul, can you take a look now?

lets wait for CI and MERGE!

Results for ec2_jjb

Test
Result
Retries
Duration (HH:MM:SS)

test_kubeburner
Pass
0
00:18:58

authors: comet-perf-ci rsevilla87 smalleni

repo: cloud-bulldozer/benchmark-operator


text:
Imporve the test cases for error page

In the current implementation of Errorpage.test.tsx, the test case renders when there is an error is checking only if the error-page is rendered. Improve the test case to check what is displayed in this error page.

@ericksod @4upz Can you take a look at this small PR ?


text:
Queue multi action

Continuation on the work that Christina did before starting the thesis.
Popup is shown when a checkbox is selected, one request per queue
TODO:

Checkbox in header that checks all queues

It's a very big diff since I've moved the js into it's own file but the changes are on this lines: https://github.com/cloudamqp/avalanchemq/pull/330/files#diff-61e046fd549fa0d149192cf50d76a706bb66e85185b34a59760be34d5e644875R49-R68

Not prioritised, but couldn't help myself to google this https://stackoverflow.com/questions/659508/how-can-i-shift-select-multiple-checkboxes-like-gmail :-)

Was trying out the shift + click but felt that it's better to get this out and then add the shift select later (keep it simpler).
But I know that people want it and it is a very nice feature.

Was trying out the shift + click but felt that it's better to get this out and then add the shift select later (keep it simpler).

100% agree :)

authors: jage snichme

repo: cloudamqp/avalanchemq


text:
Revert "63012 update scheduler api"

Reverts cloudant/couchdb-couch-replicator#32

+1

authors: nickva rnewson

repo: cloudant/couchdb-couch-replicator


text:
Removed ForwardingMap

What
Removed usage of Guava ForwardingMap.
How
Replaced SimpleChangeNotifyingMap class usages with ChangeNotifyingMap
interface.
Created new instances of ChangeNotifyingMap with SimpleChangeNotifyingMap.wrap method that uses a reflection proxy to delegate to another Map and implements the hasChanged method and checks for map changes in an InvocationHandler.
Testing
Added resolveConflictsForDocument_twoConflictAndNewWinner_newWinnerInsertedWithModifiedAttachments to exercise the hasChanged path which was untested before.
Issues
Part of #308

+1

+1

authors: rhyshort ricellis tomblench

repo: cloudant/sync-android


text:
Support vmware tools installation

Hi,
I've made a minor fix to support vmware-tools installation for VMware instance.
Currently, VMware-Tools are installed from attached CD-ROM.
I think it's better to install it from copied binary compared to CD-ROM (Because we need to attach CD-ROM manually)
Please check the comment and merge it if it's useful.
Best,
Hiro

Hello,
Thank you for the contribution, much appreciated. Currently, we are planning to obsolete the master branch and add features only on the experimental branch. Can you make a PR with only one commit to the experimental branch?
Thank you,
Adrian Vladu

PR already merged with the same functionality:
https://github.com/cloudbase/windows-openstack-imaging-tools/pull/163/


text:
🛑 berdu.id is down

In 629c63b, berdu.id (https://berdu.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: berdu.id is back up in c1dc034.

repo: cloudbip/upptime


text:
🛑 puskomedia.id is down

In 32fc11c, puskomedia.id (https://puskomedia.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: puskomedia.id is back up in a02cd36 after 14 minutes.


text:
🛑 sarang.id is down

In fe58e1b, sarang.id (https://sarang.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: sarang.id is back up in 8037daf.


text:
🛑 cbn.id is down

In 0710a27, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 4cf208b.


text:
🛑 console.idcloudhost.com is down

In 88863e9, console.idcloudhost.com (https://console.idcloudhost.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: console.idcloudhost.com is back up in 4b624d7.


text:
Is it possible to disable the Member ID validation?

Hi,
I have a specific relationship that I handle manually in the Adapter, to allow both new and existing models to be created/updated in the same request. (in order to save request-count)
However even though the relationship is marked as "Guarded" to prevent any built in relationship handling, it'll still fail with an error 400.
detail: "The member id is required."
Is it possible to remove this validation for specific relationships to handle it manually?
Cheers,

Submitting resource identifiers without an id member is against the spec - which is why you're getting that message. The spec says:

A “resource identifier object” MUST contain type and id members.

As this package is about delivering JSON-API compliant APIs, it's not possible to disable something that is defined by the spec.
If you want to do something that is non-spec compliant, don't register the route for that relationship via the routing helpers provided by this package. Then manually implement the route via normal Laravel route definitions... i.e. handle it yourself.
FYI the spec is aiming to support Operations at some point (hopefully soon), which will solve the problem that you're trying to solve by your work-around. I'm definitely planning to add support for that as soon as it is introduced to the spec, because I need to use it too!

Alright.
I know it's in the spec, which is why I have a workaround right now, but I'd prefer to keep it as clean as possible.
Let me know if I can be of help when it's introduced to the spec.
Cheers

Ah thanks and no problem! As I say, use the work-around of registering your own relationship route for the mo and hopefully Operations will be great when they get added to the spec!!

authors: JapSeyz lindyhopchris

repo: cloudcreativity/laravel-json-api


text:
SQL datastrategy with -is and -dc (distcp for LEFT and RIGHT not aligned)

The RIGHT distcp isn't appending the 'db' to the folder name.

ext_purge_odd_parts_RIGHT_distcp_workbook.md
ext_purge_odd_parts_LEFT_distcp_workbook.md

repo: cloudera-labs/hms-mirror


text:
bump golang to 1.18

Bumping golang version to 1.18
Signed-off-by: Iñigo Horcajo inigohu@gmail.com

If there is a good reason for this, let me know. This change forces all downstreams to update to go 1.18.

I think we could bump to 1.17 to fix the test?

repo: cloudevents/sdk-go


text:
Split SDK Functionality Into Separate Modules

Describe the Bug
Different CloudEvent consumers have different uses/applications. Some features folks just want certain features. We talked about splitting this repo with separate modules:

Here's the SDK spec: https://github.com/cloudevents/spec/blob/master/SDK.md

CloudEvent object model / interfaces
CloudEvent receiver
CloudEvent emitter
CloudEvent discovery / subscription

Same repo but separate libraries/modules.

I don't think it makes sense to remove the transport APIs from the top level cloudevents module. I do think a cloudevents-discovery module and a cloudevents-subscription module are good though.

I don't think it makes sense to remove the transport APIs from the top level cloudevents module. I do think a cloudevents-discovery module and a cloudevents-subscription module are good though.

Agreed.

authors: grant lance

repo: cloudevents/sdk-javascript


text:
[Pages] Update how-to to refer to bulk redirects instead of Page Rules

Expected Behavior
We should be referring to the most up-to-date functionality where appropriate. We're now recommending folks use Bulk redirects instead of Page rules for redirecting domains/subdomains.
Actual Behavior
Should provide guidance similar to the info present in the Rules documentation (or just link out).
Section that requires update
https://developers.cloudflare.com/pages/how-to/www-redirect
Additional information
Any other details or screenshots you think are relevant.

As an additional thing to this, it would be cool to make another tutorial where we redirect from *project.pages.dev/* to your custom domain with Bulk Redirects. It's a common question asking how to do it

@codewithkristian sure! I can do that. @WalshyDev I think it's worth having such a tutorial, I will make a ticket for it right now.

authors: Ekwuno WalshyDev kodster28

repo: cloudflare/cloudflare-docs


text:
Create digest-stream.md

After dropping this as a comment here: https://github.com/w3c/webcrypto/issues/73#issuecomment-1165517709, I thought might be worth turning it into an example for the docs as well?
Feel free to update this (i've allowed edits by maintainers to the branch in my fork).

BTW crypto.DigestStream got announced here in December (found a link to that post via the Github issue), but there's nothing in the docs yet (neither mentioned in Using Streams nor Streams API Reference), so this is the working result of my trial-and-error 😅

Hi @simonhaenisch , is this ready for merge? Could you please look through and accept or resolve James' suggestions?

Hey sorry haven't gotten around to it, so no not yet (let me convert it to draft PR). I'll try to get to it asap.

Hi @simonhaenisch , would you still like to work on this? Let me know how you'd like to move forward! Thank you

Hey sorry don't really have to time to finish it currently... can close it for now, and it would still be here as reference i guess.

Closing per the last comment - can reopen at a later date.


text:
Implement organization-level Load Balancer pool/monitor API calls

There is currently no way to access access organization level load balancer pool/monitor settings.
The API calls in question is:
Monitors:

https://api.cloudflare.com/#organization-load-balancer-monitors-list-monitors
https://api.cloudflare.com/#organization-load-balancer-monitors-create-a-monitor
https://api.cloudflare.com/#organization-load-balancer-monitors-monitor-details
https://api.cloudflare.com/#organization-load-balancer-monitors-delete-a-monitor
https://api.cloudflare.com/#organization-load-balancer-monitors-modify-a-monitor

Pools:

https://api.cloudflare.com/#organization-load-balancer-pools-properties
https://api.cloudflare.com/#organization-load-balancer-pools-create-a-pool
https://api.cloudflare.com/#organization-load-balancer-pools-pool-details
https://api.cloudflare.com/#organization-load-balancer-pools-delete-a-pool
https://api.cloudflare.com/#organization-load-balancer-pools-modify-a-pool

Pass UseOrganization
https://godoc.org/github.com/cloudflare/cloudflare-go#UsingOrganization -
the LB methods will then use the /organizations endpoints automatically.
On Wed, Apr 18, 2018 at 6:58 AM Jesper notifications@github.com wrote:

There is currently no way to access access organization level load
balancer pool/monitor settings.
The API calls in question is:
Monitors:

https://api.cloudflare.com/#organization-load-balancer-monitors-list-monitors
https://api.cloudflare.com/#organization-load-balancer-monitors-create-a-monitor
https://api.cloudflare.com/#organization-load-balancer-monitors-monitor-details
https://api.cloudflare.com/#organization-load-balancer-monitors-delete-a-monitor
https://api.cloudflare.com/#organization-load-balancer-monitors-modify-a-monitor
Pools:

https://api.cloudflare.com/#organization-load-balancer-pools-properties
https://api.cloudflare.com/#organization-load-balancer-pools-create-a-pool
https://api.cloudflare.com/#organization-load-balancer-pools-pool-details
https://api.cloudflare.com/#organization-load-balancer-pools-delete-a-pool
https://api.cloudflare.com/#organization-load-balancer-pools-modify-a-pool
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cloudflare/cloudflare-go/issues/178, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AABIcBvsSOo9VrXQhOvXC7LeDdTBf_Tnks5tp0aFgaJpZM4TaHiM
.

Ahh so i needed to just RTFM.
Will close the issue then

authors: FnuGk elithrar

repo: cloudflare/cloudflare-go


text:
Implement the ping-pong flow

WIP (not ready for review).
Based on #351 (merge that first).
Partially addresses #350.

Superseded by #409

repo: cloudflare/daphne


text:
fix: deprecated of from_timestamp_opt

NaiveDateTime::from_timestamp_opt had been tagged deprecated since chrono 0.4.23, it suggests using DateTime::from_timestamp instead of.

Appreciate the vigilance here. We merged a corresponding change as well when we were fixing nightly. ae8ea771b1a738b379b4061c7d7e20ca0e22a542

authors: drcaramelsyrup liloew

repo: cloudflare/pingora


text:
fuzz: add initial fuzzers based on libfuzzer

Supersedes #179. Even Mayhem seems to like this more so it seems like the way to go.
There are two downsides though:

cargo-fuzz only seems to work with Rust nightly.
cargo-fuzz doesn't support an "initialization" step (e.g. to create quiche Config object), so we need to hack one in using lazy_static.

Also, the lazy_static hack could be removed if https://github.com/rust-fuzz/libfuzzer-sys/pull/33 (or similar) was merged into libfuzzer-sys.

You should consider using bolero 😄. I ran into similar downsides and wanted something better. You can see a feature comparison here: https://github.com/camshaft/bolero/#prior-work

authors: camshaft ghedo

repo: cloudflare/quiche


text:
test - ignore

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
test
Affected resource(s)
test
Terraform configuration files
test

Link to debug output
https://gist.github.com/samuelbarata/c709c6d2226232adc49dfad5a02d2bbc
Panic output
No response
Expected output
test
Actual output
test
Steps to reproduce
test
Additional factoids
No response
References
No response

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Debug log detected :white_check_mark:

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.


text:
🐛 Bug Report — Runtime APIs: WebSocket.close() logs Request failed due to internal error in Miniflare

When calling socket.close() for a WebSocket connection inside a Durable Object logs the following error to Miniflare console.
workerd/util/symbolizer.c++:98: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
workerd/server/server.c++:2525: error: Uncaught exception: kj/async.c++:212: disconnected: worker_do_not_log; Request failed due to internal error
stack: 1053b3473 10642ee4b 1064353eb 10642c3bf 10465cd27 104660313 10466014f 104660137 1064956f3 106495a3b 10649419b 106493f6b 1046541af 1a4743f27 106426c90 1053d7cf4 104e32574 104c16b00 104c16f0f 104af12e8 10469eabc 10539bc80 10539f060

For instance:
async webSocketMessage(ws, msg) {
  if (msg === "close me") {
    ws.close();
  }
}

Outputs:

The socket closes correctly. We are only seeing this error in Miniflare, not in Workers platform logs, but I'm not sure if that means the error is not occurring, or if it's just not being send to wrangler tail.

I've opened a ticket to track internally, we won't be able to prioritize this for a bit. I'll update when someone can take a look.

authors: MellowYarker jevakallio

repo: cloudflare/workerd


text:
add buffer.transcode to nodejs_compat

This pull-request adds require('node:buffer').transcode() support. It uses ICU for most encodings, and simdutf for latin1, utf8 and utf-16 operations.

Adding the "needs-internal-pr" label on this to ensure that we make certain that the internal CI run is green before this lands.

Internal PR is now resolved. We can merge this now.

authors: anonrig jasnell


text:
add several node:zlib classes

Lacks tests but before adding more, I think this is getting ready to have an additional pair of eyes.
Remaining todo:

[ ] Add tests
[ ] Investigate why eslint is causing so much trouble (hence eslint-ignore)

Overall looking good so far. Definitely want to see more tests land with this tho so will hold off signing off until we get those.

Do we know why the unnecessary mutex guard caused the test failure?
It doesn't immediately jump out at me what this has to do with a mutex
Fatal uncaught kj::Exception: workerd/api/node/zlib-util.c++:311: failed: expected status == 0 || status == (-3); jsg.Error: Uncaught error on closing zlib stream

Do we know why the unnecessary mutex guard caused the test failure?

Yes, the class destructor was checking the reference not the value, and causing the sanitizer to fail.

Aside: That implicit conversion to operator T* in libkj is kind of wack.

authors: anonrig jasnell npaun


text:
🚀 Feature Request: Allow a top-level $schema property in wrangler.json

Describe the solution
I've created a local schema to enhance the wrangler.json experience. For the schema to be loaded by VSCode, the $schema top-level property is required. Setting the property currently generates a warning.
    - Unexpected fields found in top-level field: "$schema"

@monken Can you make that schema public? A gist would be awesome.

@monken Can you make that schema public? A gist would be awesome.

I just create it on-demand. This will make sure your schema is in sync with the installed version of wrangler.
yarn typescript-json-schema node_modules/wrangler/src/config/config.ts RawConfig > wrangler.schema.json

For Wranger v3 RawConfig isn't in the shipped module types anymore so I had to grab the source, but here's how I generated it:
pnpm dlx ts-json-schema-generator --no-type-check --no-ref-encode --path ..\workers-sdk\packages\wrangler\src\config\config.ts --type RawConfig --out ./.wrangler/wrangler.schema.json
And I use the Even Better TOML extension for VSCode which supports JSON schemas for TOML and it works fine:

In VSCode, you can specify the schema for a json file in .vscode/settings.json.
"json.schemaDownload.enable": true,
"json.schemas": [
   {
     "fileMatch": ["wrangler.json"],
     "url": "https://github.com/cloudflare/workers-sdk/files/12887590/wrangler.schema.json"
   }
],

with this extension https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml
then
#: schema https://github.com/cloudflare/workers-sdk/files/12887590/wrangler.schema.json
name = "my-worker"

# autocomplete enabled now

authors: JustinGrote Odame binyamin monken o-az

repo: cloudflare/workers-sdk


text:
🐛 BUG: create-cloudflare with opennextjs-cloudflare deploy script error

Which Cloudflare product(s) does this pertain to?
C3 (npm create cloudflare)
What versions are you using?

C3 2.35.1

What operating system and version are you using?
Windows 11
Please provide a link to a minimal reproduction
No response
Describe the Bug
The next C3 install uses the wrong deploy command.

Run npm create cloudflare@latest my-next-app -- --framework=next --experimental
Try npm run deploy
Observe:

'cloudflare' is not recognized as an internal or external command,
operable program or batch file.

This was changed in https://github.com/opennextjs/opennextjs-cloudflare/pull/166
Please provide any relevant error logs
No response

The issue here is that the template has not been updated for @opennextjs/cloudflare 0.3.x.
So the fix is to ping the package to 0.2.x, done in this PR but pending release.
We can either close the issue or keep it open to track the upgrade of the templates

authors: Cherry vicb