[KFP Bug] In KFPv2 we cannot create a unique string at runtime and pass it to components

Search before asking

[X] I searched the issues and found no similar issues.

Component
KFP workflows
What happened + What you expected to happen
To prevent Ray cluster conflicts, KFP should provide a unique name for each cluster. This unique name should be generated at runtime.
In order to do it in KFPv1 we used kfp.dsl.RUN_ID_PLACEHOLDER, unfortunately, it was deprecated in KFPv2 and from KFP SDK 2.5.0 it is unavailable.
We checked an option to create this unique string in one of the KFP components (uuid.uuid4().hex), but we have to pass it to the clean_up_task of ExitHandler but the issue (https://github.com/kubeflow/pipelines/issues/10187) prevents as do in that.
We have discussed it with our Red Hat colleagues.
As a temporary workaround in KFPv1 we will continue using kfp.dsl.RUN_ID_PLACEHOLDER, but in KFPv2 we will generate a unique string at compilation time (at runtime it is not unique).
Reproduction script
if os.getenv("KFPv2", "0") == "1":
run_id = uuid.uuid4().hex
else:
run_id = dsl.RUN_ID_PLACEHOLDER
Anything else
This issue is for tracking https://github.com/kubeflow/pipelines/issues/10187 and update our code, when it will be resolved.
OS
Red Hat Enterprise Linux (RHEL)
Python
3.10.x
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

The issue is expected to be resolved in KFPv2.4.0, which is scheduled for the middle of January 2025.


Module parse failed: Unexpected token (112:19)

I have a problem with Harlem when I use Vue CLI boilerplate.
The compilation error is following:
ERROR  Failed to compile with 1 error
error  in<EMAIL_ADDRESS>Module parse failed: Unexpected token (112:19)

You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|       providers: {
|         ...PROVIDERS,
>         ...options?.providers
|       }
|     };

 @ ./src/main.js 7:0-34 8:19-25
 @ multi (webpack)-dev-server/client?http://<IP_ADDRESS>:8080&sockPath=/sockjs-node (webpack)/hot/dev-server.js ./src/main.js`

Steps to reproduce the behaviour:

Use vue create app to create vue project.
Install Harlem with NPM.
Add import Harlem from '@harlem/core'; and createApp(App).use(Harlem).mount('#app') to main.js file.
Run npm run serve to compile the project.
Have aforementioned error.

Version:

Harlem: ^2.0.0
Vue: ^3.0.0
"@vue/cli-plugin-babel": "~4.5.0",
"@vue/cli-plugin-eslint": "~4.5.0",
"@vue/cli-service": "~4.5.0",

Hi @Dzelix
This error is due to Harlem using modern language features such as optional chaining etc. These features are only available in ES2020. I have changed Harlem's target browser version to match Vue 3's target browser version which is ES2016.
This issue should now be fixed in v2.0.1.
I also noticed that your target Vue version is ^3.0.0. Harlem ^2.0.0 requires at least version ^3.2.0 of Vue as it uses new features only available in Vue 3.2.
Let me know if v2.0.1 fixes the issue.
Thanks


FileNotFoundError: [Errno 2] No such file or directory: '/dev/i2c-1

When I start to run python manage.py drive I hit the following error  (boot from pi zero image)
(env) pi@donkeypi:~/mycar $ python manage.py drive
using donkey v2.5.1 ...
/usr/lib/python3/dist-packages/h5py/__init__.py:34: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
loading config file: /home/pi/mycar/config.py
config loaded
PiCamera loaded.. .warming camera
Starting Donkey Server...
Traceback (most recent call last):
  File "manage.py", line 190, in <module>
    drive(cfg, model_path = args['--model'], use_joystick=args['--js'], use_chaos=args['--chaos'])
  File "manage.py", line 103, in drive
    steering_controller = PCA9685(cfg.STEERING_CHANNEL)
  File "/home/pi/env/lib/python3.5/site-packages/donkeycar/parts/actuator.py", line 18, in __init__
    self.pwm = Adafruit_PCA9685.PCA9685()
  File "/home/pi/env/lib/python3.5/site-packages/Adafruit_PCA9685/PCA9685.py", line 74, in __init__
    self._device = i2c.get_i2c_device(address, **kwargs)
  File "/home/pi/env/lib/python3.5/site-packages/Adafruit_GPIO/I2C.py", line 64, in get_i2c_device
    return Device(address, busnum, i2c_interface, **kwargs)
  File "/home/pi/env/lib/python3.5/site-packages/Adafruit_GPIO/I2C.py", line 97, in __init__
    self._bus = Adafruit_PureIO.smbus.SMBus(busnum)
  File "/home/pi/env/lib/python3.5/site-packages/Adafruit_PureIO/smbus.py", line 105, in __init__
    self.open(bus)
  File "/home/pi/env/lib/python3.5/site-packages/Adafruit_PureIO/smbus.py", line 130, in open
    self._device = open('/dev/i2c-{0}'.format(bus), 'r+b', buffering=0)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/i2c-1'

But it can be easily fixed by
adding (or uncomment) dtparam=i2c_arm=on
in /boot/config.txt
Just would like to see is it a common issue

Hello, it states in the donkey instructions that you must enable i2c in raspi-config.  Did you do that?

@scitronboy Ah, I haven't done that. Thanks for the prompt reply!~ I found it in the faq now.
Originally I am following this: http://docs.donkeycar.com/guide/install_software/
But that part seems just mention to use raspi-config to expand file system. Do you think it is good to mention it is necessary to enable i2c in that page?

I don't think it's necessary on that page, because the pre-built disk image should already have i2c enabled. Are you using the pre-built disk image? Also, try checking raspi-config: sudo raspi-config and then navigate to interfacing options and then check i2c. Is it enabled???

Yes, i am using the pre-build image (for pi-zero) but i agree user can enable it in raspi-config easily even not enabled. let me close this issue


Anvil worlds - new north-south chunks deleted after world exit

Chunks on the z coordinate (north-south) made will be deleted upon exit and re-entry, even when saved. This happens after current chunks on the north-south reach a total width of 32.
East-west chunks can still be created indefinitely.

Still an issue with the 0.1.1 packaged windows version.

Yup, saw your forum post. Will look into it if I get time this weekend.


release 2.5.1 Node >18 incompatibility

I was on the 2.4.3 release and could use the package with no problems, when I upgraded to the latest release (2.5.1), I get the following error during installation.
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "^18.0.0". Got "20.11.1"
warning<EMAIL_ADDRESS>The engine "pnpm" appears to be invalid.
error Found incompatible module.

I saw that the engine in package.json was changed:
Release 2.4.3
  "engines": {
    "node": ">=16",
    "pnpm": ">=7"
  },

Release 2.5.1
  "engines": {
    "node": "^18.0.0",
    "pnpm": "^8.0.0"
  },

Is there a particular reason for this change ?

I guess you might be using yarn, pnpm and npm does not enable engine-strict by default.
This sentence is for renovate to now update dependencies to the latest version with pnpm and node.
The pnpm-lock.yaml will be forcibly upgraded to 9.0.
Before upgrading to pnpm V9, you can temporarily use:
yarn add vuetify-pro-tiptap --ignore-engines

Or if you have other locked versions of pnpm and node that renovate uses, you can tell me.

Indeed I do use yarn, in my case, using the ignore-engines option worked, when is it planned to upgrade to pnpm V9 ?
I can add the option in a .yarnrc to apply it by default for my project, but would rather keep this check in my dev environement.

:tada: This issue has been resolved in version 2.5.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Rancher 2.6.5 and 2.6.4 upgrade fails behind proxy with privateCA

Rancher Server Setup

Rancher version: 2.6.3
Installation option (Docker install/Helm Chart): Helm Chart

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1

Proxy/Cert Details: Proxy + private CA

Information about the Cluster

Kubernetes version: v1.21.5
Cluster Type (Local/Downstream): Local

User Information

What is the role of the user logged in? Admin

Describe the bug
Rancher 2.6.5 (and 2.6.4) crash with segmentation violation
To Reproduce
Run helm upgrade
Result
2022/05/13 16:57:14 [INFO] Listening on :80
2022/05/13 16:57:14 [INFO] Listening on :444
2022/05/13 16:57:14 [INFO] certificate CN=dynamic,O=dynamic signed by CN=dynamiclistener-ca,O=dynamiclistener-org: notBefore=2021-10-18 14:00:56 +0000 UTC notAfter=2023-05-13 16:57:14 +0000 UTC
2022/05/13 16:57:14 [INFO] certificate CN=dynamic,O=dynamic signed by CN=dynamiclistener-ca,O=dynamiclistener-org: notBefore=2021-10-18 14:00:56 +0000 UTC notAfter=2023-05-13 16:57:14 +0000 UTC
2022/05/13 16:57:14 [INFO] Updating TLS secret for tls-rancher-internal (count: 1): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/fingerprint:SHA1=723457E2F455ED2AD4F7CC3723D846FFE2096763]
2022/05/13 16:57:14 [INFO] Active TLS secret tls-rancher-internal (ver=97248785) (count 1): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/fingerprint:SHA1=723457E2F455ED2AD4F7CC3723D846FFE2096763]
2022/05/13 16:57:15 [ERROR] error syncing 'rancher-rke2-charts': handler helm-clusterrepo-ensure: git -C /var/lib/rancher-data/local-catalogs/v2/rancher-rke2-charts/675f1b63a0a83905972dcab2794479ed599a6f41b86cd6193d69472d0fa889c9 fetch origin 9d3e60bde34813252b383c5d11d48d34cd8fa31e error: exit status 128, detail: fatal: unable to access 'https://git.rancher.io/rke2-charts/': The requested URL returned error: 502
, requeuing
2022/05/13 16:57:16 [INFO] Starting /v1, Kind=Secret controller
E0513 16:57:16.107875 35 runtime.go:78] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference)
goroutine 8336 [running]:
k8s.io/apimachinery/pkg/util/runtime.logPanic({0x37f4160, 0x6eaa280})
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/runtime/runtime.go:74 +0x7d
k8s.io/apimachinery/pkg/util/runtime.HandleCrash({0x0, 0x0, 0xc00bcf67d0})
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/runtime/runtime.go:48 +0x75
panic({0x37f4160, 0x6eaa280})
/usr/lib64/go/1.17/src/runtime/panic.go:1038 +0x215
github.com/rancher/dynamiclistener/factory.(*TLS).Merge(0x3d, 0x0, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/factory/gen.go:79 +0x70
github.com/rancher/dynamiclistener/storage/kubernetes.(*storage).saveInK8s(0xc011384380, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/storage/kubernetes/controller.go:134 +0x96
github.com/rancher/dynamiclistener/storage/kubernetes.(*storage).Update(0xc011384380, 0xc00a766b70)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/storage/kubernetes/controller.go:169 +0xb3
github.com/rancher/dynamiclistener/storage/kubernetes.(*storage).init.func1({0x0, 0x0}, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/storage/kubernetes/controller.go:83 +0xa5
github.com/rancher/wrangler/pkg/generated/controllers/core/v1.FromSecretHandlerToHandler.func1({0xc00e379ca0, 0x59cb2c456ef7}, {0x47b9f98, 0xc008def680})
/go/pkg/mod/github.com/rancher/wrangler@v0.8.11-0.20220411195911-c2b951ab3480/pkg/generated/controllers/core/v1/secret.go:102 +0x44
github.com/rancher/lasso/pkg/controller.SharedControllerHandlerFunc.OnChange(0xc00bcf6790, {0xc00e379ca0, 0xc009cd5e40}, {0x47b9f98, 0xc008def680})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/sharedcontroller.go:29 +0x38
github.com/rancher/lasso/pkg/controller.(*SharedHandler).OnChange(0xc00aca86e0, {0xc00e379ca0, 0x1a}, {0x47b9f98, 0xc008def680})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/sharedhandler.go:75 +0x23f
github.com/rancher/lasso/pkg/controller.(*controller).syncHandler(0xc0006b0790, {0xc00e379ca0, 0x1a})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:220 +0x93
github.com/rancher/lasso/pkg/controller.(*controller).processSingleItem(0xc0006b0790, {0x35bd920, 0xc00bcf67d0})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:201 +0x10e
github.com/rancher/lasso/pkg/controller.(*controller).processNextWorkItem(0xc0006b0790)
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:178 +0x46
github.com/rancher/lasso/pkg/controller.(*controller).runWorker(...)
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:167
k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0x7f785c26d818)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:155 +0x67
k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0xc010fbe7c0, {0x47886e0, 0xc00a033380}, 0x1, 0xc00007ed20)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:156 +0xb6
k8s.io/apimachinery/pkg/util/wait.JitterUntil(0x0, 0x3b9aca00, 0x0, 0x80, 0x440c45)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:133 +0x89
k8s.io/apimachinery/pkg/util/wait.Until(0xc007502f58, 0xc007502f78, 0xc007502f68)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:90 +0x25
created by github.com/rancher/lasso/pkg/controller.(*controller).run
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:135 +0x2c6
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb8 pc=0x2150310]
goroutine 8336 [running]:
k8s.io/apimachinery/pkg/util/runtime.HandleCrash({0x0, 0x0, 0xc00bcf67d0})
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/runtime/runtime.go:55 +0xd8
panic({0x37f4160, 0x6eaa280})
/usr/lib64/go/1.17/src/runtime/panic.go:1038 +0x215
github.com/rancher/dynamiclistener/factory.(*TLS).Merge(0x3d, 0x0, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/factory/gen.go:79 +0x70
github.com/rancher/dynamiclistener/storage/kubernetes.(*storage).saveInK8s(0xc011384380, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/storage/kubernetes/controller.go:134 +0x96
github.com/rancher/dynamiclistener/storage/kubernetes.(*storage).Update(0xc011384380, 0xc00a766b70)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/storage/kubernetes/controller.go:169 +0xb3
github.com/rancher/dynamiclistener/storage/kubernetes.(*storage).init.func1({0x0, 0x0}, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/storage/kubernetes/controller.go:83 +0xa5
github.com/rancher/wrangler/pkg/generated/controllers/core/v1.FromSecretHandlerToHandler.func1({0xc00e379ca0, 0x59cb2c456ef7}, {0x47b9f98, 0xc008def680})
/go/pkg/mod/github.com/rancher/wrangler@v0.8.11-0.20220411195911-c2b951ab3480/pkg/generated/controllers/core/v1/secret.go:102 +0x44
github.com/rancher/lasso/pkg/controller.SharedControllerHandlerFunc.OnChange(0xc00bcf6790, {0xc00e379ca0, 0xc009cd5e40}, {0x47b9f98, 0xc008def680})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/sharedcontroller.go:29 +0x38
github.com/rancher/lasso/pkg/controller.(*SharedHandler).OnChange(0xc00aca86e0, {0xc00e379ca0, 0x1a}, {0x47b9f98, 0xc008def680})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/sharedhandler.go:75 +0x23f
github.com/rancher/lasso/pkg/controller.(*controller).syncHandler(0xc0006b0790, {0xc00e379ca0, 0x1a})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:220 +0x93
github.com/rancher/lasso/pkg/controller.(*controller).processSingleItem(0xc0006b0790, {0x35bd920, 0xc00bcf67d0})
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:201 +0x10e
github.com/rancher/lasso/pkg/controller.(*controller).processNextWorkItem(0xc0006b0790)
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:178 +0x46
github.com/rancher/lasso/pkg/controller.(*controller).runWorker(...)
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:167
k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0x7f785c26d818)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:155 +0x67
k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0xc010fbe7c0, {0x47886e0, 0xc00a033380}, 0x1, 0xc00007ed20)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:156 +0xb6
k8s.io/apimachinery/pkg/util/wait.JitterUntil(0x0, 0x3b9aca00, 0x0, 0x80, 0x440c45)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:133 +0x89
k8s.io/apimachinery/pkg/util/wait.Until(0xc007502f58, 0xc007502f78, 0xc007502f68)
/go/pkg/mod/k8s.io/apimachinery@v0.23.3/pkg/util/wait/wait.go:90 +0x25
created by github.com/rancher/lasso/pkg/controller.(*controller).run
/go/pkg/mod/github.com/rancher/lasso@v0.0.0-20220412224715-5f3517291ad4/pkg/controller/controller.go:135 +0x2c6
Expected Result
Rancher 2.6.5 running

@FFock Could you please share more details about your installation, to reproduce this issue, including:

Rancher chart options specified during helm install and during helm upgrade
Content of the tls-ca secret (kubectl -n cattle-system get secret tls-ca -o yaml)
Content of the additional trusted CA secret (kubectl -n cattle-system get secret tls-ca-additional -o yaml)

@janeczku
Here are the requested helm operations
helm install rancher rancher-latest/rancher --namespace cattle-system --set hostname=<sub.internal.domain.com> --set bootstrapPassword=<somepassword> --set ingress.tls.source=secret --set proxy=http://<proxy-url>:80 --set noProxy="<IP_ADDRESS>/8\,<IP_ADDRESS>/8\,<IP_ADDRESS>/12\,<IP_ADDRESS>/16\,.svc\,.cluster.local"
helm upgrade rancher rancher-latest/rancher --namespace cattle-system --set hostname=<sub.internal.domain.com> --set ingress.tls.source=secret --set proxy=http://<proxy-url>:80 --set noProxy="<IP_ADDRESS>/8\,<IP_ADDRESS>/8\,<IP_ADDRESS>/12\,<IP_ADDRESS>/16\,.svc\,.cluster.local" --set privateCA=true --version 2.6.5

When I checked the output of

kubectl -n cattle-system get secret tls-ca -o yaml and
kubectl -n cattle-system get secret tls-ca-additional -o yaml

I recognized that the second is an old intermediate certificate which is not matching to the root CA returned by the first. Probably that was my error when I tried to upgrade the CA chain in the past (which, by-the-way, is not working as documented on rancher.com if the root CA changes), because unfortunately, the CA chain completely changed a few months ago for the certificate used for Rancher.
As both certificates are described as "independent" from each other by the Rancher documentation and both are valid entries (although the first does not have a LF after "-----END CERTIFICATE-----"!).
I would not expect that this could harm the upgrade process!?
My question is now, does it matter and why?
If yes, would it be sufficient to add the new/correct intermediate ca with kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem and then try the upgrade again?
Because the upgrade currently fails inrecoverable, this would require backing up the HA-cluster completely and a down-time while the backup is restored in case of failure. Therefore I would not like to do this without having a real chance that it would be fixed then.

Meanwhile I tried to upgrade to 2.6.5 using the "migrate to a new kubernetes cluster" approach using the Rancher backup tool to backup the 2.6.3 content and then restoring that on a freshly installed 2.6.5 cluster.
This approach fails because of the "v1beta1" API incompatibility between 2.6.4 and 2.6.3. The restore operation fails with a couple of errors and renders the new cluster damaged.

Would a velero.io based backup and restore of a local cluster's namespaces work better? Maybe that is the next I will try.
In addition I am thinking about importing those clusters created with the 2.6.3 rancher in a freshly installed 2.6.5 Rancher. Would that work and provide full maintainability of the downstream clusters? I have not found much information about that yet...

I have read through the code that is involved in this stack trace and the following change seems to have caused this regression:
https://github.com/rancher/dynamiclistener/commit/b1d65efb6f8309327ed7beb41463056379ec18eb
After the change, the local variable "secret" in the following code can be nil which is causing the seg-fault on the last line:
func (s *storage) saveInK8s(secret *v1.Secret) (*v1.Secret, error) {
	if !s.controllerHasSynced() {
		return secret, nil
	}

	targetSecret, err := s.targetSecret()
	if err != nil {
		return nil, err
	}

	// if we don't have a TLS factory we can't create certs, so don't bother trying to merge anything,
	// in favor of just blindly replacing the fields on the Kubernetes secret.
	if s.tls != nil {
		// merge new secret with secret from backing storage, if one exists
		if existing, err := s.Get(); err == nil && cert.IsValidTLSSecret(existing) {
			if newSecret, updated, err := s.tls.Merge(existing, secret); err == nil && updated {

Would a velero.io based backup and restore of a local cluster's namespaces work better? Maybe that is the next I will try.

Using velero to backup/restore a local cluster might not yet be possible because Rancher uses etcd directly to store its configuration: https://github.com/rancher/rancher/issues/24986

I have read through the code that is involved in this stack trace and the following change seems to have caused this regression:
rancher/dynamiclistener@b1d65ef
After the change, the parameter variable "secret" in the following code can be nil which is causing the seg-fault on the last line:

That's a fun theory, except the stack trace clearly shows that the change you're blaming is not present in the version of dynamiclistener  Rancher currently is using. From the stack trace:

github.com/rancher/dynamiclistener/factory.(*TLS).Merge(0x3d, 0x0, 0xc008def680)
/go/pkg/mod/github.com/rancher/dynamiclistener@v0.3.1-0.20210616080009-9865ae859c7f/factory/gen.go:79

This is https://github.com/rancher/dynamiclistener/commit/9865ae859c7f - which is a non-tagged commit of dynamiclister somewhere between 0.3.0 and 0.3.1.

Hi @brandond
You are right, sorry, I was mislead by not knowing exactly how the dependencies (and their versions) in Go are exactly managed and trustable. The latest code has a check for the existing variable not being nil before the merge within the cert.IsValidTLSSecret function as show below :
		if existing, err := s.Get(); err == nil && cert.IsValidTLSSecret(existing) {
			if newSecret, updated, err := s.tls.Merge(existing, secret); err == nil && updated {

In addition, I ignoring mistakenly that in the stack trace the first parameter of merge was 0x0. That was because I was unsure how Go would order the parameters - some other languages are doing funny things there ;-)
The commit used for Rancher 2.6.5 as stated by you above (https://github.com/rancher/dynamiclistener/commit/9865ae859c7f) does not contain this check. So, my error was to think that the variable existing is causing the crash, but it is actually secret.
Thus, I conclude that updating the dynamic listener to the latest existing version would fix the isuse already.

Are you recommending to wait for that release with the further upgrade attempts?
Do you have any hint to "clean-up" the TLS secrets to avoid this crash in 2.6.5?

You might try deleting the tls-rancher-internal and tls-rancher-internal-ca secrets? I'm not sure exactly how your cluster got into this state though, so make sure you take a backup of those resources first.
Obviously this issue isn't very widely encountered so I wouldn't recommend anyone avoid upgrading. Hopefully we'll get those updates merged for 2.6.6, so if you can't work around the issue now, maybe try again then?

I have removed the tls-rancher-internal and tls-rancher-internal-ca secrets from the Rancher backup, uploaded it to our s3 service and did a Rancher restore using kubectl on a freshly installed k8s HA cluster. The restore operation completed with success this time (why not last time???), but Rancher crashed on startup with exactly the same stack trace as before.
--> Thus, these two certificates are not causing this error.

Now I am trying to fix the bug myself and compile Rancher 2.6.5 with that fix myself.
Unfortunately, Rancher 2.6.5 cannot be build because of:
Running: golangci-lint
pkg/auth/providers/keycloakoidc/keycloak_provider.go:80:19: k.GetOIDCConfig undefined (type *keyCloakOIDCProvider has no field or method GetOIDCConfig) (typecheck)
config, err := k.GetOIDCConfig()
^
pkg/auth/providers/keycloakoidc/keycloak_provider.go:117:17: k.IsThisUserMe undefined (type *keyCloakOIDCProvider has no field or method IsThisUserMe) (typecheck)
princ.Me = k.IsThisUserMe(token.UserPrincipal, princ)
^
pkg/auth/providers/keycloakoidc/keycloak_provider.go:123:23: k.TokenMGR undefined (type *keyCloakOIDCProvider has no field or method TokenMGR) (typecheck)
princ.MemberOf = k.TokenMGR.IsMemberOf(*token, princ)
^
pkg/auth/providers/keycloakoidc/keycloak_provider.go:130:19: k.GetOIDCConfig undefined (type *keyCloakOIDCProvider has no field or method GetOIDCConfig) (typecheck)
config, err := k.GetOIDCConfig()
^
pkg/auth/providers/keycloakoidc/keycloak_provider.go:160:29: k.TokenMGR undefined (type *keyCloakOIDCProvider has no field or method TokenMGR) (typecheck)
storedOauthToken, err := k.TokenMGR.GetSecret(token.UserID, token.AuthProvider, []*v3.Token{&token})
^
pkg/auth/providers/keycloakoidc/keycloak_provider.go:182:5: k.UpdateToken undefined (type *keyCloakOIDCProvider has no field or method UpdateToken) (typecheck)
k.UpdateToken(reusedToken, token.UserID)
^
pkg/controllers/managementuserlegacy/cis/utils.go:81:2: systemProjectID declared but not used (typecheck)
systemProjectID, err := app.GetSystemProjectID(clusterName, projectLister)
^
pkg/pipeline/providers/bitbucketcloud/actions.go:41:12: b.DisableAction undefined (type *BcProvider has no field or method DisableAction) (typecheck)
return b.DisableAction(request, b.GetName())
^
pkg/pipeline/providers/bitbucketcloud/actions.go:88:33: b.AuthAddAccount undefined (type *BcProvider has no field or method AuthAddAccount) (typecheck)
sourceCodeCredential, err := b.AuthAddAccount(userName, applyInput.Code, toUpdate, toUpdate.ProjectName, model.BitbucketCloudType)
^
pkg/pipeline/providers/bitbucketcloud/actions.go:92:16: b.RefreshReposByCredentialAndConfig undefined (type *BcProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err = b.RefreshReposByCredentialAndConfig(sourceCodeCredential, toUpdate); err != nil {
^
pkg/pipeline/providers/bitbucketcloud/actions.go:98:20: b.ClusterLister undefined (type *BcProvider has no field or method ClusterLister) (typecheck)
cluster, err := b.ClusterLister.Get("", clusterID)
^
pkg/pipeline/providers/bitbucketcloud/actions.go:102:19: b.SecretMigrator undefined (type *BcProvider has no field or method SecretMigrator) (typecheck)
secret, err := b.SecretMigrator.CreateOrUpdateSourceCodeProviderConfigSecret("", toUpdate.ClientSecret, cluster, model.BitbucketCloudType)
^
pkg/pipeline/providers/bitbucketcloud/actions.go:109:16: b.SourceCodeProviderConfigs undefined (type *BcProvider has no field or method SourceCodeProviderConfigs) (typecheck)
if _, err = b.SourceCodeProviderConfigs.ObjectClient().Update(toUpdate.Name, toUpdate); err != nil {
^
pkg/pipeline/providers/bitbucketcloud/actions.go:111:23: b.SecretMigrator undefined (type *BcProvider has no field or method SecretMigrator) (typecheck)
if cleanupErr := b.SecretMigrator.Cleanup(secret.Name); cleanupErr != nil {
^
pkg/pipeline/providers/bitbucketcloud/actions.go:147:20: b.AuthAddAccount undefined (type *BcProvider has no field or method AuthAddAccount) (typecheck)
account, err := b.AuthAddAccount(userName, authUserInput.Code, config, config.ProjectName, model.BitbucketCloudType)
^
pkg/pipeline/providers/bitbucketcloud/actions.go:156:17: b.RefreshReposByCredentialAndConfig undefined (type *BcProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err := b.RefreshReposByCredentialAndConfig(account, config); err != nil {
^
pkg/pipeline/providers/bitbucketcloud/provider.go:50:25: b.SourceCodeProviderConfigs undefined (type *BcProvider has no field or method SourceCodeProviderConfigs) (typecheck)
scpConfigObj, err := b.SourceCodeProviderConfigs.ObjectClient().UnstructuredClient().GetNamespaced(projectID, model.BitbucketCloudType, metav1.GetOptions{})
^
pkg/pipeline/providers/bitbucketcloud/provider.go:65:41: b.SecretMigrator undefined (type *BcProvider has no field or method SecretMigrator) (typecheck)
storedBitbucketPipelineConfig, err = b.SecretMigrator.AssembleBitbucketCloudPipelineConfigCredential(storedBitbucketPipelineConfig)
^
pkg/pipeline/providers/bitbucketcloud/provider.go:18:2: "k8s.io/apimachinery/pkg/runtime" imported but not used (typecheck)
"k8s.io/apimachinery/pkg/runtime"
^
pkg/pipeline/providers/bitbucketserver/actions.go:48:12: b.DisableAction undefined (type *BsProvider has no field or method DisableAction) (typecheck)
return b.DisableAction(request, b.GetName())
^
pkg/pipeline/providers/bitbucketserver/actions.go:95:20: b.ClusterLister undefined (type *BsProvider has no field or method ClusterLister) (typecheck)
cluster, err := b.ClusterLister.Get("", clusterID)
^
pkg/pipeline/providers/bitbucketserver/actions.go:99:19: b.SecretMigrator undefined (type *BsProvider has no field or method SecretMigrator) (typecheck)
secret, err := b.SecretMigrator.CreateOrUpdateSourceCodeProviderConfigSecret("", private, cluster, model.BitbucketServerType)
^
pkg/pipeline/providers/bitbucketserver/actions.go:105:16: b.SourceCodeProviderConfigs undefined (type *BsProvider has no field or method SourceCodeProviderConfigs) (typecheck)
if _, err = b.SourceCodeProviderConfigs.ObjectClient().Update(toUpdate.Name, toUpdate); err != nil {
^
pkg/pipeline/providers/bitbucketserver/actions.go:107:23: b.SecretMigrator undefined (type *BsProvider has no field or method SecretMigrator) (typecheck)
if cleanupErr := b.SecretMigrator.Cleanup(secret.Name); cleanupErr != nil {
^
pkg/pipeline/providers/bitbucketserver/actions.go:201:33: b.AuthAddAccount undefined (type *BsProvider has no field or method AuthAddAccount) (typecheck)
sourceCodeCredential, err := b.AuthAddAccount(userName, code, toUpdate, toUpdate.ProjectName, model.BitbucketServerType)
^
pkg/pipeline/providers/bitbucketserver/actions.go:205:16: b.RefreshReposByCredentialAndConfig undefined (type *BsProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err = b.RefreshReposByCredentialAndConfig(sourceCodeCredential, toUpdate); err != nil {
^
pkg/pipeline/providers/bitbucketserver/actions.go:211:16: b.SourceCodeProviderConfigs undefined (type *BsProvider has no field or method SourceCodeProviderConfigs) (typecheck)
if _, err = b.SourceCodeProviderConfigs.ObjectClient().Update(toUpdate.Name, toUpdate); err != nil {
^
pkg/pipeline/providers/bitbucketserver/actions.go:245:20: b.AuthAddAccount undefined (type *BsProvider has no field or method AuthAddAccount) (typecheck)
account, err := b.AuthAddAccount(userName, code, config, config.ProjectName, model.BitbucketServerType)
^
pkg/pipeline/providers/bitbucketserver/actions.go:254:17: b.RefreshReposByCredentialAndConfig undefined (type *BsProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err := b.RefreshReposByCredentialAndConfig(account, config); err != nil {
^
pkg/pipeline/providers/bitbucketserver/provider.go:48:25: b.SourceCodeProviderConfigs undefined (type *BsProvider has no field or method SourceCodeProviderConfigs) (typecheck)
scpConfigObj, err := b.SourceCodeProviderConfigs.ObjectClient().UnstructuredClient().GetNamespaced(projectID, model.BitbucketServerType, metav1.GetOptions{})
^
pkg/pipeline/providers/bitbucketserver/provider.go:63:41: b.SecretMigrator undefined (type *BsProvider has no field or method SecretMigrator) (typecheck)
storedBitbucketPipelineConfig, err = b.SecretMigrator.AssembleBitbucketServerPipelineConfigCredential(storedBitbucketPipelineConfig)
^
pkg/pipeline/providers/bitbucketserver/provider.go:18:2: "k8s.io/apimachinery/pkg/runtime" imported but not used (typecheck)
"k8s.io/apimachinery/pkg/runtime"
^
pkg/pipeline/providers/github/actions.go:50:12: g.DisableAction undefined (type *GhProvider has no field or method DisableAction) (typecheck)
return g.DisableAction(request, g.GetName())
^
pkg/pipeline/providers/github/actions.go:127:33: g.AuthAddAccount undefined (type *GhProvider has no field or method AuthAddAccount) (typecheck)
sourceCodeCredential, err := g.AuthAddAccount(userName, applyInput.Code, toUpdate, toUpdate.ProjectName, model.GithubType)
^
pkg/pipeline/providers/github/actions.go:131:16: g.RefreshReposByCredentialAndConfig undefined (type *GhProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err = g.RefreshReposByCredentialAndConfig(sourceCodeCredential, toUpdate); err != nil {
^
pkg/pipeline/providers/github/actions.go:141:21: g.ClusterLister undefined (type *GhProvider has no field or method ClusterLister) (typecheck)
cluster, err := g.ClusterLister.Get("", clusterID)
^
pkg/pipeline/providers/github/actions.go:153:16: g.SourceCodeProviderConfigs undefined (type *GhProvider has no field or method SourceCodeProviderConfigs) (typecheck)
if _, err = g.SourceCodeProviderConfigs.ObjectClient().Update(toUpdate.Name, toUpdate); err != nil {
^
pkg/pipeline/providers/github/actions.go:191:20: g.AuthAddAccount undefined (type *GhProvider has no field or method AuthAddAccount) (typecheck)
account, err := g.AuthAddAccount(userName, authUserInput.Code, config, config.ProjectName, model.GithubType)
^
pkg/pipeline/providers/github/actions.go:200:17: g.RefreshReposByCredentialAndConfig undefined (type *GhProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err := g.RefreshReposByCredentialAndConfig(account, config); err != nil {
^
pkg/pipeline/providers/github/provider.go:56:25: g.SourceCodeProviderConfigs undefined (type *GhProvider has no field or method SourceCodeProviderConfigs) (typecheck)
scpConfigObj, err := g.SourceCodeProviderConfigs.ObjectClient().UnstructuredClient().GetNamespaced(projectID, model.GithubType, metav1.GetOptions{})
^
pkg/pipeline/providers/github/provider.go:21:2: "k8s.io/apimachinery/pkg/runtime" imported but not used (typecheck)
"k8s.io/apimachinery/pkg/runtime"
^
pkg/pipeline/providers/gitlab/actions.go:41:12: g.DisableAction undefined (type *GlProvider has no field or method DisableAction) (typecheck)
return g.DisableAction(request, g.GetName())
^
pkg/pipeline/providers/gitlab/actions.go:90:33: g.AuthAddAccount undefined (type *GlProvider has no field or method AuthAddAccount) (typecheck)
sourceCodeCredential, err := g.AuthAddAccount(userName, applyInput.Code, toUpdate, toUpdate.ProjectName, model.GitlabType)
^
pkg/pipeline/providers/gitlab/actions.go:94:16: g.RefreshReposByCredentialAndConfig undefined (type *GlProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err = g.RefreshReposByCredentialAndConfig(sourceCodeCredential, toUpdate); err != nil {
^
pkg/pipeline/providers/gitlab/actions.go:99:20: g.ClusterLister undefined (type *GlProvider has no field or method ClusterLister) (typecheck)
cluster, err := g.ClusterLister.Get("", clusterID)
^
pkg/pipeline/providers/gitlab/actions.go:103:19: g.SecretMigrator undefined (type *GlProvider has no field or method SecretMigrator) (typecheck)
secret, err := g.SecretMigrator.CreateOrUpdateSourceCodeProviderConfigSecret("", toUpdate.ClientSecret, cluster, model.GitlabType)
^
pkg/pipeline/providers/gitlab/actions.go:110:16: g.SourceCodeProviderConfigs undefined (type *GlProvider has no field or method SourceCodeProviderConfigs) (typecheck)
if _, err = g.SourceCodeProviderConfigs.ObjectClient().Update(toUpdate.Name, toUpdate); err != nil {
^
pkg/pipeline/providers/gitlab/actions.go:112:23: g.SecretMigrator undefined (type *GlProvider has no field or method SecretMigrator) (typecheck)
if cleanupErr := g.SecretMigrator.Cleanup(secret.Name); cleanupErr != nil {
^
pkg/pipeline/providers/gitlab/actions.go:148:20: g.AuthAddAccount undefined (type *GlProvider has no field or method AuthAddAccount) (typecheck)
account, err := g.AuthAddAccount(userName, authUserInput.Code, config, config.ProjectName, model.GitlabType)
^
pkg/pipeline/providers/gitlab/actions.go:157:17: g.RefreshReposByCredentialAndConfig undefined (type *GlProvider has no field or method RefreshReposByCredentialAndConfig) (typecheck)
if _, err := g.RefreshReposByCredentialAndConfig(account, config); err != nil {
^
pkg/version/version.go:4: File is not gofmt-ed (gofmt)
"fmt"
"strings"

Building Rancher 2.6.5 on my own with the following modification solved the crash on start-up:

go.mod | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/go.mod b/go.mod
index 94e0b1006..3bbbdc759 100644
--- a/go.mod
+++ b/go.mod
@@ -92,7 +92,7 @@ require (
github.com/rancher/aks-operator v1.0.5
github.com/rancher/apiserver v0.0.0-20220223185512-c4e289f92e46
github.com/rancher/channelserver v0.5.1-0.20220405170618-28c9b37deff1

github.com/rancher/dynamiclistener v0.3.1-0.20210616080009-9865ae859c7f

github.com/rancher/dynamiclistener v0.3.3
github.com/rancher/eks-operator v1.1.3
github.com/rancher/fleet/pkg/apis v0.0.0-20210918015053-5a141a6b18f0
github.com/rancher/gke-operator v1.1.3
--


feat: update project cache

Description
Linear Ticket
https://linear.app/autokitteh/issue/UI-855/cache-all-assets-on-first-load-files-triggers-connections-variables-to
What type of PR is this? (check all applicable)

[ ] 💡 (feat) - A new feature (non-breaking change which adds functionality)
[ ] 🔄 (refactor) - Code Refactoring - A code change that neither fixes a bug nor adds a feature
[ ] 🐞 (fix) - Bug Fix (non-breaking change which fixes an issue)
[ ] 🏎 (perf) - Optimization
[ ] 📄 (docs) - Documentation - Documentation only changes
[ ] 📄 (test) - Tests - Adding missing tests or correcting existing tests
[ ] 🎨 (style) - Styles - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
[ ] ⚙ (ci) - Continuous Integrations - Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
[ ] ☑ (chore) - Chores - Other changes that don't modify src or test files
[ ] ↩ (revert) - Reverts - Reverts a previous commit(s).

test

Why is when we are going to the "Assets" tab - fetchDeployments(projectId!, true); triggered?
We don't need to fetchEvents on initCache, only on the events page.

refactored
changed

Creating a new project doesn't refresh the validation state:
https://github.com/user-attachments/assets/53e820b8-bf9f-4e5d-bc76-1e922eefbb78

Moving between projects as well:
https://github.com/user-attachments/assets/d4f174bc-ade6-454d-a93e-ae3c4330bd51


missing some string of english translation

settings | Profile picture url
results
missing translation: en.g.upload
settings | Cover image url
results
missing translation: en.g.upload

https://github.com/golos-blockchain/golos-ui/commit/86b366750938c1dffda88a8882a9221ea6b71994


Could not create gzip reader for 'movies': EOF

goim load -db goim.sqlite
Dropping indices for: atom, name, movie, tvshow, episode
Could not create gzip reader for 'movies': EOF

My system has gzip 1.6.

It looks like the movies list is empty. Might need to try re-downloading it.

How to re-downloading it.?
I re-ran the same command and it showed the same error.

I tried the following:
goim load -db goim.sqlite -download .
Downloading movies to movies.list.gz...
Could not close FTP download: exit status 1

Filesize of movies.list.gz is 0.

For other that same the same issue as me.
Here is a way that work for me:
# Download movies.list.gz from IMDB and put in a directory(.e.g tarball)
goim load -db goim.sqlite tarball/
# Movies are processed but will show some errors as stated in issue#4.

Read the documentation? See goim help load. load can either download data for you (which is apparently failing) or you can download it manually and point goim to it. e.g.,
mkdir tmp-goim
goim load -download ./tmp-goim
ls -l ./tmp-goim/

Did it download a non-empty file? If so, try doing the download manually:
mkdir tmp-goim
goim load -urls
curl what-you-see-above.list.gz > tmp-goim/movies.list.gz
goim load ./tmp-goim

You can try different sources too, e.g., goim load -urls digital.


docs(react-tinacms-date): Typo fix: s/Craeted/Created/

✍✅

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@notjosh Please sign the CLA 🙏

@notjosh Please sign the CLA 🙏

Ah, that's a lot of legalese for such a trivial change :[
I'll leave it to an existing maintainer to fix. Thanks anyway!

Ah, that's a lot of legalese for such a trivial change :[
I'll leave it to an existing maintainer to fix. Thanks anyway!


Skip legacy container events simple consumer

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area driver-kmod

/area driver-ebpf

/area libscap

/area libsinsp

/area tests

/area proposals

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Ensure that old container event numbers are not returned by sinsp_filter_check_event::evttypes() and do not return true for sinsp::simple_consumer_consider_evtnum()

@mstemm: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

build-libs
817c9859024470310c545f922b41296714c2454e
link
true
/test build-libs

Full PR test history. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Consideration of removing an unnecessary dependency.

Hi,
I'm doing research on finding unnecessary dependencies in NodeJs packages. I found that one dependency (readable-stream) is not used in your package. So I modified the package.json file to remove the "readable-stream" dependency and I ran your tests. The result showed that all tests passed, and the test coverage did not change. Would you consider removing this dependency from your package, so that developers do not need to install them when they use your package?

Hi @SandZn — thanks for filing this! We will look into it.

hey @SandZn thanks for the report, I have opened PR #1213 to remove it and replace it's usage on tests by the native stream package.

@alvarowolfx Just for context, this was added in https://github.com/googleapis/nodejs-bigquery/pull/997


Doesn't work  with flag template-only-glimmer-components

with this add-on installed and template-only-glimmer-components turned on wrapping div is being created. It would be nice to provide an element as root to attach auto generated class to.

I'm not familiar with template only components and ember-component-css, but maybe try using

 in your template?

this would generate two divs with auto generated class:

the only way I was able to get it working correctly is by doing the following:
  init() {
    this._super(...arguments);
    this.tagName = 'div';
    this.classNames =['main-navbar', 'sticky', 'navCTA'];
    this.classNameBindings = ['styleNamespace'];
  }

and result is :

It would be useful to have logic not to generate outer div if {{styleNamespace}} is used in the template

I have done I little more digging. The way template-only-glimmer-components is that if there is now component.js file in the component folder outer div will not be generated. Feather more, here it looks like if tagName is not set on component the outer div will be generated even if I am already using {{styleNamespace}} inside the component. I guess to solve it would need to add additional check if {{styleNamespace}} is present in component template.

I know that isn't what a template-only-glimmer-components is, but until the new version is complete, that will be what you have to do.

@webark Thanks a lot for quick reply! Let me know if you need a hand getting this working. I would be happy to help!

What's the status on this? Since it also affects glimmer components I think as well.

Indeed it does, I have already asked this question in discord. But I guess it will take some time to make it forward compatible. I am more then willing to help but with some directions from maintainer

Hit this today when working with Glimmer and Sparkles components. Is there any movement forward to get something working for those cases?

When working with Sparkles Components you can do something like:
import Component from 'sparkles-component';
import podNames from 'ember-component-css/pod-names';

export default class ReportConfigButton extends Component {
  get styleNamespace() {
    return podNames['foo-bar'];
  }
}

Where foo-bar is the path for the current component.
I'd imagine that this is similar to what would be wanted when working with the let AST transform since at build time we have access to the current module path.

ya. if you look in PR #300, you can see the template transform that does that. (i ended up just doing a string adjustment cause it’s always wrapping i don’t have to go through the complexity of a handlebars transform)
That PR is held up due to me not really loving the babel transform that adds the styleNamespace into the component js files, and considering having to manually do the imports for addons similarly to how you do the templates with importing the layout

In 3.13

with this add-on installed and template-only-glimmer-components turned on wrapping div is being created.

is no longer true, and if you disable template-only-glimmer-components classes aren't generated either

The issue from a discussion with @rwjblue

import podNames from 'ember-component-css/pod-names';

This doesn't work in Ember 3.15
podNames contains:
default:
  components: "__components__dfa48"

@BryanCrotaz I’m sorry that you are running into this issue. :/ I will release the new beta version soon where you should have access to the class.


Interactive Dashboard

Description of the new feature / enhancement
You should be able to click on the module tiles on the new Dashboard to jump to that module's settings page.
Scenario when this would be used?
When you want to modify the setting of a module (most commonly, your enabled modules). It provides the convenience of not having to then search the sidebar for it.
Supporting information
No response

/dup #29501


Question regarding the settle modes to allow delayed message acknowledgement

I apologize in advance if this has been asked before. I've been struggling with this for the last two weeks and pulling out what little hair I have left :-/
I'm struggling with the link options that would allow me to receive an incoming message from an Azure IoT Hub (direct method invocation), process the message, accept or reject the incoming request based on the results of the message processing, and then send the response.
What tends to happen is the incoming message is already settled and then the send disposition just waits (client.go line 1833)
It's probably my understanding of things, but I can't get the right combination of Sender/Receive settle settings that allow this processing.
SenderLink Settings
	amqp.LinkProperty("com.microsoft:api-version", azuredevicesdk.APIVersion),  	amqp.LinkProperty("com.microsoft:channel-correlation-id", correlationID),  	amqp.LinkTargetAddress(dest),
ReceiverLink Settings
	amqp.LinkProperty("com.microsoft:api-version", azuredevicesdk.APIVersion), 	amqp.LinkProperty("com.microsoft:channel-correlation-id", correlationID), 	amqp.LinkSourceAddress(dest), 	amqp.LinkSenderSettle(amqp.ModeUnsettled), 	amqp.LinkReceiverSettle(amqp.ModeSecond),
Any insights or examples that you may be aware of to point me in the right direction would be greatly appreciated.
Thanks

Hi @talmdal, if the incoming message is already settled, there is no reason to send a disposition.
What is happening with the configuration above is that you are saying the receiver will wait for an ack on the disposition. This never comes, so the receiver waits indefinitely.
I believe if you set receiver settle mode to first, the receiver will assume the message sent to it will be settled and not try to send a disposition.
I think that's right, but I mix these up from time to time.
As an aside, have you tried using the event hub library to connect to Azure IoT? I think this should just work. If not, open an issue and we'll get it fixed.

Thanks @devigned! Not being familiar with IoT Hubs, does it support sending messages unsettled to the receiver? Sounds like @talmdal is looking for that behavior.
I should look into the hanging. The client should know which mode was negotiated and act appropriately. Or perhaps provide an error if the requested mode wasn't negotiated. I have run across brokers that simply echo back the mode even if they don't support it though (it wasn't a Microsoft broker).

Thanks guys for the quick response. I had used the Azure Java sample programs and SDK as the model to understand the message flow. (which receives, processes, acknowledges and sends the result)
I have tried setting the mode to first and then the go client doesn't hang, but the request in the portal times-out. I had seen this behavour in the Java SDK, when I took a while to send the disposition.
So I'm not sure I have the link settings right.
@devigned I'll take a look at using the event hub library. I had seen it, but didn't think I could use it
Thanks again for your input

@talmdal I'll look into what's going on between the portal and client lib, and report back. I should be able to get to it today.

@devigned: thanks I appreciate it.  as an aside, sending device-2-cloud messages, receiving cloud-2-device, updating the twin properties and receiving twin updates all work. So I'm pretty sure, it's the "idiot" behind this keyboard that is the problem

@talmdal no worries :). This stuff is complicated!
Unfortunately, I ran out of time to try this out today. I'll update tomorrow.

@talmdal It seems I didn't read your original post thoroughly enough, my apologies. So it's hanging at line 1833 as seen here?
https://github.com/vcabbage/amqp/blob/d48c91ecba2ea50cd732db309a13cbbc2a25262b/client.go#L1832-L1834
That would be unexpected since that path shouldn't be taken unless batching is enabled. What version are you using? Batching was enabled by default until 0.9.0.

I'm using v0.10.3
It takes the else branch and then waits 11 lines later at 1845:
    return <-wait

@vcabbage, It looks like the incoming message is being settled on line 1135 (client.go).
I'm probably doing something wrong with the link options that are causing the receiver settle modes to be negotiated into an inconsistent state so the sender is settling it and the client is expecting to have acknowledge the message.

If the received message is already settled it shouldn't try to send a disposition due to:
https://github.com/vcabbage/amqp/blob/d48c91ecba2ea50cd732db309a13cbbc2a25262b/types.go#L1812-L1814
Say, are you using msg.Release()? I see I have a really silly bug in the logic. It should be !m.shouldSendDisposition()
https://github.com/vcabbage/amqp/blob/d48c91ecba2ea50cd732db309a13cbbc2a25262b/types.go#L1773-L1780
I'll get that fixed shortly.

No I'm using Accept().
I'm using the following settle options when I create the receiver options:
amqp.LinkSenderSettle(amqp.ModeUnsettled),
amqp.LinkReceiverSettle(amqp.ModeSecond),

I think there are two problems:

The first is my understanding of the interaction between the Azure IoT Hub that the received request needs to be manually acknowledged, based on the flow I observed in the Java IoT SDK, which could be flawed.  It's based on the assumption that the flow shouldn't change based the client (they use qpid java client)
The second is because I have set the receiver settle mode to ModeSecond, it effectively ignores that the message is settled (on line 1813 !m.settled is false, but the 2nd half will return true if the receiver is mode is modeSecond)

Not sure if this is possible or where it would be appropriate, but getting a warning that the settle modes are inconsistent in this case... Or, should the || on line 1813 be a &&
Tim

2. The second is because I have set the receiver settle mode to ModeSecond, it effectively ignores that the message is settled (on line 1813 !m.settled is false, but the 2nd half will return true if the receiver is mode is modeSecond)

Oh yes, you're right. Thanks for pointing that out :)

Not sure if this is possible or where it would be appropriate, but getting a warning that the settle modes are inconsistent in this case... Or, should the || on line 1813 be a &&

I'm starting to think it should be an error if the server returns settlement modes different from what you requested. If there is a use case where one needs to allow that, it could be controlled via an additional link option.
&& may be the correct logic there. I'll need to dig into it a little to verify. ModeSecond has always been a bit tricky in my mind.
So we can confirm what exactly is happening, would you be able to build with -tags debug and provide the output (https://github.com/vcabbage/amqp/blob/master/CONTRIBUTING.md#logging)?

Sure, I can do that

I edited the file to add a descriptive line before the direct method request entries. From what I can see, is the negotiated settle modes completely ignore the requested modes.
I just had an off the wall thought. I have 3 "channels" that I want to have bi-directional conversations on. I only have one session that is the "parent" of each of the link pairs. Could this be cause the problem and should I have a separate session for each one?
Hope this helps.
trace_level9.txt

Agreed, the server is responding back with SenderSettleMode: settled, ReceiverSettleMode: first to your SenderSettleMode: unsettled, ReceiverSettleMode: second.
For sender settle mode the spec says:

When set at the receiver this indicates the desired value for the settlement mode at the sender. When set at the sender this indicates the actual settlement mode in use. The sender SHOULD respect the receiver's desired settlement mode if the receiver initiates the attach exchange and the sender supports the desired mode.

For receiver settle mode:

When set at the sender this indicates the desired value for the settlement mode at the receiver. When set at the receiver this indicates the actual settlement mode in use. The receiver SHOULD respect the sender's desired settlement mode if the sender initiates the attach exchange and the receiver supports the desired mode.

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-attach
So the behavior is certainly within spec for sender mode. Whereas it might not be for the receiver mode. Not all brokers support all modes in all situations though, that may be what's happening here. @devigned, do you have any thoughts on this?
As for this library, I still think the correct behavior is to return an error on mistmatch. Currently it doesn't look at the server's receiver settle mode at all, which explains the hangs you've experienced.

I just had an off the wall thought. I have 3 "channels" that I want to have bi-directional conversations on. I only have one session that is the "parent" of each of the link pairs. Could this be cause the problem and should I have a separate session for each one?

Each broker does seem to have their idiosyncrasies. My guess is it's just not supported for that link address (not sure on the IoT Hub terminology for that link).

Thanks for the quick response,
I might give it a try to create a session for each conversation to see if I can rule out any overlap on different settings.
I think you are right, in providing some feedback to the application when there is a settlement mismatch.  I've always said if you want to find all the corner case in software give it to the user (in this case that's me) and we will find ways to break it 😉

@shubha or @clemensv any thoughts on the Event Hubs interpretation of this issue?

I've always said if you want to find all the corner case in software give it to the user (in this case that's me) and we will find ways to break it

Bug reports like this are very much appreciated! I started writing this library because I wanted to see if I could avoid C bindings and it sounded like fun. It pretty much only worked for my limited use case initially (I'm using a rather generous definition of "worked"). It would still be that way if it weren't for all the contributions; including bug reports, discussions, and code.

An update from playing this weekend.
I tried to create 3 sessions, one per conversation, but that didn't help, but I noticed was that when I created the third session, the second session closed.  End of that trial.
I did notice a different behavior if I didn't explicitly set the settle modes on the sender link that that I was trying to send the response on. Without them set, the message was transferred and the remote responded with settled and accepted:

08:02:59.403202 TX(link): Transfer{Handle: 4, DeliveryID: 3, DeliveryTag: "\x00\x00\x00\x00\x00\x00\x00\x00", MessageFormat: 0, Settled: false, More: false, ReceiverSettleMode: , State: , Resume: false, Aborted: false, Batchable: false, Payload [size]: 196}
08:02:59.403230 TX(Session): Transfer{Handle: 4, DeliveryID: 3, DeliveryTag: "\x00\x00\x00\x00\x00\x00\x00\x00", MessageFormat: 0, Settled: false, More: false, ReceiverSettleMode: , State: , Resume: false, Aborted: false, Batchable: false, Payload [size]: 196}
08:02:59.440661 RX(Session): Disposition{Role: Receiver, First: 3, Last: , Settled: true, State: Accepted, Batchable: false}
08:02:59.440714 RX: Disposition{Role: Receiver, First: 3, Last: , Settled: true, State: Accepted, Batchable: false}

Whereas, if I set settle mode to sender: Settled and receiver: First, I see no response from the remote:

07:57:58.316303 TX(link): Transfer{Handle: 4, DeliveryID: 3, DeliveryTag: "\x00\x00\x00\x00\x00\x00\x00\x00", MessageFormat: 0, Settled: true, More: false, ReceiverSettleMode: , State: , Resume: false, Aborted: false, Batchable: false, Payload [size]: 196}
07:57:58.316328 TX(Session): Transfer{Handle: 4, DeliveryID: 3, DeliveryTag: "\x00\x00\x00\x00\x00\x00\x00\x00", MessageFormat: 0, Settled: true, More: false, ReceiverSettleMode: , State: , Resume: false, Aborted: false, Batchable: false, Payload [size]: 196}

Interesting, but not sure that it impacts the problem at hand, just reaffirms something I learned along time ago... always be explicit when setting options. 😉
I have been unable to find any details on what the amqp message flow on the IoTHub side of things is in order understand why the negotiation between the remote and my program is failing when trying to set the settle modes.

I did some more digging and I think I might be chasing a ghosts here.  I was able to dump the message when it arrives in the Java SDK client I've been using as a message flow model, and was surprised to find that it had been settled on the remote.  Then I spent sometime following the acknowledgement logic and found that it recognizes the remote has settled the message and doesn't try to send a disposition, just does some local message handling cleanup
I changed the || to a && in shouldSendDisposition locally and I didn't get the "hang" that I was seeing.
At this point, I think we can call this issue resolved and you can close it unless you want to keep it open  to address the error when the sender settle mode don't match expected.
Thanks for everyones input

Thanks for the update! I'm going to leave this open at least until I'm able to determine the proper way to handle this. I think a library blindly accepting the settlement mode when the user requested something different is at best surprising but could also have more serious ramifications if the application logic expects a particular mode.
I found another reference to the settlement modes here: https://issues.oasis-open.org/browse/AMQP-37

Clarify the text to make clearer that the initiator is getting the chance to choose the settlement policy of its peer. For example a client can choose the policy it wants at the broker, and if the broker supports the policy it SHOULD agree to the client's request.

This make's me think the intention is to allow the client to request the modes but the broker gets to decide. The spec seems less clear on this, to me at least.
My understanding of settle modes is that sender and receiver settlement states are independent. The settled bool on the message corresponds only to the sender's settlement state. If that's correct, the || in shouldSendDispostion isn't necessarily the problem. Rather it goes back to the link not being updated with the receiver settle mode from the broker's attach frame. If it were the second part of the expression would also evaluate to false and it would not attempt to send the disposition.
Thanks again for taking the time to work though this and reporting your findings, I really appreciate it!

After reading the spec as well, I think you are on the right track.  It looks like it's not really an error condition, as it seems to be a normal course of events for the sender to potentially ignore the request from the receiver as it does say "SHOULD" not "MUST". From my understanding, the "|| ..." is just not needed as if the received message is already settled, then there is really no option, but accept that.
Thanks again

I've merged the error on mismatch logic and tagged it as v0.11.0.
I'm going to go ahead and close this issue. Please feel free to reopen if I've missed anything.


Add contact us section #25

closes #25

Sir , please review and please change the label of this issue to hard as I have spent almost one day to complete the issue.
please change..

The form is showing odd for the site make it smaller from height like font size or other

ok!

sir , please merge..

Is it the final version but there is a responsive problem.
A horizontal bar coming in home page


unable to update data with nulls or empty strings

Env information:
mysql: Ver 14.14 Distrib 5.7.14, for osx10.11 (x86_64)
node: 6.9.2,
knex: 0.11.7,
objection: ^0.5.2
Here is the model I am using as an example.  As you can see I have "street2" schema set to string or null.  I have ran this same test with setting the property to only null with the same results.

Here is a screenshot of my database schema.  As you can see "street2" is allowed nulls.

Here is my PUT request which is using the update() method with objection (see below).  This shot was taken after sending the request, below is the response.  As you can see, street2 did not update with null or an empty string value.

Here is my code for the update query.  Location has a belongs to one relationship with address.  I know this test would probably be better by bypassing the relationship however I am importing the Address model  directly and running the query directly on the Address table/model.

With the debug running you can see the two outcomes of running the above query.  The first is when I updated street2 (defaults to null in our seed file) to "APT B".  You can see the data is in the bindings array of the queryobject.  The 2nd update it is missing completely.  This behavior also occurs with empty strings ("").

Here I am updating the database with straight knex.  And it works fine, this is leading me to believe this is a bug with Objection.

I wrote a test case and it seems to work ok. Have you tried this with objection 0.6.X?

Hey Koskimas - I just tested again with 0.6.2 and I get the same behavior

These both tests work on all databases:
      it('should be able to update to null value', function () {
        return Model1
          .query()
          .update({model1Prop1: null, model1Prop2: 100})
          .where('id', '=', 1)
          .then(function (numUpdated) {
            expect(numUpdated).to.equal(1);
            return session.knex('Model1').orderBy('id');
          })
          .then(function (rows) {
            expect(rows).to.have.length(3);
            expectPartEql(rows[0], {id: 1, model1Prop1: null});
            expectPartEql(rows[1], {id: 2, model1Prop1: 'hello 2'});
            expectPartEql(rows[2], {id: 3, model1Prop1: 'hello 3'});
          });
      });

      it('should be able to update to an empty string', function () {
        return Model1
          .query()
          .update({model1Prop1: '', model1Prop2: 100})
          .where('id', '=', 1)
          .then(function (numUpdated) {
            expect(numUpdated).to.equal(1);
            return session.knex('Model1').orderBy('id');
          })
          .then(function (rows) {
            expect(rows).to.have.length(3);
            expectPartEql(rows[0], {id: 1, model1Prop1: ''});
            expectPartEql(rows[1], {id: 2, model1Prop1: 'hello 2'});
            expectPartEql(rows[2], {id: 3, model1Prop1: 'hello 3'});
          });
      });

Are you absolutely sure the null values are present when the update operation is done? I'm unable to reproduce this.

  Thanks for helping out here - it turns out one of our other functions was removing data that was null (a filter).  Thanks for you time and efforts on this one.

😄 No problem.


Use bash in prepare scripts

Prepare scripts that use #!/bin/sh and
source "$HOME/.sdkman/bin/sdkman-init.sh"
fail on systems where sh is not bash,
e.g. on Ubuntu it is dash which has not source.

Thx!


chore(sequencer)!: update storage keys locations and values (ENG-898)

Summary
The storage keys for all components were moved from the top of  state_ext modules into new storage::keys modules.  The key values were updated to a consistent style.
Background
We wanted the keys to be easy to find and to follow a consistent pattern in terms of their values and locations.
Changes

All key consts and functions were moved to <COMPONENT>/storage/keys.
All keys were given a prefix matching the component name followed by a /.
All keys now use full words (except for a few instances of well-know abbreviations like "init") and _ as word separators.
Existing helper structs in various state_ext modules for formatting keys were unified into a new struct AddressPrefixer in crate::storage.
The Asset functionality was moved from crate::storage_keys to crate::storage.

Testing

All keys have snapshot tests (including const keys - this might be considered overkill?)
All keys have tests ensuring they have a component name as prefix.
All prefix consts or functions which are used in state_ext modules are tested to ensure they are actually prefixes of the given keys.

Breaking Changelist

This breaks the on-disk format of both the verifiable and non-verifiable store.

Related Issues
Closes #1611.

I wonder if in this PR we should just change base64 encoding to the url safe alphabet everywhere (so that we don't have a different encoding in the storage keys and the normal display impl).

Ticketed for follow-up at #1649.


MSK AWS connect

Im trying to set the connector in AWS connect with a MSK serverless cluster in AWS but I keep getting the error:

[Worker-016e5f49a1715bc84] [2023-05-10 17:40:33,607] WARN [iceberg-sink-connector\|task-0] Unable to retrieve the requested metadata. (software.amazon.awssdk.regions.internal.util.EC2MetadataUtils:398)
--
[Worker-016e5f49a1715bc84] [2023-05-10 17:40:33,608] ERROR [iceberg-sink-connector\|task-0] WorkerSinkTask{id=iceberg-sink-connector-0} Task threw an uncaught and unrecoverable exception. Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:191)
[Worker-016e5f49a1715bc84] software.amazon.awssdk.core.exception.SdkClientException: Unable to load region from any of the providers in the chain software.amazon.awssdk.regions.providers.DefaultAwsRegionProviderChain@c649ef2: [software.amazon.awssdk.regions.providers.SystemSettingsRegionProvider@52410e10: Unable to load region from system settings. Region must be specified either via environment variable (AWS_REGION) or  system property (aws.region)., software.amazon.awssdk.regions.providers.AwsProfileRegionProvider@2d28feba: No region provided in profile: default, software.amazon.awssdk.regions.providers.InstanceProfileRegionProvider@1c19d17a: Unable to retrieve region information from EC2 Metadata service. Please make sure the application is running on EC2.]

Any suggestion on how to declare region in the connector?

this is my config by the way:
"connector.class"= "com.getindata.kafka.connect.iceberg.sink.IcebergSink"
"tasks.max"= "1"
"topics"= "sqa-sdiv-data-warehouse.public.test_2,sqa-sdiv-data-warehouse.public.test_table"

"upsert"= true
"upsert.keep-deletes"= true

"table.auto-create"= true
"table.write-format"= "parquet"
"table.namespace"= "sdiv"
"table.prefix"= "cdc_"

"iceberg.catalog-impl"= "org.apache.iceberg.aws.glue.GlueCatalog"
"iceberg.fs.defaultFS"= "s3a://sqa-subdiv-kafka-iceberg-poc/sdiv-iceberg"
"iceberg.warehouse"= "s3a://sqa-subdiv-kafka-iceberg-poc/sdiv-iceberg"
"iceberg.fs.s3a.endpoint.region" = "us-west-2"
"iceberg.fs.s3a.endpoint" = "s3.us-west-2.amazonaws.com"
"iceberg.com.amazonaws.services.s3.enableV4"= true
"iceberg.com.amazonaws.services.s3a.enableV4"= true
"iceberg.fs.s3a.aws.credentials.provider"= "com.amazonaws.auth.DefaultAWSCredentialsProviderChain"
"iceberg.fs.s3a.path.style.access"= true
"iceberg.fs.s3a.impl"= "org.apache.hadoop.fs.s3a.S3AFileSystem"

I am having the exact same issue. Unable to specify the region to the worker in any way

Facing the same issue.

Solved by modifying the connector and compiling it again, tomorrow will share the modified code so you can do the same

Ok, it will be very helpful. waiting for updated connector.

@clazalde , I would appreciate if you can share the updated connector. Thanks in advance.

In the public void start(Map<String, String> properties) {
Add the following:
System.setProperty("aws.region", "us-west-2");
Replace it with your region

@clazalde , I have set the aws.region. Now I am getting below error:-
Task threw an uncaught and unrecoverable exception. Task is being killed and will not recover until manually restarted. Error: Unable to execute HTTP request: connect timed out (org.apache.kafka.connect.runtime.WorkerSinkTask:612)

I am also facing the same issue while trying to use this connector in AWS MSK cluster. Any input would be greatly appreciated. 🙏
software.amazon.awssdk.core.exception.SdkClientException: Unable to load region from any of the providers in the chain


Clean GToolkit baseline

There are many messages in our install.log that can be easily solved:
NewUndeclaredWarning: GtRlRepository>>gtRepoMapFor: (BlTextElement is Undeclared)

It breaks our build. It requires more time to clean all baselines. I will do it another day.


Fix if elseif condition

No reason to use "elseif" condition with return inside

Thanks for contributing this. The normalize_color method has been rewritten in 3.0 and doesn't use elseif.


Add Transaction API Tests

This PR adds more tests to cover some testing coverage gaps in newrelic/api/transactions.py

Codecov Report

Merging #857 (ecaa16a) into main (c2fd5e3) will increase coverage by 0.14%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #857      +/-   ##
==========================================
+ Coverage   79.24%   79.38%   +0.14%
==========================================
  Files         183      183
  Lines       18368    18368
  Branches     3183     3183
==========================================
+ Hits        14556    14582      +26
+ Misses       2966     2928      -38
- Partials      846      858      +12

see 7 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Cannot execute because a node is missing the class_type property.: Node ID '#9'

Tripo:Generate Draft model节点有问题，加载不上，我确定API_Key设置是对的，也可以正确返回结果，但在Comfyui里就是无法使用，请告诉我这是什么错误？

Please update to the newest version and try again.

Are you still having this issue?


test for TimeConvolve - [merged]

In GitLab by @artpelling on Mar 24, 2021, 21:32
Merges tprocess_test -> master

adds TimeConvolve to init.py
adds a simple test that compares the output of TimeConvolve to numpy.convolve
adds functionality for the case where the kernel is shorter than num
fixes a bug
ensures that the output length is always N+M-1, even for uncommon signal length and blocksize combinations
moves _validate_kernel to results to avoid error when no source is defined
changes errors to warnings in validation for a softer behaviour

In GitLab by @artpelling on Mar 25, 2021, 15:17
added 1 commit
e1529ca2 - reinstate error messages
Compare with previous version

In GitLab by @artpelling on Mar 25, 2021, 09:38
added 4 commits
98d533ae...0c3840da - 2 commits from branch acoular-dev:masterc21c9edf - add to init.py, add test, fix output length for special cases6f4afbb9 - typo, print debugging...
Compare with previous version

In GitLab by @artpelling on Mar 24, 2021, 21:38
added 5 commits
a4651944...b2e3dc32 - 4 commits from branch acoular-dev:masteredc97f4f - add to init.py, add test, fix output length for special cases
Compare with previous version

In GitLab by @artpelling on Mar 24, 2021, 23:01
added 1 commit
98d533ae - typo, print debugging...
Compare with previous version


Before, getting the version also download the manifest.
Now, the manifest needs to be explicitly downloaded.
Task getService still returns the manifest, but task listService doesn't
TODO:

[x] improve mesg.yml when https://github.com/mesg-foundation/core/pull/863 is merged (can be done in another PR).

need to update mesg.yml as well

Done. Please review


Expose dropped publish messages count in sys info

PublishDropped renamed to MessagesDropped for alignment with MessagesSent and MessagesReceived, which refer only to publish packets.
Exposes the PublishDropped/MessagesDropped statistic via $SYS topics per #167 on $SYS/broker/messages/dropped

cc @thedevop - FAO, above name change! Thank you

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 4 (100.0%)  changed or added relevant lines in 2 files are covered.
6 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.1%) to 98.473%

Files with Coverage Reduction
New Missed Lines
%

server.go
6
99.04%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
5093

Relevant Lines:
5172

💛  - Coveralls


@orta=>Email settings

[x] Email settings main view controller
[x] UI polish
[x] Tests

will close #43 and #44

@orta greening :green_apple:

OK, the question about the AREmail defaults is a blocker otherwise it's mergable :+1:

Then this looks :+1:


Add fluentnamer plugin

This PR includes changes to add a new plugin for fluent namer. The plugin sits between preprocessor and javagen plugin and when activated will use the code model yaml file generated from preprocessor to make necessary changes to the names of types and then output another code model yaml file which will then be consumed by javagen plugin.

BTW, @jianghaolu . Any advice on the fluentgen PR itself? https://github.com/Azure/autorest.java/pull/460

@weidongxu-microsoft initially, my thoughts were similar to what you mentioned about having 2 parallel pipelines:
javanamer -> javagen
fluentnamer -> fluentgen
However, after talking to @jianghaolu, it made sense to have just one plugin consume the code model from modelerfour and do the initial transformation. This parsing of input code model is common to both javanamer and fluentnamer and the transformation is going to be mostly common and only a few changes might be required in fluentnamer (I am assuming here, correct me if that's not the case). So, instead of duplicating the same logic in both plugins, this new approach was used.

The reason to put fluentnamer after javanamer is so that we can avoid duplicating the code for common renamings. And I suppose any new classes added after javanamer can just be named correctly by itself.
What are some specific scenarios where having fluentnamer after javanamer will make it more difficult for you?

@srnagar @jianghaolu
There is not really concern on duplicate code. Basically the fluentnamer would just depends on preprocessor module and call the same Transformer.transform function. A few lines, done. (there might be some issue when package to single jar, about duplicate resource or such, but seems not too bad)
Well, even if preprocessor and fluentnamer is concatenated, fluentnamer would still depends on preprocessor module. Anyway I will need all the common rename methods. I will certainly not add a CodeNamer by myself.
BTW, about duplicate code, why do we have 2 CodeNamer java file (one in preprocessor and one in javagen), which is almost same?
That said, currently there should be no blocking issue for me to move transform after the naming stage (e.g. add apiVersion parameter to all operations, add some beginFoo operation for LRO operation), etc. I can manage it.
You can go ahead and merge. I will try to adapt if possible.

I'm okay with Weidong's proposal. It simplifies our flow too since javagen will no longer require output from fluentnamer (which was a bit confusing to me) @srnagar what do you think?

I am okay with the proposal too. I have updated the PR based on the discussion. So, the pipeline will be:
Data: modelerfour/identity -> preprocessor (may change name) -> javagen
Fluent:  modelerfour/identity -> fluentnamer -> fluentgen


v0.134.3

Merge pull request #3213 from dependabot/updates/issues/1104-rust-issues
Merge pull request #3153 from GiriB/azure_pr_updater
using securerandom instead of uuid
adding uuid to temp branch name
renaming function call in azure pull request updater
renaming fetch_pull_request function
adding pull request updater for azure client

Diff: https://github.com/dependabot/dependabot-core/compare/v0.134.2...0.134.3-release-notes

There are a few other changes in https://github.com/dependabot/dependabot-core/compare/v0.134.2...0.134.3-release-notes that look like they may warrant a minor version bump rather than just patch. WDYT?

kjk

I just merged a pr fixing the flaky npm spec
On Thu, 4 Mar 2021 at 17:00, mo khan<EMAIL_ADDRESS>wrote:

kjk
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/dependabot/dependabot-core/pull/3231#issuecomment-790768419,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAE5RLDA5EW6QG2WGUGDBTTB64CRANCNFSM4YTS6U7A
.


Decide if Option and Option should always respect features

Currently the string-null-empty feature only operates on fields that were not explicitly set as optional in the go sdk. If the field was set as optional, we don't generate an empty value for it and it stays an Option<String> on the Rust side. Similarly, we only synthesize empty HashMaps if the field was not explicitly set as optional.
This could be confusing, as sometimes you get a default and don't need to handle an Option (if the field was marked as required) and sometimes you do (if the field was marked as optional). One could reasonably expect to always get Strings or HashMaps with a default and I am not sure the current distinction is clear or important.
Should we unify the behavior here to better match expectations? Or would users prefer the current split behavior that matches the go sdk?

/cc @quezlatch @srijs for opinions

that's a tricky one... I think go with the current behaviour, and see how things shake out after it's been used in the wild a bit

The events crate has now moved to https://github.com/LegNeato/aws-lambda-events. Because of GitHub limitations (https://help.github.com/articles/transferring-an-issue-to-another-repository/) this issue is being closed rather than transferred.
If it is still relevant, please open an issue in the new repo.
Sorry for the churn!


Bring dev up to date with compatible changes from benleb/ad-automoli

Updated branch manually so closing this pull request.


AzureServiceBus target: eventOptions is not listed as optional in the CRD docs

@FranBarrera perhaps you can confirm if this is a "bug" ?

I'm seeing similar things on the other Azure targets, but not on other targets like AWS.

@jmcx It's optional but it's not marked to optional, actually I see this problem to almost all components that have this parameter (not only azure). I'm not sure what you mean with not on other targets like AWS, can you point me to an AWS Target that doesn't have the problem?

For example the SQS target doesn't seem to have the same "eventOptions" param https://docs.triggermesh.io/1.25/reference/targets/#targets.triggermesh.io/v1alpha1.AWSSQSTargetSpec


Subscription via newsletter fails

I tap the link on the homepage and... No reaction.

Hi, @mightyiam. Thanks for the feedback. We currently haven't prepared the newsletter. Please stay tuned.

is there any plan for this function?


Heavy tearing in fullscreen with V-Sync disabled

Godot version:
Godot 3.2.2 stable
OS/device including version:
GTX 1070 Windows 10 1909 GLES 2,3
Issue description:
fullscreen has mush more(or the only mode that has) tearing when disabling Vsync.
Steps to reproduce:
Disable Vsync
Shake the screen on window mode and then on fullscreen and see the tearing.
Minimal reproduction project:
Press Space to toggle fullscreen and window mode.
Tearing.zip

You will always get tearing with V-Sync disabled. Godot can't bypass the monitor's physical limitations :slightly_smiling_face:

Playing in a smaller window will make tearing less noticeable since the window will occupy a lower portion of your vision.

@Calinou
How about maximized window?
with resulotion of 8K? shouldn't that put some tearing?
and force fps to be 60 or below?
i can't see a single tear, it only happen in fullscreen or maximized borderless.

@Calinou
making project setting resulotion exactly my screen resulotion and putting it borderless get rid of the tearing in fullscreen like display.
How do you explain that?

@Gerarama Windows gives different a process priority to applications in fullscreen mode compared to those in windowed mode. See Fixing jitter and stutter in the documentation.

@Calinou
The link you doesn't explain how this solution works at all.
it talks about stutter effect between windowed and fullscreen mode, which is not our problem anyway.
based on the doc a special priority get rid of the stutter.
and create tearing problem?
so doesn't getting rid of stutter result in tearing?

so doesn't getting rid of stutter result in tearing?

V-Sync prevents tearing by increasing the delay with which frames are displayed. You can't have your cake and eat it, unless you have a variable refresh rate monitor (NVIDIA G-Sync or AMD FreeSync). Variable refresh rate requires compatible hardware and some special setup to get it to work flawlessly, so it's not for everyone.

After laborious testing and talking with @Gerarama in discord I can confirm that they do not understand how screen tearing happens, and what the various approaches are for fixing it. And how and when the desktop window manager of windows will enable/disable vsync settings.
Everything is working fine.
Tearing occurs in the provided project in all cases in which vsync is disabled. This means disabled within godot, and disabled within windows and or drivers.
If vsync is enabled, in godot or via the desktop window manager or drivers, then no tearing occurs.
I have a RTX2070 super, running the project at upwards of 2000 fps with vsync disabled. and a 144hz gsync compatible monitor. (however, godots vsync implementation is locked to 60hz and is not compatible with gsync at this date)
TL:DR: Issue can remain closed. No issue to be found.

To further squash this: the photos are confirmed to be taking with a camera suffering from long exposure time and long shutter speed. Meaning that images become blurry unless a steadycam or tripod is used, and that either way it will capture several frames to composite one image. Hence why its blurry/ghosting. Its entirely the cameras fault.

Having talked to @TheDuriel in discord he seems to not undertand how vsync work, and how there is no relation between the window modes and vsync being enabled or disabled, having i prove it with my testing of borderless windows.
he kept talking about fullscreen optimization and windows priority and non sense without proofs.
and he said that it can be fixed by changing some windows settings and he didn't show any.

To further squash this: the photos are confirmed to be taking with a camera suffering from long exposure time and long shutter speed. Meaning that images become blurry unless a steadycam or tripod is used, and that either way it will capture several frames to composite one image. Hence why its blurry/ghosting. Its entirely the cameras fault.

and here is trying to make it sound stupid by blaming my camera.
even tho its So clear that the tearing is happening, but heck here is even better photos with better camera:

This ticket is pointless. VSync is the method to prevent tearing. Disabling VSync disables any guarantees regarding tearing. The picture on the screen may or may not have tearing.

making project setting resulotion exactly my screen resulotion and putting it borderless get rid of the tearing in fullscreen like display.
How do you explain that?

You could as well say "Shooting people in the head kills them, please fix it", and then "I just shot someone in the head and he survived, how do you explain that?"
No guarantees when VSync is off means just that: no guarantees.
Sometimes tearing is reduced because the different conditions cause a slight shift in framerate, causing the natural framerate of the monitor to align with the game's, reducing the frequency in which tearing manifests.
Other times it's because the OS is performing vsync behind your back (i.e. silently introduces latency) or changes how presentation is being made (blitting vs flipping), thus window, borderless window and exclusive fullscreen all manifest different kind of tearing behaviour or even no tearing at all.

@darksylinc
Nope, its indeed using my project settings only when the fullscreen is enabled.
see gl_context->set_use_vsync(video_mode.use_vsync); in os.windows.cpp
You havn't added any new information to this topic,
rather then confirming that OS has something to do with this.
What this topic was all about is why does tearing only happen in fullscreen when disabling vsync, while no tearing ever happen in windowed mode.
If you can't answer that, then ignore the issue, because if i want vsync to be off in windowed mode, then its an issue and i have the right to open it.

What this topic was all about is why does tearing only happen in fullscreen when disabling vsync, while no tearing ever happen in windowed mode.

Because in windowed mode the compositor is rendering to the screen using VSync, and often the game present to the compositor via the blitting model.
When you switch to fullscreen, it is a direct path to the monitor. No compositor (hence no implicit VSync) and the presentation model to the monitor is often flip instead of blit.
If you suspect VSync is always enabled in windowed mode, then the framerate must be locked to 60 fps (assuming a 60hz monitor and the computer is fast enough) while in windowed mode, while uncapped in fullscreen.
If you get e.g. 1000 fps while in windowed mode, then VSync is off. Whether you get tearing or not.

finally some reasonable statement.
True that explains everything.
And it sonuds like there is no way to disable it, Because its Windows thing.
Thank you!!


4.8 PCH regression

what's going on here?
https://builds.gradle.org/viewLog.html?buildId=12757521&buildTypeId=Gradle_Check_PerformanceExperimentCoordinator

PR: https://github.com/gradle/gradle/pull/5358


[Feature] POTCAR generation allow using VASP recommended potential

POTCAR generation allow using VASP recommended potential here: https://cms.mpi.univie.ac.at/vasp/vasp/Recommended_PAW_potentials_DFT_calculations_using_vasp_5_2.html

Added by e6c34d1ccc82ee92e844798870a11b125e87c0b8.


Release 1.1.0

Syncing all dev changes to master so we can then cut a new 1.1.0 release.

Radix component support
ref="forwardedRef" opt-in behavior
nanoid
polygon tag
Custom React tags

I think we are missing Radix changes from CHANGELOG. Also let's change Pending to 1.1.0

Good catch. I updated the CHANGELOG @evgenykuzyakov: https://github.com/NearSocial/VM/pull/23/commits/13b3a317530d4565b80f19247891cd80bc118b27


Add a Read-Me

     This PR creates a read-me for this repository by adapting some wording from helloSystem's Filer's read-me and the introduction to Apple's short online Finder help page for it.  Whether it's kept around when this repository gets merged into the main ravynOS one or not is something I'll leave up in the air (though I'll note that GitHub automatically displays read-mes it finds in any folder for that directory, not just the repository root, even if that folder isn't a Git submodule.)
Potential future directions:

Add a build status badge.
Add a sentence at the end of the introduction paralleling the one in the Apple technical note linked above explaining why this project's called 'Filer' or one that refers to a new section of this read-me on naming.  (helloSystem's Filer doesn't have any documentation on how its name got chosen that I could find and we could parallel, though.)

     Actually, forgot to add one little thing to include here before you merged this; I'll just create a teensy follow-up PR for that.

     OK, that's now done in #7.


create-react-app v2.1.5 fails @svgr/plugin-svgo v4.0.3 dependency not found

Is this a bug report?
Yes, but more of an FYI because the dependency should exist.
To reproduce the problem
Simply run
create-react-app app
The output and error are
yarn add v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred<EMAIL_ADDRESS>Request failed \"404 Not Found\"".

I'm using the latest versions of node, npm, yarn, and create-react-app.  Versions shown below
create-react-app = v2.1.5
node = v10.15.1 (64-bit install)
npm = v6.4.1
yarn = v1.13.0
I'm on a Windows 10 (64-bit).
OS= Win10 under gitbash
uname -a
MINGW64_NT-6.1 SB4706 2.10.0(0.325/5/3) 2018-04-23 03:21 x86_64 Msys
This is not a create-react-app problem as later. I found that the dependent package doesn't exist (for some reason).
======================================================
I ran the following to install the missing dependency.
(1) I went to https://www.npmjs.com/package/@svgr/plugin-svgo, and see the latest version is 4.0.3.
(2) I tried using it
mkdir testitout
cd testitout
npm init -y
npm install --save-dev @svgr/plugin-svgo

which produced this error...
npm ERR! code E404
npm ERR! 404 Not Found: @svgr/plugin-svgo@latest

npm ERR! A complete log of this run can be found in:
npm ERR!     c:\users\user1\...\npm-cache\_logs\2019-02-11T18_57_48_235Z-debug.log

So while there is nothing that the create-react-app can do, the team should be aware of this issue.
NOTE: Because @svgr/plugin-svgo says it latest version is 4.0.3 • Public • Published 3 months ago
It should exist! There must be some problem with the NPM repo that holds this artifact.

Thanks @steranka, it seems that @svgr/plugin-svgo properly installs as of now

I'm experiencing the same issue.
@petetnt  How can I solve it and install?

Same here. Did you do something to solve it?

To @cstenico and @jpaulomotta,
Since I reported it I've had mixed results.  Sometimes it has worked and other times it has not.  I haven't gotten to the bottom of it yet.  I haven't done anything to "fix" it.


How to reactivate after deactivating

As per the title, I deactivated the plugin in the overlay and was unable to re-activate until i deleted '.bak' that was appended to the (IIRC) RT.elf file.

.bak and .elf files shouldn't exist next to each other. It can mean that after you have deactivated it you installed plugin again, thus creating an issue I didn't predicted in code.

.bak and .elf files shouldn't exist next to each other. It can mean that after you have deactivated it you installed plugin again, thus creating an issue I didn't predict in code.

it seems the .bak was appended around the same time i selected '(de)activate). I'm not sure how this happened, but i deleted the appended 'bak' and i was able to 'reactivate' the plugin.
can i ask, what is the intended behaviour after clicking (de)activate? should a re-enable button be present? as there was not for me.
I think the only 'naughty' thing in my setup was the 'latest' (but probably deprecated)  "ReverseNX.elf', which i very recently made sure was deleted.

IIRC the deactivate button dissapeared once deactivated for me, i will try
again soon. can you not 'reactivate' from the overlay?
On Wed, 4 Jan 2023 at 19:18, MasaGratoR @.***> wrote:

Button stays the same. Description above it only changes. That's why it's
"(De)activate"
—
Reply to this email directly, view it on GitHub
https://github.com/masagrator/ReverseNX-RT/issues/2#issuecomment-1371322263,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABMDU426D25DNFHGQZ6ESXTWQXEKFANCNFSM6AAAAAATRADJCY
.
You are receiving this because you authored the thread.Message ID:
@.***>


ApiConnection Class Throws on ListBacktests

The REST response from the API request is:
"{"backtests":[{"backtestId":"..........","name":"2018-02-20 14:08:02Z API Backtest","note":null,"completed":true,"progress":1,"result":" "}],"success":true}"
This empty result value causes an exception in the ApiConnection class TryRequest method:
{"Error converting value " " to type 'QuantConnect.Packets.BacktestResult'. Path 'backtests[0].result', line 1, position 160."}
Listing backtest doesn't return the results (by design) but it should just return the metadata for the backtest without throwing.
Might be an issue from an API change

@Martin-Molinero -- is this resolved by PR #1785 ?

It was actually solved by a fix done by @gaviles in the server. It was at the time I was working in PR #1785


Docs: add a code example for each of our SDK classes (preferably in Go)

Where did you see the issue in our documentation?
https://docs.kurtosis.com/SDK
Issue description
We've gotten feedback that using the SDK is not as friendly as we'd like it to be (see: https://github.com/kurtosis-tech/kurtosis/issues/1152). To make the usage easier for new users to understand, I'd like to propose we add at least 1 code example to each of the SDK classes that we have.

Adding more scope to this original ask: the code examples should be added for every language we support (Go, Typescript, Rust?) & I'd like to see us implement a similar UX to what Stripe has: https://stripe.com/docs/api/balance/balance_retrieve?lang=node where you can change the language:

Related issue opened by @galenmarchetti here: https://github.com/kurtosis-tech/kurtosis/issues/1338

Re-opening as this was not related to #1436


Feature Request: Support For Use Without Browser

Please add support for use outside the browser. I know there is node-jspdf, but it appears to have been abandoned.

Yeah I think this is something we should try tackle for the next big release. We're already moving over to node-land for testing.

@MrRio Have you already spec'd out what has to be adapted for the lib to run smoothly in node? Is there any help required?

+1

this might help: https://github.com/fb55/htmlparser2

@MrRio any update on this or an ETA? thank you

This issue is too common. Our goal is definitely to achieve full support in nodeJS. But this issue doesnt give any problems which have to be solved go achieve the goal