Extra VPC being created

What happened?
We created a composition for creating 2 VPCs and two different region. It always creates one extra VPC for us. For example, below configuration creates 3 VPCs on console but crossplane cr shows only two vpcs. However, in actual it creates 3 vpcs on aws console.

How can we reproduce it?

What environment did it happen in?

Crossplane Version: crossplane-1.13.1
Provider Version: xpkg.upbound.io/upbound/provider-family-aws:v0.46.0
Kubernetes Version:     v1.27.8
Kubernetes Distribution:  baremetal

@prtkdave could you please share the example you mention in the description of the issue.

@jeanduplessis
I am using below example
Use below composition
resources:
- name: cloud-vpc
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
annotations:
meta.upbound.io/example-id: ec2/v1beta1/defaultroutetable
labels:
testing.upbound.io/example-name: example
name: cloud
spec:
forProvider:
cidrBlock: <IP_ADDRESS>/16
region:
tags:
Name: DemoVpc
patches:
- fromFieldPath: spec.network.zone.cloud.region
toFieldPath: spec.forProvider.region
- fromFieldPath: spec.network.zone.cloud.vpc
toFieldPath: spec.forProvider.vpc
- fromFieldPath: spec.network.zone.cloud.vpc
toFieldPath: spec.forProvider.cidrBlock
- fromFieldPath: spec.network.name
toFieldPath: "metadata.name"
transforms:
- type: string
string:
fmt: "%s-cloud-vpc"
- name: onprem-vpc
base:
apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
metadata:
annotations:
meta.upbound.io/example-id: ec2/v1beta1/defaultroutetable
labels:
testing.upbound.io/example-name: example
name: cloud
spec:
forProvider:
cidrBlock: <IP_ADDRESS>/16
region:
tags:
Name: DemoVpc
patches:
- fromFieldPath: spec.network.zone.onprem.region
toFieldPath: spec.forProvider.region
- fromFieldPath: spec.network.zone.onprem.vpc
toFieldPath: spec.forProvider.vpc
- fromFieldPath: spec.network.zone.onprem.vpc
toFieldPath: spec.forProvider.cidrBlock
- fromFieldPath: spec.network.name
toFieldPath: "metadata.name"
transforms:
- type: string
string:
fmt: "%s-onprem-vpc"
*Claim
spec:
compositionSelector:
matchLabels:
provider: aws
network:
name: my test
zone:
cloud:
region: eu-west-1
vpc: <IP_ADDRESS>/20
onprem:
region: eu-west-2
vpc: <IP_ADDRESS>/20

There seems to be something going on with the provider when it cannot fetch resource state from aws api perhaps?
Here are my observations.

When the state of the resource is not updated within the initial timeout ie 2m, Provider is/would be trying to delete the vpc and remove from the state but the delete doesn't seem to happen sometime. I observed another vpc created exactly at that moment.
Guessing delete from step-1 might have triggered a reconcile, which could have cause another create action.
Waiting for state to become: [success]  -  this does not succeed all the time, continues to wait indefinitely if the state is not updated from aws.
Manual delete of the claim does not seem to delete the VPC. I verified if vpcs are deleted by deleting the claim, didnt work.

Below are the logs from provider-aws-ec2 pod.
$> k logs provider-aws-ec2-72d4bc0fae2b-5ffd998494-h6bvh -n crossplane-system --follow
{"level":"info","ts":"2023-12-12T08:29:41Z","logger":"provider-aws","msg":"Beta feature enabled","flag":"EnableBetaManagementPolicies"}
[controller-runtime] log.SetLogger(...) was never called; logs will not be displayed.
Detected at:
        >  goroutine 11666 [running]:
        >  runtime/debug.Stack()
        >       runtime/debug/stack.go:24 +0x65
        >  sigs.k8s.io/controller-runtime/pkg/log.eventuallyFulfillRoot()
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/log/log.go:60 +0xcd
        >  sigs.k8s.io/controller-runtime/pkg/log.(*delegatingLogSink).WithValues(0xc004dec9c0, {0xc0076cc480, 0x4, 0x4})
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/log/deleg.go:168 +0x54
        >  github.com/go-logr/logr.Logger.WithValues(...)
        >       github.com/go-logr/logr@v1.2.4/logr.go:323
        >  sigs.k8s.io/controller-runtime/pkg/builder.(*Builder).doController.func1(0xc00523a560)
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/builder/controller.go:402 +0x2b6
        >  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0035d99a0, {0x12bf7f70, 0xc000124910}, {0xf964d00?, 0xc00523a400?})
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:306 +0x18b
        >  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0035d99a0, {0x12bf7f70, 0xc000124910})
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:266 +0x1d9
        >  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:227 +0x85
        >  created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:223 +0x587
2023/12/12 14:32:38 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:32:38 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:32:39 [DEBUG] Waiting for state to become: [available]
2023/12/12 14:32:39 [DEBUG] Waiting for state to become: [available]
2023/12/12 14:32:39 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:32:39 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:32:40 [TRACE] Waiting 500ms before next try
2023/12/12 14:32:41 [TRACE] Waiting 1s before next try
2023/12/12 14:32:42 [TRACE] Waiting 2s before next try
2023/12/12 14:32:43 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:32:45 [TRACE] Waiting 4s before next try
2023/12/12 14:32:46 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:32:49 [TRACE] Waiting 8s before next try
2023/12/12 14:32:58 [TRACE] Waiting 10s before next try
2023/12/12 14:33:08 [TRACE] Waiting 10s before next try
2023/12/12 14:33:19 [TRACE] Waiting 10s before next try
2023/12/12 14:33:30 [TRACE] Waiting 10s before next try
2023/12/12 14:33:40 [TRACE] Waiting 10s before next try
2023/12/12 14:33:51 [TRACE] Waiting 10s before next try
2023/12/12 14:34:02 [TRACE] Waiting 10s before next try
2023/12/12 14:34:13 [TRACE] Waiting 10s before next try
2023/12/12 14:34:23 [TRACE] Waiting 10s before next try
2023/12/12 14:34:34 [TRACE] Waiting 10s before next try
2023/12/12 14:34:39 [WARN] WaitForState timeout after 2m0s
2023/12/12 14:34:39 [WARN] WaitForState starting 30s refresh grace period
2023/12/12 14:34:41 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:34:42 [DEBUG] Waiting for state to become: [available]
2023/12/12 14:34:42 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:34:44 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:34:46 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:42:48 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:44:44 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:53:00 [DEBUG] Waiting for state to become: [success]
2023/12/12 14:55:04 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:02:48 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:05:34 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:13:02 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:15:51 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:22:51 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:26:13 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:32:47 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:36:43 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:43:16 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:46:44 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:53:34 [DEBUG] Waiting for state to become: [success]
2023/12/12 15:56:23 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:03:14 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:06:46 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:13:48 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:16:30 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:23:30 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:26:21 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:33:41 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:36:35 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:43:57 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:46:24 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:53:54 [DEBUG] Waiting for state to become: [success]
2023/12/12 16:56:26 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:04:17 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:06:18 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:14:30 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:16:29 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:24:52 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:26:36 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:34:44 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:37:01 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:44:52 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:47:30 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:54:45 [DEBUG] Waiting for state to become: [success]
2023/12/12 17:57:54 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:05:02 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:07:43 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:14:58 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:17:20 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:25:23 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:27:18 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:35:34 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:37:40 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:45:54 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:47:15 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:55:44 [DEBUG] Waiting for state to become: [success]
2023/12/12 18:57:34 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:06:03 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:07:44 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:16:33 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:17:43 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:26:20 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:27:37 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:35:56 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:37:14 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:45:57 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:47:48 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:55:57 [DEBUG] Waiting for state to become: [success]
2023/12/12 19:57:54 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:06:26 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:08:22 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:16:24 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:18:43 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:26:09 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:28:36 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:36:17 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:39:05 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:46:41 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:49:12 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:57:06 [DEBUG] Waiting for state to become: [success]
2023/12/12 20:59:25 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:06:51 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:09:23 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:16:41 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:19:25 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:26:47 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:29:32 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:36:34 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:39:38 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:46:56 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:49:41 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:56:47 [DEBUG] Waiting for state to become: [success]
2023/12/12 21:59:39 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:07:19 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:09:40 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:17:02 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:19:59 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:26:59 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:29:46 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:37:27 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:39:31 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:47:13 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:49:30 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:57:11 [DEBUG] Waiting for state to become: [success]
2023/12/12 22:59:38 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:07:01 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:09:48 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:17:30 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:19:54 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:27:53 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:30:15 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:38:08 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:40:39 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:48:33 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:50:16 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:58:52 [DEBUG] Waiting for state to become: [success]
2023/12/12 23:59:56 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:08:47 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:10:20 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:19:04 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:20:36 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:29:29 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:30:29 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:39:16 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:40:08 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:49:22 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:49:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:59:05 [DEBUG] Waiting for state to become: [success]
2023/12/13 00:59:37 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:09:06 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:09:38 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:19:33 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:19:47 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:29:37 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:29:45 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:39:17 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:40:08 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:49:45 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:50:19 [DEBUG] Waiting for state to become: [success]
2023/12/13 01:59:30 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:00:29 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:09:10 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:10:45 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:19:31 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:20:45 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:29:45 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:31:16 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:40:07 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:41:13 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:50:29 [DEBUG] Waiting for state to become: [success]
2023/12/13 02:51:47 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:00:12 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:01:38 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:10:39 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:12:07 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:21:10 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:22:05 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:30:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:32:35 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:40:48 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:42:28 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:50:45 [DEBUG] Waiting for state to become: [success]
2023/12/13 03:52:13 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:01:16 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:02:04 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:11:05 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:12:07 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:21:24 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:22:07 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:31:01 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:32:16 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:41:08 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:42:04 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:51:39 [DEBUG] Waiting for state to become: [success]
2023/12/13 04:51:42 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:32 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:33 [WARN] EC2 VPC vpc-0910f36ab9728b000 not found, removing from state
2023/12/13 05:01:33 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:34 [DEBUG] Waiting for state to become: [available]
2023/12/13 05:01:35 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:37 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:39 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:42 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:43 [WARN] EC2 VPC vpc-03f343c869fe9d75e not found, removing from state
2023/12/13 05:01:43 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:44 [DEBUG] Waiting for state to become: [available]
2023/12/13 05:01:44 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:47 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:01:50 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:11:12 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:11:50 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:21:36 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:21:37 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:31:17 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:31:23 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:40:57 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:41:38 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:51:28 [DEBUG] Waiting for state to become: [success]
2023/12/13 05:52:11 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:01:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:02:13 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:12:06 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:12:12 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:21:41 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:22:19 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:29:37 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:30:38 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:31:09 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:31:41 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:31:49 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:32:14 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:32:25 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:32:26 [DEBUG] Waiting for state to become: [available]
2023/12/13 06:32:26 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:32:28 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:32:30 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:33:28 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:33:30 [INFO] Deleting EC2 VPC: vpc-033ca8928166d255c
2023/12/13 06:33:30 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:33:30 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:41:54 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:42:15 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:51:40 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:52:21 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:13 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:14 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:15 [DEBUG] Waiting for state to become: [available]
2023/12/13 06:55:15 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:15 [DEBUG] Waiting for state to become: [available]
2023/12/13 06:55:16 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:19 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:19 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:21 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:55:22 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:58:08 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:58:10 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:58:12 [INFO] Deleting EC2 VPC: vpc-01e49c1a8b26926e3
2023/12/13 06:58:12 [DEBUG] Waiting for state to become: [success]
2023/12/13 06:58:13 [INFO] Deleting EC2 VPC: vpc-041e377114394d856
2023/12/13 06:58:13 [DEBUG] Waiting for state to become: [success]
{"level":"info","ts":"2023-12-13T06:58:13Z","logger":"provider-aws","msg":"Async delete callback failed","trackerUID":"8e23dbe9-e18b-440e-b42e-05ebc450bd3e","resourceName":"test-shiva-vpc1","error":"cannot update status of the resource ec2.aws.upbound.io/v1beta1, Kind=VPC/test-shiva-vpc1 after an async destroy: Operation cannot be fulfilled on vpcs.ec2.aws.upbound.io \"test-shiva-vpc1\": the object has been modified; please apply your changes to the latest version and try again"}
2023/12/13 07:02:07 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:02:44 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:07:15 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:07:16 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:07:17 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:07:17 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:07:18 [TRACE] Waiting 500ms before next try
2023/12/13 07:07:19 [TRACE] Waiting 1s before next try
2023/12/13 07:07:20 [TRACE] Waiting 2s before next try
2023/12/13 07:07:23 [TRACE] Waiting 4s before next try
2023/12/13 07:07:28 [TRACE] Waiting 8s before next try
2023/12/13 07:07:36 [TRACE] Waiting 10s before next try
2023/12/13 07:07:47 [TRACE] Waiting 10s before next try
2023/12/13 07:07:49 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:07:58 [TRACE] Waiting 10s before next try
2023/12/13 07:08:09 [TRACE] Waiting 10s before next try
2023/12/13 07:08:20 [TRACE] Waiting 10s before next try
2023/12/13 07:08:23 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:08:31 [TRACE] Waiting 10s before next try
2023/12/13 07:08:42 [TRACE] Waiting 10s before next try
2023/12/13 07:08:52 [TRACE] Waiting 10s before next try
2023/12/13 07:08:56 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:09:03 [TRACE] Waiting 10s before next try
2023/12/13 07:09:14 [TRACE] Waiting 10s before next try
2023/12/13 07:09:17 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:09:17 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:10:58 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:10:58 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:10:59 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:10:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:10:59 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:10:59 [TRACE] Waiting 500ms before next try
2023/12/13 07:11:00 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:11:00 [TRACE] Waiting 1s before next try
2023/12/13 07:11:01 [TRACE] Waiting 2s before next try
2023/12/13 07:11:03 [TRACE] Waiting 4s before next try
2023/12/13 07:11:03 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:11:06 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:11:08 [TRACE] Waiting 8s before next try
2023/12/13 07:11:16 [TRACE] Waiting 10s before next try
2023/12/13 07:11:27 [TRACE] Waiting 10s before next try
2023/12/13 07:11:38 [TRACE] Waiting 10s before next try
2023/12/13 07:11:49 [TRACE] Waiting 10s before next try
2023/12/13 07:12:00 [TRACE] Waiting 10s before next try
2023/12/13 07:12:08 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:12:10 [TRACE] Waiting 10s before next try
2023/12/13 07:12:21 [TRACE] Waiting 10s before next try
2023/12/13 07:12:32 [TRACE] Waiting 10s before next try
2023/12/13 07:12:43 [TRACE] Waiting 10s before next try
2023/12/13 07:12:50 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:12:53 [TRACE] Waiting 10s before next try
2023/12/13 07:12:59 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:12:59 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:12:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:13:00 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:13:00 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:13:03 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:13:06 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:20:49 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:21:19 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:21:20 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:21:20 [INFO] Deleting EC2 VPC: vpc-06e246699a27054fc
2023/12/13 07:21:20 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:21:23 [INFO] Deleting EC2 VPC: vpc-045dd7ae435e9f794
2023/12/13 07:21:23 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:22:41 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:23:21 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:23:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:23:59 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:23:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:23:59 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:24:00 [TRACE] Waiting 500ms before next try
2023/12/13 07:24:01 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:24:01 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:24:01 [TRACE] Waiting 1s before next try
2023/12/13 07:24:01 [TRACE] Waiting 500ms before next try
2023/12/13 07:24:02 [TRACE] Waiting 2s before next try
2023/12/13 07:24:02 [TRACE] Waiting 1s before next try
2023/12/13 07:24:04 [TRACE] Waiting 2s before next try
2023/12/13 07:24:05 [TRACE] Waiting 4s before next try
2023/12/13 07:24:07 [TRACE] Waiting 4s before next try
2023/12/13 07:24:10 [TRACE] Waiting 8s before next try
2023/12/13 07:24:12 [TRACE] Waiting 8s before next try
2023/12/13 07:24:18 [TRACE] Waiting 10s before next try
2023/12/13 07:24:21 [TRACE] Waiting 10s before next try
2023/12/13 07:24:29 [TRACE] Waiting 10s before next try
2023/12/13 07:24:31 [TRACE] Waiting 10s before next try
2023/12/13 07:24:40 [TRACE] Waiting 10s before next try
2023/12/13 07:24:42 [TRACE] Waiting 10s before next try
2023/12/13 07:24:50 [TRACE] Waiting 10s before next try
2023/12/13 07:24:53 [TRACE] Waiting 10s before next try
2023/12/13 07:25:01 [TRACE] Waiting 10s before next try
2023/12/13 07:25:04 [TRACE] Waiting 10s before next try
2023/12/13 07:25:12 [TRACE] Waiting 10s before next try
2023/12/13 07:25:15 [TRACE] Waiting 10s before next try
2023/12/13 07:25:22 [TRACE] Waiting 10s before next try
2023/12/13 07:25:26 [TRACE] Waiting 10s before next try
2023/12/13 07:25:33 [TRACE] Waiting 10s before next try
2023/12/13 07:25:37 [TRACE] Waiting 10s before next try
2023/12/13 07:25:44 [TRACE] Waiting 10s before next try
2023/12/13 07:25:47 [TRACE] Waiting 10s before next try
2023/12/13 07:25:54 [TRACE] Waiting 10s before next try
2023/12/13 07:25:58 [TRACE] Waiting 10s before next try
2023/12/13 07:25:59 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:25:59 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:26:01 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:26:01 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:26:01 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:26:02 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:26:02 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:26:02 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:26:03 [TRACE] Waiting 500ms before next try
2023/12/13 07:26:03 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:26:03 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:26:03 [TRACE] Waiting 500ms before next try
2023/12/13 07:26:03 [TRACE] Waiting 1s before next try
2023/12/13 07:26:04 [TRACE] Waiting 1s before next try
2023/12/13 07:26:05 [TRACE] Waiting 2s before next try
2023/12/13 07:26:06 [TRACE] Waiting 2s before next try
2023/12/13 07:26:08 [TRACE] Waiting 4s before next try
2023/12/13 07:26:09 [TRACE] Waiting 4s before next try
2023/12/13 07:26:12 [TRACE] Waiting 8s before next try
2023/12/13 07:26:13 [TRACE] Waiting 8s before next try
2023/12/13 07:26:21 [TRACE] Waiting 10s before next try
2023/12/13 07:26:22 [TRACE] Waiting 10s before next try
2023/12/13 07:26:32 [TRACE] Waiting 10s before next try
2023/12/13 07:26:33 [TRACE] Waiting 10s before next try
2023/12/13 07:26:43 [TRACE] Waiting 10s before next try
2023/12/13 07:26:44 [TRACE] Waiting 10s before next try
2023/12/13 07:26:54 [TRACE] Waiting 10s before next try
2023/12/13 07:26:55 [TRACE] Waiting 10s before next try
2023/12/13 07:27:04 [TRACE] Waiting 10s before next try
2023/12/13 07:27:06 [TRACE] Waiting 10s before next try
2023/12/13 07:27:15 [TRACE] Waiting 10s before next try
2023/12/13 07:27:17 [TRACE] Waiting 10s before next try
2023/12/13 07:27:26 [TRACE] Waiting 10s before next try
2023/12/13 07:27:27 [TRACE] Waiting 10s before next try
2023/12/13 07:27:36 [TRACE] Waiting 10s before next try
2023/12/13 07:27:38 [TRACE] Waiting 10s before next try
2023/12/13 07:27:47 [TRACE] Waiting 10s before next try
2023/12/13 07:27:49 [TRACE] Waiting 10s before next try
2023/12/13 07:27:58 [TRACE] Waiting 10s before next try
2023/12/13 07:28:00 [TRACE] Waiting 10s before next try
2023/12/13 07:28:02 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:28:02 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:28:03 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:28:03 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:28:03 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:28:04 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:28:04 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:28:04 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:28:05 [TRACE] Waiting 500ms before next try
2023/12/13 07:28:05 [DEBUG] Waiting for state to become: [available]
2023/12/13 07:28:05 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:28:06 [TRACE] Waiting 500ms before next try
2023/12/13 07:28:06 [TRACE] Waiting 1s before next try
2023/12/13 07:28:07 [TRACE] Waiting 1s before next try
2023/12/13 07:28:07 [TRACE] Waiting 2s before next try
2023/12/13 07:28:08 [TRACE] Waiting 2s before next try
2023/12/13 07:28:10 [TRACE] Waiting 4s before next try
2023/12/13 07:28:11 [TRACE] Waiting 4s before next try
2023/12/13 07:28:15 [TRACE] Waiting 8s before next try
2023/12/13 07:28:16 [TRACE] Waiting 8s before next try
2023/12/13 07:28:23 [TRACE] Waiting 10s before next try
2023/12/13 07:28:25 [TRACE] Waiting 10s before next try
2023/12/13 07:28:34 [TRACE] Waiting 10s before next try
2023/12/13 07:28:35 [TRACE] Waiting 10s before next try
2023/12/13 07:28:45 [TRACE] Waiting 10s before next try
2023/12/13 07:28:46 [TRACE] Waiting 10s before next try
2023/12/13 07:28:56 [TRACE] Waiting 10s before next try
2023/12/13 07:28:57 [TRACE] Waiting 10s before next try
2023/12/13 07:29:06 [TRACE] Waiting 10s before next try
2023/12/13 07:29:08 [TRACE] Waiting 10s before next try
2023/12/13 07:29:17 [TRACE] Waiting 10s before next try
2023/12/13 07:29:19 [TRACE] Waiting 10s before next try
2023/12/13 07:29:28 [TRACE] Waiting 10s before next try
2023/12/13 07:29:29 [TRACE] Waiting 10s before next try
2023/12/13 07:29:38 [TRACE] Waiting 10s before next try
2023/12/13 07:29:40 [TRACE] Waiting 10s before next try
2023/12/13 07:29:49 [TRACE] Waiting 10s before next try
2023/12/13 07:29:51 [TRACE] Waiting 10s before next try
2023/12/13 07:30:00 [TRACE] Waiting 10s before next try
2023/12/13 07:30:02 [TRACE] Waiting 10s before next try
2023/12/13 07:30:04 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:30:04 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:30:05 [WARN] WaitForState timeout after 2m0s
2023/12/13 07:30:05 [WARN] WaitForState starting 30s refresh grace period
2023/12/13 07:30:05 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:30:07 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:30:40 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:30:40 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:31:14 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:31:18 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:31:48 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:31:52 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:32:23 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:32:26 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:32:48 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:32:57 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:33:00 [DEBUG] Waiting for state to become: [success]
2023/12/13 07:33:13 [DEBUG] Waiting for state to become: [success]

I now have 3VPC spawned and none deleted when the claim is deleted.

Hey folks,
Thank you for your responses and discussions so far, it would be great if you could provide clear reproduction steps with necessary YAMLs so that we can try on our side and see what happens.

@turkenf Here are the steps to reproduce.

Create a kubernetes cluster. [v1.27.3]

Install stable crossplane
helm install crossplane crossplane-stable/crossplane --namespace crossplane-system --create-namespace

Install upbound aws-ec2 provider.

cat <<EOF | kubectl apply -f -
  apiVersion: pkg.crossplane.io/v1
  kind: Provider
  metadata:
    name: provider-aws-ec2
  spec:
    package: xpkg.upbound.io/upbound/provider-aws-ec2:v0.46.0
EOF

Create a kubernetes secret for provider.
kubectl create secret generic aws-secret -n crossplane-system --from-file=creds=<path to your aws-credentials.txt>

Create a Providerconfig.

cat <<EOF | kubectl apply -f -
  apiVersion: aws.upbound.io/v1beta1
  kind: ProviderConfig
  metadata:
    name: default
  spec:
    credentials:
      source: Secret
      secretRef:
        namespace: crossplane-system
        name: aws-secret
        key: creds
EOF

Create a simple Composition for deploying 2 VPCs

cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: test-network
  labels:
    provider: aws
    resource: testnetwork
spec:
  compositeTypeRef:
    apiVersion: shiva.upbound.io/v1alpha1
    kind: TestNetwork
  resources:
    - name: vpc1
      base:
        apiVersion: ec2.aws.upbound.io/v1beta1
        kind: VPC
        metadata:
          annotations:
            meta.upbound.io/example-id: ec2/v1beta1/defaultroutetable
          labels:
            shiva.upbound.io/test-name: test-1
          name: placeholder
        spec:
          forProvider:
            region: us-west-1
            cidrBlock: <IP_ADDRESS>/16
            tags:
              Name: TestVpc1
      patches:
        - fromFieldPath: spec.network.vpc1.region
          toFieldPath: spec.forProvider.region
        - fromFieldPath: spec.network.vpc1.cidrBlock
          toFieldPath: spec.forProvider.cidrBlock
        - fromFieldPath: spec.network.vpc1.name
          toFieldPath: spec.forProvider.tags.Name
        - fromFieldPath: spec.network.vpc1.name
          toFieldPath: "metadata.name"
    - name: vpc2
      base:
        apiVersion: ec2.aws.upbound.io/v1beta1
        kind: VPC
        metadata:
          annotations:
            meta.upbound.io/example-id: ec2/v1beta1/defaultroutetable
          labels:
            shiva.upbound.io/test-name: test-2
          name: placeholder
        spec:
          forProvider:
            region: us-west-1
            cidrBlock: <IP_ADDRESS>/16
            tags:
              Name: TestVpc2
      patches:
        - fromFieldPath: spec.network.vpc2.region
          toFieldPath: spec.forProvider.region
        - fromFieldPath: spec.network.vpc2.cidrBlock
          toFieldPath: spec.forProvider.cidrBlock
        - fromFieldPath: spec.network.vpc2.name
          toFieldPath: spec.forProvider.tags.Name
        - fromFieldPath: spec.network.vpc2.name
          toFieldPath: "metadata.name"
EOF

Create a CompositeResourceDefinition

cat <<EOF | kubectl apply -f -
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: testnetworks.shiva.upbound.io
spec:
  group: shiva.upbound.io
  names:
    kind: TestNetwork
    plural: testnetworks
  claimNames:
    kind: Network
    plural: networks
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              description: TestNetwork creates two VPCs
              properties:
                network:
                  description: Networks to create.
                  type: object
                  properties:
                    vpc1:
                      type: object
                      properties:
                        region:
                          type: string
                        cidrBlock:
                          type: string
                        name:
                          type: string
                    vpc2:
                      type: object
                      properties:
                        region:
                          type: string
                        cidrBlock:
                          type: string
                        name:
                          type: string
EOF

Create a testnetwork

cat <<EOF | kubectl apply -f -
apiVersion: shiva.upbound.io/v1alpha1
kind: TestNetwork
metadata:
  name: shiva-test-claim
spec:
  compositionSelector:
    matchLabels:
      provider: aws
      resource: testnetwork
  network:
    vpc1:
      region: eu-west-1
      cidrBlock: <IP_ADDRESS>/16
      name: test-shiva-vpc1
    vpc2:
      region: eu-west-2
      cidrBlock: <IP_ADDRESS>/16
      name: test-shiva-vpc2
EOF

Check vpcresources are created in k8s
k get vpc.ec2 -w
[Notice that only one of the vpc will have EXTERNAL-NAME assigned whilst the other is still blank and in READY=False/SYNCED=True state]

Check AWS Console. verify creation of two VPC across two Regions.

Tail provider-aws-ec2 pod logs,
k logs <provider-aws-ec2> --follow -n crossplane-system

In the provider logs, after the first timeout ie 2 mins, refresh the aws console (check both the regions). You would see another VPC with the same name created in the region where the vpc(vpc.ec2 in k8s) which had READY=False/SYNCED=True state was created.

Now The vpc(vpc.ec2 in k8s) which was in READY=False/SYNCED=True state, would have obtained EXTERNAL-NAME which points to the vpc-id of the newly created vpc, and transition to READY=True/SYNCED=True state.

Delete the XR (testnetwork)
k delete testnetwork/shiva-test-claim

Refresh the AWS console. and Notice that the vpcs are not deleted.

@shivaprasad201,
Thank you very much for the detailed reproduction steps, the issue can be reproduced:

k get managed

aws console eu-west-1

aws console eu-west-2

@ulucinar I tested with index.docker.io/ulucinar/provider-aws-ec2:v0.46.1-173da7b77ed5eefaa4ef80218ba1973a0419b802 package. Worked perfectly fine. No Timeouts observed in the logs, No duplicate vpcs in both regions.
$> k get provider
NAME                           INSTALLED   HEALTHY   PACKAGE                                                                                AGE
provider-aws-ec2               True        True      index.docker.io/ulucinar/provider-aws-ec2:v0.46.1-173da7b77ed5eefaa4ef80218ba1973a0419b802     3m10s
ulucinar-provider-family-aws   True        True      index.docker.io/ulucinar/provider-family-aws:v1.0.0-e5113e44fc04314cb5b571a15b86e00acd3d28ae   2m55s

$> k get pods -n crossplane-system
NAME                                                         READY   STATUS    RESTARTS   AGE
crossplane-6d7d7d5466-tmr5z                                  1/1     Running   0          4m41s
crossplane-rbac-manager-c6d67f89d-gmkh8                      1/1     Running   0          4m41s
provider-aws-ec2-2450f103556d-74dfdcb887-p8sg8               1/1     Running   0          2m49s
ulucinar-provider-family-aws-0ca418d0679d-545f4d95dc-7qnvq   1/1     Running   0          2m58s

$> k logs provider-aws-ec2-2450f103556d-74dfdcb887-p8sg8 -n crossplane-system
{"level":"info","ts":"2023-12-15T06:15:22Z","logger":"provider-aws","msg":"Beta feature enabled","flag":"EnableBetaManagementPolicies"}
[controller-runtime] log.SetLogger(...) was never called; logs will not be displayed.
Detected at:
        >  goroutine 7800 [running]:
        >  runtime/debug.Stack()
        >       runtime/debug/stack.go:24 +0x5e
        >  sigs.k8s.io/controller-runtime/pkg/log.eventuallyFulfillRoot()
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/log/log.go:60 +0xcd
        >  sigs.k8s.io/controller-runtime/pkg/log.(*delegatingLogSink).WithValues(0xc00d682dc0, {0xc0052bed40, 0x4, 0x4})
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/log/deleg.go:168 +0x49
        >  github.com/go-logr/logr.Logger.WithValues(...)
        >       github.com/go-logr/logr@v1.2.4/logr.go:323
        >  sigs.k8s.io/controller-runtime/pkg/builder.(*Builder).doController.func1(0xc0069e6580)
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/builder/controller.go:402 +0x2ad
        >  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc00d680500, {0x12ca2878, 0xc000bdd810}, {0xf7254a0?, 0xc0069e6560?})
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:306 +0x16a
        >  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc00d680500, {0x12ca2878, 0xc000bdd810})
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:266 +0x1c9
        >  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:227 +0x79
        >  created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2 in goroutine 3808
        >       sigs.k8s.io/controller-runtime@v0.16.3/pkg/internal/controller/controller.go:223 +0x565
2023/12/15 06:16:34 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:34 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:35 [DEBUG] Waiting for state to become: [available]
2023/12/15 06:16:35 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:37 [DEBUG] Waiting for state to become: [available]
2023/12/15 06:16:37 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:40 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:40 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:43 [DEBUG] Waiting for state to become: [success]
2023/12/15 06:16:44 [DEBUG] Waiting for state to become: [success]

$> k get testnetwork
NAME               SYNCED   READY   COMPOSITION    AGE
shiva-test-claim   True     False   test-network   4s

$> k get vpc.ec2 -w
NAME              READY   SYNCED   EXTERNAL-NAME   AGE
test-shiva-vpc1   False   True                     10s
test-shiva-vpc2   False   True                     10s
test-shiva-vpc1   True    True     vpc-0e46572dce2a059b6   23s
test-shiva-vpc2   True    True     vpc-0e2b2eb57a74660d8   23s


Allow admins to configure default guidance to switch DCC off

@xsrust
Would it be possible to give administrators the rights to configure their default guidance?
Some institutions would like DCC guidance to be switched off.

need to add a new section to the org details page to allow admins to disable this and/or select the guidance they want

Ohh, pinging @gjacob24 here as this might be a change to what root_org affects or at least introduce an option to overwrite it for guidance.

👍🏻 Yes, we were just chatting about this yesterday. The 'default org' is defined in our configuration files, but the only thing it is used for is to determine where the default guidance comes from. So, we are going to discuss in the dev call on Monday. It may make sense to remove the concept of the 'default org' and replace it with 'default guidance' (we already have a 'default template').
One though was to add a new 'Settings' page to the Super Admin's menu that will allow them to manage global settings like that.


DB: Create a migration and initial seed for the Topics table

Create a Knex migration for the Topics table. Also, consider adding a seed file for development to add a couple of initial topics.

This task will be handle on issue #63


Multiple aggregates in show view influence each other

Describe the bug
Aggregated fields in show views seem to ignore the where formula. In list views, this feature works fine.
To Reproduce
Steps to reproduce the behavior:

Create show view
Insert aggregate field with "sum" statistics, such that a non-zero result is expected
Copy the aggregate field, enter "false" as in "Where" for the copy
Open the view (selecting a row can be done by appending id=1 to the URL, replace "1" with an id for with the non-zero result is expected).

Expected behavior
Since no rows should be selected when using "false" as a Where formula, the result should be 0 resp. empty, while the other aggregate should show the non-zero result.
Observed (wrong) behavior
Both fields show the same value, sometimes 0/empty sometimes the non-zero value. The behaviour is somewhat random. The same is true when aggregating different fields, so this behaviour is not limited to the use of "Where" clauses.
Tested with Saltcorn version 0.7.4

This was fixed a few weeks ago in https://github.com/saltcorn/saltcorn/commit/e6200f54723e138a9a0a917f5a0972a4651b1be2


CAD of motors' support

CAD of a support, a wooden box, that can be assemble with the slide and that will support the robot by the motors. Holes are cut to indicate where to put the motors.  It will also have premade holes on a false bottom to fix the OpenCR and Raspberry Pi and holes for the wires and plugs.


Matrix strategy for CI tests, allowing to parametrize different tests more easily

Note: completely untested (have not yet figured out how to run the github action locally)

The parameterized part is a good idea. I'm not sure the tests can be made concurrent though. The package repo has to be accessed test one at a time. Otherwise the test will clobber each other.

You are right. I was under the false assumption that the matrix jobs would be executed sequentially.
Any ideas what we could do here? I have not found a way to force the matrix to run the jobs 1 by 1.
What I was contemplating is to tell the ci-tester.js to only purge specific hashes relevant for the respective test, but I fear that will be messy (and not even sure we can do it since the same hash exists across multiple tests)

Yeah, I thought the same things about preserving images/digests between runs, but it would get very complicated (or more work). So I just kept a full purge mode and considering the images are like 1meg ish it's probably okay.

What I like about the matrix approach is the ability to simply set up tests and parametrize them, without repeating the code that then executes them. The piece we're missing is how to isolate the runs from one another (be it by suppressing parallelism somehow, or being able in the code to differentiate which images belong to which test)...
any thoughts how we could achieve that?
I did also contemplate using a run with a do-for loop, but there i coudln't figure out how to run the step 2 (running the workflow itself from within a run)

there is a separation setup already:
    concurrency:
      group: integeration-tests

but that is for the whole workflow. so if multiple workflows are wanting to run across the repo only one will run at a time. Not sure it makes sense to move the concurrency group to job/step level (if that's even possible).

My understanding is that this works either across all jobs in a workflow or per job (depending on where it is defined).
However, within a job that has a matrix setup, the different matrix jobs may still be executed concurrently.
Really no expert here, just what I gathered from reading up on this today. What's your take?
    concurrency:
      group: integeration-tests

it probably would act different depending on where its defined. it may support matrix, not sure though.

Ok, it works now. Would you mind reviewing?
I was able to handle the concurrency with the max-parallel: 1 flag for matrices.
The script could still be improved I feel when it comes to performance.
right now, the npm packages get set up for each test over and over again.
I was not able to figure out how to put the first steps into a cache, and then using that cached environment for each test.
I think that would significantly speed up the process.
Ideas?

There are merge conflicts that will need to be fixed for the merge to succeed.

Also the integration tests don't pass in your repo. This also would have to pass. I haven't reviewed all your changes, but there should be no changes in any of the expected digest files.
Also, I don't think the merge should include any folder name changes. That's extra work for me to review and match up everything. This PR should focus just on the ci.yml. I don't think think those folders should be ordered either. Creates more work to manage.
The concurrency needs to be on the full workflow also. The full suite off jobs should run otherwise other branches etc can be interwoven.
I'm also curious why there isn't an errors in your action, it shouldn't be possible to have all the options specified. Ie. keep-n-tagged and keep-n-untagged. How does that work?
Can you "npm run bundle" on the repo and check in the dist folder. Also squash all your commits again.

Great job though, good job in figuring out that concurrency.

Also the integration tests should probably depend on the general tests. no point running all those tests if the general tests don't pass. That's happen to me many times.

I think the config class skips over null values for keep-n-tagged and keep-n-untagged which explains how it works!!!! That's cool.

There are merge conflicts that will need to be fixed for the merge to succeed. They are minor. Probably best to rebase. I add some additional changes.

Will do

Also the integration tests don't pass in your repo. This also would have to pass. I haven't reviewed all your changes, but there should be no changes in any of the expected digest files.
I changed the expected digest in one case, so that the multi and single have the same conditions (keep 2 untagged; before single kept 2, multi kept 1). Else it's the same.

Also, I don't think the merge should include any folder name changes. This PR should focus just on the ci.yml. I don't think think those folders should be ordered either. Creates more work to manage. - Not 100% against the single prefix addition, but the numbers will create more work.
I found it hard to read the CI.yml and navigate through the folder structure and pick the right prime/expected digest files etc. That's why I ordered them and gave them the same prefix. To me, was super helpful. Hope I can convince you of the prefix ;). As said above, other than for the digest that I changed, the rest stayed the same

The concurrency needs to be on the full workflow also. The full suite off jobs should run otherwise other branches etc can be interwoven.
Will add

I'm also curious why there isn't an errors in your action, it shouldn't be possible to have all the options specified. Ie. keep-n-tagged and keep-n-untagged. How does that work?
You answered it already below :)

Can you "npm run bundle" on the repo and check in the dist folder. Also squash all your commits again.
Sure

Also the integration tests should probably depend on the general tests. no point running all those tests if the general tests don't pass. That's happen to me many times.
Will add

Get the rebase and concurrency group back and the lint/integration tests passing. I think that is important as if there are 2 PR at the same time, there will be problems. Probably just easier to lock the whole workflow. But the matrix is great idea. I can probably live with the folder changes and numbers considering you've done the work.
The dry-run test in your repo likely failed as the arg was passed through somehow.

Here's what I've done:

rebased and merged conflicts.
Added concurrency restriction overall
Update dist (npm run bundle): Done
Make intgration tests dependent on general tests: Done
Dry-run Fail: Fixed (see integration test result below)

Testing status:

Javascript tests: Pass
Lint tests: Pass
Integration tests: Fail

What I think is still needed:

Test 3a is failing (keen n tagged); packages 1.32-1.36 are primed, and then 2 are supposed to be kept. It does keep 2 but not 1.35+13.6 but 1.34+1.36. Is the order by which the script choses which ones to keep correct?

Above I see a message that there are still three conflicts, but I can't figure out what they are / how to resolve them

As written above, the setup of npm (incl. "Install Dependencies & Build Tester Steps") for each test separately is time consuming; if we could create the environment once, cache it, and then use this cache for each test, that would speed things up tremendously

The failures are likely due to the fact you've removed the "deplay" option to the citester. For the keep-n tests order/date it's important and the packages get inserted to fast so the order is messed up (the images are very small so everything happens to quickly in the github side). To work around that I added a 3 second delay between for those kinds of tests. Check the original ci.yml and those tests I pass delay 3000 as an option to the citester. You can add that to your matrix args.

Well spotted, I had overlooked that you had set the delay argument for certain jobs!
Added it and now it works like a charm.
Integration tests: Fail
From my view, ready to merge, unless you have any view on these two points?

Below I see a message that there are still three conflicts, but I can't figure out what they are / how to resolve them
As written above, the setup of npm (incl. "Install Dependencies & Build Tester Steps") for each test separately is time consuming; if we could create the environment once, cache it, and then use this cache for each test, that would speed things up tremendously

I will then look at your feedback on https://github.com/dataaxiom/ghcr-cleanup-action/pull/16 and enhance that

that's great.
the branch has conflicts, so it's not possible to merge GitHub. they need to be resolved first. Also your logs messages need to be fixed, they are multi line log messages, they should just be a single log message.
take a backup of your branch/repo/directory, then
one strategy would be to rebase of main and fix conflicts (git merge --squash main)
regenerate dist (npm run bundle) then create a new commit with the fixes)
then squash in an interactive rebase picking just your commits. (git rebase -i HEAD~n) where n is the first of your commits. change pick to squash for your commits, then in the comment parts remove all the extra log lines.
that should leave you with a single commit change

Thanks for the pointers.
I am a bit lost. Here's where I am  right now

I have synced my main branch with yours
I have taken a backup of my feature branch
I have rebased my feature branch with the main branch and accepted my edits in the merge conflits
I have regenerated the dist

Now I am at the step where I should rebase interactively.
Is my understanding from your instructions correct, and I shall proceed like this?

From this PR I see that my first commit is 7b5d79b

If I git rebase -i 7b5d79b, I get this choice:

pick b13a406 Matrix strategy for CI tests, allowing to parametrize different tests more easily UNTESTED
pick fd3e152 referrer/attestation support (OCIv1 tag approach), rework child packages and delete logic,  more ci tests
pick 3788b1f support testing in repos with uppercase chars
pick 4103212 fix referrers validation
pick b2ada8b add missing images test and fix
pick d59b8ac update description
pick 89e4f87 uppercase repo support fixes
pick 002500e Matrix strategy for CI tests, allowing to parametrize different tests more easily UNTESTED
pick 76299dd Creation of untagged images
pick 97ccf72 Squashed commit of the following:
pick fcbcdaf rebase

My take would be that I remove your commits from this, and squash mine, like this:

pick b13a406 Matrix strategy for CI tests, allowing to parametrize different tests more easily UNTESTED
squash 002500e Matrix strategy for CI tests, allowing to parametrize different tests more easily UNTESTED
squash 76299dd Creation of untagged images
squash 97ccf72 Squashed commit of the following:
squash fcbcdaf rebase

Then in the next screen, I remove the lengthy comments in the commit logs.

Lastly, I git push --force

Many thanks for your pointers.

Almost, you only squash your commits, leave mine as pick.

Ok, just done all of that. but what confuses me is that I see here this message that the branch still has conflicts.
Have no idea what to do...

your branch is still 6 commits behind the main branch, you need to rebase off main first. then resolve the conflicts. then squash.

Ok, maybe I'm not doing the rebasing correctly. Sorry, it's my first time I am really contributing to an open source project. Appreciate your kind patience and guidance.
Here's how I've approached it:

I have synced the main branch of my fork with your repo:

Refreshed in my vscode my main branch

On vscode, in my feature branch, ran git merge --squash main

Resolved all merge conflicts

Did the git rebase -i 7b5d79b and git push -force

Do you see where I'm going wrong?

between step 4 and 5. you'd need to make a new commit after you resolve the conflicts. do a git status to check if the changes then make a new commit (it will get squashed in the last step), but do a "npm run build" after resolving conflicts also.

I have synced the main branch of my fork with your repo
Refreshed in my vscode my main branch
On vscode, in my feature branch, ran git merge --squash main
Resolved all merge conflicts
Ran npm run bundle
Commited changes (but not pushed to git yet)
Did the git rebase -i 7b5d79b (moved all your comits on top, mine below, and picked my first one as "pick", rest as "squash"
Edited the commit message with git commit --amend
Ran git push --force

and still it says there are errors..... I feel i am going in circles

after step 6 do a force push so I can see what is in your branch.

done

did you git fetch before you rebase off main? to pull the main changes down to your local environment?

Here is where I‘m confused:
https://github.com/ManiMatter/ghcr-cleanup-action/compare/matrix-strategy-CI-tests...dataaxiom%3Aghcr-cleanup-action%3Amain
Above shows the 6 commits that my branch is supposedly behind
https://github.com/ManiMatter/ghcr-cleanup-action/commits/matrix-strategy-CI-tests/
Shows that your commits are part of my branch, but with a different commit id.
Do you know why the process we went through resulted in different commit ids?

If that is the case its probably best to recreate the branch.

keep a copy of the repo with your changes aside
clone your repo into a new directory (your main branch is up to date with the upstream repo currently)
create a new branch with exactly the same name as your current PR branch
manually copy across the changes tests, ci-tester.ts and ci.yml files.
do a diff on the ci-tester and ci.yaml file and manually merge back in any changes you might have removed.
create a commit and force push


question : how to enable or disable sentinl  without delete plugins/sentinl ?

question : how to enable or disable sentinl  without delete plugins/sentinl ?
a users need can't see the sentinl table in kibana,the  orther is need .
sentinl 5.x with es 5.x.
thanks.

Sentinl and Kibana version

Issue description

Reproducing the issue step-by-step

Expected results vs. actual results

Sample of data

Additional details

Hi @zqc0512 are you asking for a method to trigger the enable status of a watcher without using the UI?

http://sentinl.readthedocs.io/en/latest/FAQ/#can-i-disable-a-watcher-without-deleting-it


Perform case-sensitive path comparisons on Linux

On Windows and Mac, path comparisons are case-insensitive, as the filesystems are case-insensitive -- .git and .GIT are the same path name, and you can't have two different files or directories with names that only differ in case.
On Linux, filesystems (usually) are case-sensitive -- it is possible to have .git, .GIT and .Git entries in the one directory, all referring to different things. Accordingly, we need to do all path comparisons in a case-sensitive fashion.
This change should be a no-op for Windows and Mac, inasmuch as no different values will result after the change. This change does mean GVFSPlatform.Instance is being relied on in more places, and it's difficult to audit if a given piece of code could be called without GVFSPlatform.Instance already being initialised. (This bit me when working on #1084, where I tried to use GVFSPlatform.Instance in GVFS.FunctionalTests.LockHolder, which silently died with NRE because it wasn't initialised.)
Nonetheless, unit and (Windows) functional tests pass, so it might be fine.
Fixes github#29.
/cc @chrisd8088

/azp run GitHub VFSForGit Mac Functional Tests

I thought I'd give it a try! Looks like maybe I don't have permissions?

I thought I'd give it a try! Looks like maybe I don't have permissions?

It looks like the mac build worked for you. Sorry that you don't have access to the build results themselves. It's unfortunate that we always get those "No pipelines are associated..." messages.

FYI - If you need to support repos that have files whose names only differ by case, you'll also need to update GitIndexProjection.SortedFolderEntries.
It uses LazyUTF8String.CaseInsensitiveCompare and it will need to use a new CaseSensitiveCompare if you need to support repos that allow names that only differ by case.
Please note that this is an extremely hot path, and has been tuned to eliminate as many instructions as possible (it's hit for every entry when parsing the index) and so we'll have to be careful with how this code is updated.
Related, there is a project GVFS.PerfProfiling that can be used to measure the perf of VFS4G's index loading/parsing code which I've found to be helpful when making changes in this area.  Unfortunately it looks like it hasn't been converted to .NET core yet, and so right now it can only be run on Windows.

FYI - If you need to support repos that have files whose names only differ by case, you'll also need to update GitIndexProjection.SortedFolderEntries.
It uses LazyUTF8String.CaseInsensitiveCompare and it will need to use a new CaseSensitiveCompare if you need to support repos that allow names that only differ by case.

Sounds like we will need a new set of functional tests that only run on Linux that check case-sensitive comparisons by explicitly adding files or folders that differ only by case, otherwise, we will never know if we've checked all the things we need to make this switch.

For now we've decided to not support in-tree files whose name only differ by case -- this PR will be scoped only to the operations VFS for Git performs on the filesystem for its own functioning (like locating the .git directory, or matching .keep and .idx files, etc.) -- the repository content will remain case-insensitive.

I think this should be good to go -- @derrickstolee @wilbaker fyi in case you'd like to re-review. I've lessened the scope of the change so nothing that impacts tracked content should be changed now.

Purely as a note for future work (not for this PR, unless someone feels it's important), I have a suspicion there are a few places in the functional test suite where we may want to have a similar OS-specific path comparator instead of StringComparison.OrdinalIgnoreCase().

The paths referred to in those instances are in-tree paths (tracked content), and so are not in the scope of the change proposed in this PR. We'll only change those if we proceed to make VFSForGit support case-sensitivity in the repository contents. Right now we're just behaving appropriately with respect to the backing store.


Constrain transform increment directionally

Hello,
I'm just getting started with libpointmatcher so I apologize if this is already documented somewhere but I could not find a way to do what I want.
I have a set of scans where the orientation is very accurate but the translation has significantly more drift. I would like a way to constrain the ICP to be mostly or only translational. My current problem is that around corners if there is not much overlap, libpointmatcher will perform very large rotations to fit the reading pointcloud. But I know this is wrong and want to limit the rotations. I have attached a figure to illustrate the problem.

Is there any way I can achieve this in the parameters of libpointmatcher? Thank you

Here is my current yaml configuration
readingDataPointsFilters:
  - VoxelGridDataPointsFilter:
      vSizeX: 0.005
      vSizeY: 0.005
      vSizeZ: 0.005
      useCentroid: 1

referenceDataPointsFilters:
  - VoxelGridDataPointsFilter:
      vSizeX: 0.005
      vSizeY: 0.005
      vSizeZ: 0.005
      useCentroid: 1

matcher:
  KDTreeMatcher:
    knn: 3
    maxDist: 0.1

outlierFilters:
  - TrimmedDistOutlierFilter:
      ratio: 0.70

errorMinimizer:
  PointToPointErrorMinimizer

transformationCheckers:
  - CounterTransformationChecker:
      maxIterationCount: 60

inspector:
  VTKFileInspector:
     baseFileName : vissteps
     dumpDataLinks : 1
     dumpReading : 1
     dumpReference : 1

logger:
  FileLogger

There is currently no option to limit the degrees of freedom to be minimized beyond 2D (x, y, yaw) and 4D (x, y, z, yaw).
Looking at your yaml file and your example images, you might want to explore these points:

What is the expected distance between your reference and reading? matcher, maxDist: 0.1 might be too small
TrimmedDistOutlierFilter, ratio: 0.70 means that you expect 70 % inlier, which I doubt. You can explore this parameter too
make sure that you have a reasonable number of points in the overlapping area (hard to tell with the images)

Thank you, how can I limit the minimization to 4D (x, y, z, yaw)?

PointToPlaneErrorMinimizer
Point-to-plane error (or point-to-line in 2D). Per [9].
- force2D (default: 0) - If set to true(1), the minimization will be forced to give a solution in 2D (i.e., on the XY-plane) even with 3D inputs. - min: 0 - max: 1
- force4DOF (default: 0) - If set to true(1), the minimization will optimize only yaw and translation, pitch and roll will follow the prior. - min: 0 - max: 1


Not Functioning Correctly on Partial Updates of Serialized Fields

It seems that changing the value of the serialized field called "options" does not set "changed?" to true. It works correctly when the entire "options" field is modified.
Is this the expected behavior?
Reproduction
Dynamoid: v3.9.0
Ruby: 3.3.0
Sample Test
    context 'serialized field' do
      let(:model) do
        new_class do
          field :options, :serialized
        end
      end

      it 'returns true if serialized field has unsaved changes' do
        obj = model.new(options: {})
        expect(obj.changed?).to eq true

        obj = model.create(options: {})
        obj.options['name'] = 'Alex'
        expect(obj.changed?).to eq true
      end

      it 'returns true if serialized field has unsaved changes other object ' do
        obj = model.new(options: {})
        expect(obj.changed?).to eq true

        obj = model.create(options: {})
        obj.options = {'name' => 'Alex'}
        expect(obj.changed?).to eq true
      end
    end

Thank you for reporting the issue. It's definitely a bug and a similar issue with arrays was reported in #666.


creating an irregular quadmesh from an xarray dataset

I would like to create an irregular quadmesh from an xarray dataset.
Let's start from the cannonical quadmesh example:
n = 20
coords = np.linspace(-1.5, 1.5, n)
X,Y = np.meshgrid(coords, coords);
Qx = np.cos(Y) - np.cos(X)
Qz = np.sin(Y) + np.sin(X)
Z = np.sqrt(X**2 + Y**2)

qmesh = hv.QuadMesh((Qx, Qz, Z))

Now let's say I want to store the data in xarray format. The way I would do so is this:
da = xr.DataArray(Z, dims=['j', 'i'], name='Z',
                  coords={'Qx': (('j', 'i'), Qx),
                          'Qz': (('j', 'i'), Qz)})

giving
<xarray.DataArray 'Z' (j: 20, i: 20)>
array([[2.12132 , 2.012771, 1.911113, ..., 1.911113, 2.012771, 2.12132 ],
       [2.012771, 1.898023, 1.789861, ..., 1.789861, 1.898023, 2.012771],
       [1.911113, 1.789861, 1.674727, ..., 1.674727, 1.789861, 1.911113],
       ...,
       [1.911113, 1.789861, 1.674727, ..., 1.674727, 1.789861, 1.911113],
       [2.012771, 1.898023, 1.789861, ..., 1.789861, 1.898023, 2.012771],
       [2.12132 , 2.012771, 1.911113, ..., 1.911113, 2.012771, 2.12132 ]])
Coordinates:
    Qx       (j, i) float64 0.0 -0.156 -0.3063 -0.4472 -0.5753 -0.6873 ...
    Qz       (j, i) float64 -1.995 -1.971 -1.924 -1.853 -1.761 -1.65 -1.522 ...
Dimensions without coordinates: j, i

The key thing to note is that, in xarray, coordinates and dimensions are different. In this example, there are no dimensions. This works; I can convert to holoviews fine: hv_ds = hv.Dataset(da) gives:
:Dataset   [Qx,Qz]   (Z)

and I can do hv_ds.to(hv.QuadMesh).
But now suppose the xarray DataArray has logical coordiantes i, j defined:
da = xr.DataArray(Z, dims=['j', 'i'], name='Z',
                  coords={'Qx': (('j', 'i'), Qx),
                          'Qz': (('j', 'i'), Qz),
                          'i': ('i', np.arange(20)),
                          'j': ('j', np.arange(20))})

If I convert to holoviews with no options, I get :Dataset   [i,j]   (Z). I need to instead do
hv_ds = hv.Dataset(da, kdims=['Qx', 'Qz'])
hv_ds.to(hv.QuadMesh)

This is all a bit obvious in retrospect, but it took me quite a while to figure it out. I recommend maybe adding something to the docs about how to create QuadMesh from xarray.

Thanks this should definitely be documented, we're going to try to update the reference gallery notebooks and docstrings to explain the supported formats better.
As you mentioned in the past the QuadMesh documentation should also explain the difference between supplying the edges of the mesh by supplying N+1 x M+1 coordinate arrays and supplying the bin centers with N x M coordinate arrays.

Just merged a major overhaul of the Image, QuadMesh, RGB and HSV element documentation and the gridded data user guide.


Add test for scenario where 1build file is not present and add pyc files to gitignore

@Ritabrata-TW Thank you for the PR.
Next time onward please reference issue in your commit message.
example
git commit -m "Release 1.0.0
Issue: #75
"

@gopinath-langote - Noted and will do. Thanks.


Add a feature to Navigation

After we navigate to a particular page, It will be more user-friendly by showing the directed page name in different color(green) in the navigation bar.
(eg:- After we directed to the Home page, we can show Home in navigation bar in a different color(like green). So it will be more user friendly :) )

Hi, Can I work on this issue?

i want to work on this issues please assign me this issue @Ravindu-Hirimuthugoda


Include some info on innocuous "ERROR" messages in log (or suppress them)

Specifically this is about the dd exit status in the block size estimation function, and the final mt status at the end of the tape (both of these might alarm users).

For now dd/mt logging output is suppressed for block size estimation: https://github.com/bitsgalore/tapeimgr/commit/b70b614b0d158173ec4cde674ede3d884239bb24


Profile editor

Experimental version of the mapper with integrated server profile editor.
Fixes Issue #58

This needs a little more debugging.


SwiftMoment as Swift package

Added configuration to allow the use of SwiftMoment as a Swift package.
Description
Pretty straight forward job.
Motivation and Context
I have a need to use SwiftMoment in a Vapor app.
How Has This Been Tested?
It can be used as a dependency:
// swift-tools-version:4.0
import PackageDescription

let package = Package(
    name: "MyApp",
    dependencies: [
        // 💧 A server-side Swift web framework.
        .package(url: "https://github.com/vapor/vapor.git", from: "3.0.0"),

        // 🍃 An expressive, performant, and extensible templating language built for Swift.
        .package(url: "https://github.com/vapor/leaf.git", from: "3.0.0"),

        // 🖋 Swift ORM framework (queries, models, and relations)
        .package(url: "https://github.com/vapor/fluent-postgresql.git", from: "1.0.0"),

        // SwiftMoment - A time and calendar manipulation library
        .package(url: "https://github.com/pardel/SwiftMoment.git", from: "0.7.1"),
    ],
    targets: [
        .target(name: "App", dependencies: ["Leaf", "FluentPostgreSQL", "Vapor", "SwiftMoment"]),
        .target(name: "Run", dependencies: ["App"]),
        .testTarget(name: "AppTests", dependencies: ["App"])
    ]
)

Possible problem
The Swift Package manager doesn't like the v.X.X.X format for versioning but prefers X.X.X so a tag without the v will need to be also created. eg: https://github.com/pardel/SwiftMoment/releases

This is awesome, thanks a lot Paul! Merged


feat: test dependencies updated and including archunit

checked with alda sorting solution, not sure if there are additional/better projects to validate these version bumps?

Do not forget to update the pom version, otherwise you cannot make a new release.

Do not forget to update the pom version, otherwise you cannot make a new release.

thanks, fine, i'll do the mvn versions:set -DnewVersion=1.5 myself :p


Google indexing don't follow their own documentation

despite their documentation Google do index pages that arent listed in the sitemap as is clear from the link below.

@MattBlissett i still think we should remove it from search. Let me know if you can think of an easy client way to do so. I guess removing search from indexing is one option, but I'd rather not. Is filtering the API very time consuming?

Try http://api.gbif-dev.org/v1/organization?isEndorsed=true

Reopening, since changes to the portal will still be needed.

this is done


Generate transaction receipts for reverted transactions

This PR adds an integration test that demonstrates missing transaction receipts when transactions are reverted as described in #178. It also makes an attempt to solve that issue, by delaying the error handling in pallet_ethereum's transact until after the Pending storage item has been written.
I do have some open questions about this work:

Why there no status in the transaction receipts (whether it is reverted or not)
Why is the gas used different when the transaction reverts vs when it doesn't
Is it acceptable to write to runtime storage (Pending) even when the transaction is going to fail? It seems like the correct thing in this case, but it is contrary to "normal" best practices "verify first, then write".

@JoshOrndorff Can you pull master? It should fix the DispatchError issue, and the tests you added are really useful.

Okay, so the desired behaviour is that calls to transact should succeed even if the evm execution fails? That fine, but a bit unintuitive.
So I'll revert my changes to the rust code, merge master, and keep this PR open for the tests.


More weather update to be added and new UI to be designed - (Frontend and UI for interface design and Backend for data fetching)

Implemented in the last release


Update .travis.yml

Fixes tags not running when having more than a digit

[Current coverage][cc-pull] is 91.88%

Merging [#1967][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master      #1967   diff @@
==========================================
  Files            91         91
  Lines          6405       6405
  Methods        1094       1094
  Messages          0          0
  Branches       1344       1344
==========================================
  Hits           5885       5885
  Misses          520        520
  Partials          0          0

Powered by Codecov. Last updated by [c6c9c97...612fd22][cc-compare]
[cc-base-branch]: https://codecov.io/gh/ParsePlatform/parse-server/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/ParsePlatform/parse-server/compare/c6c9c97b54f945d392e03ff6866c52f7e1a2c1d3...612fd226f37d0116930134ef8adf0501c4f894c2
[cc-pull]: https://codecov.io/gh/ParsePlatform/parse-server/pull/1967?src=pr


Sidebar visibility

Hello everyone, i have a problem with sidebar, when i push to the parent route link of a current child (through click on a logout button), sidebar is still appear, but the parent component don't have sidebar. Did this happen to anyone?

OS: win 10
Node.js version: 12.14.1
Vuesax version: 3.11.13
Browser version: Chrome 80.0.3987.122 x64
package manager: npm

I did solved this by changing parent id in component attributes


Index at github.com-1ecc6299db9ec823 isn't updated

Problem
When updating the index, only index.crates.io-6f17d22bba15001f index is updated, but not github.com-1ecc6299db9ec823.
Steps

Run any command that should update the index (e.g. cargo update --dry-run )
Check that index.crates.io-6f17d22bba15001f index is updated
Check that github.com-1ecc6299db9ec823 index isn't updated

Possible Solution(s)
No response
Notes
No response
Version
cargo 1.70.0 (ec8a8a0ca 2023-04-25)
release: 1.70.0
commit-hash: ec8a8a0cabb0e0cadef58902470f6c7ee7868bdc
commit-date: 2023-04-25
host: x86_64-pc-windows-msvc
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Home Single Language) [64-bit]

This is expected and exactly the purpose sparse registry index was designed for — skipping the update of Git-based registry index. Cargo updates only the registry index for the default protocol of your choice. By default it is the sparse protocol since 1.68.
Is there any issue you encountered with this behavior?

@weihanglo thank you for your answer
As discussed in https://github.com/rust-lang/cargo/issues/3377, this index is used in various tools (intellij-rust in my case) to gather information about the crates. I've noticed that the github index stopped updating, and it was causing problems for us, for example https://github.com/intellij-rust/intellij-rust/issues/10644
I'll try setting the github index as default one, thank you!

I am not sure what it wasn't reported earlier, since sparse registry was in beta for a long while, and got stabilized in March this year. For intellij-rust perhaps some bugs were introduced in recent.
Anyway, here is a workaround to forced update the Git-based registry index: CARGO_REGISTRIES_CRATES_IO_PROTOCOL=git cargo fetch
Closing in favor of other prior issues:

#3377
#10928
#11034

Thank you for the report!


Multiple log widgets displaying different log targets.

Firstly, Thank you for producing this crate.  I have thus far found it excellent.
What I'd like to do is have 2 separate log widgets, both displaying different log data dependent on the log target. I'm pretty sure I know the answer is that it's just not possible, but I was wondering if you could shed some insight as to what I might need to do to achieve that goal.
I basically want  log::info!(target: "x", "This is log X"); and log::info!(target: "y", "This is log Y");  to show up in different log panes (widgets).
 ---Logs 1-----------------------Logs 2-----------------------
| This is log X              | This is log Y                  |
|                            |                                |
 -------------------------------------------------------------

:point_up: A bit like that; stylistic hell I know :smiley:

Thanks @gin66 , I did try that just for one, but had a terrible time trying to get it to work, to the point I gave up thinking it was meant to be an internal representation.  I can't remember what my trouble was, but I'll try again and report back.

OK, So this is what I have:
    {
        let lws = TuiWidgetState::new().set_level_for_target("task_log", log::LevelFilter::Debug);
        // let mut tui_lw: TuiLoggerWidget = TuiLoggerWidget::default();
        // let tui_lw = tui_lw.state(&lws);
        let widget = TuiLoggerWidget::default()
            .block(
                Block::default()
                    .title(" Logs ")
                    .border_style(Style::default().fg(Color::White).bg(Color::Black))
                    .borders(Borders::ALL),
            )
            .style_error(Style::default().fg(Color::Red))
            .style_debug(Style::default().fg(Color::Green))
            .style_warn(Style::default().fg(Color::Yellow))
            .style_trace(Style::default().fg(Color::Magenta))
            .style_info(Style::default().fg(Color::Cyan))
            .output_separator('|')
            // .output_timestamp(Some("%F %H:%M:%S%.3f".to_string()))
            .output_level(Some(TuiLoggerLevelOutput::Abbreviated))
            .output_target(false)
            .output_file(false)
            .output_line(false)
            .style(Style::default().fg(Color::White).bg(Color::Black))
            .state(&lws);

        f.render_widget(widget, logs_events[0]);
    }

and this is what I get in response.
error[E0277]: the trait bound `&mut TuiLoggerWidget<'_>: Widget` is not satisfied
   --> cli/src/ui/terminal.rs:129:25
    |
129 |         f.render_widget(widget, logs_events[0]);
    |           ------------- ^^^^^^ the trait `Widget` is not implemented for `&mut TuiLoggerWidget<'_>`
    |           |
    |           required by a bound introduced by this call
    |
    = help: the trait `Widget` is implemented for `TuiLoggerWidget<'b>`
note: required by a bound in `Frame::<'a, B>::render_widget`
   --> .../.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.19.0/src/terminal.rs:99:12
    |
99  |         W: Widget,
    |            ^^^^^^ required by this bound in `Frame::<'a, B>::render_widget`

I've tried getting to the widget like so
f.render_widget(*widget, logs_events[0]);

but that gives me
129 |         f.render_widget(*widget, logs_events[0]);
    |                         ^^^^^^^ move occurs because `*widget` has type `TuiLoggerWidget<'_>`, which does not implement the `Copy` trait

and I've tried a few other things.  none of which have rewarded me 😢
It's probably a very simple thing I'm missing, but it just escapes me at present.
Appreciate the help.

You are a super ⭐
Thank you very much.

Sorry @gin66 , I'm back.  Although I can now use the state method, I think it's being ignored.
My widgets have the following states:
        let lws = TuiWidgetState::new()
            .set_level_for_target("task_log", log::LevelFilter::Debug)
            .set_default_display_level(log::LevelFilter::Off);

and
        let ews = TuiWidgetState::new()
            .set_level_for_target("event_log", log::LevelFilter::Debug)
            .set_default_display_level(log::LevelFilter::Off);

which is added appropriately to each widget.
However, regardless of what I do, the output is identical in both of them, and is governed more by init_logger(LevelFilter::Info)?; than anything I do to the WidgetState.
Any idea's what I might be doing wrong?

Perhaps a typo (lws/ews) in the .state() calls ?
I have extended the demo to demonstrate how/that it works.

This patch will do it.
diff --git a/src/lib.rs b/src/lib.rs
index c99be58..23e558b 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -1054,6 +1054,8 @@ impl<'b> Widget for TuiLoggerWidget<'b> {
                     if *level < evt.level {
                         continue;
                     }
+                } else {
+                    continue;
                 }
                 if state.focus_selected {

hmmm. I think, that patch will ensure, that the widget does not display anything.

I've observed it to work.  The statement in question is
                if let Some(level) = state.config.get(&evt.target) {
                    if *level < evt.level {
                        continue;
                    }
                }

and becomes
                if let Some(level) = state.config.get(&evt.target) {
                    if *level < evt.level {
                        continue;
                    }
                } else {
                    continue;
                }

that first if is checking if there is a level set for the target, and if there is, and the level is set lower than the events level, it ignores it.  It doesn't account for it not being set at all.
Now that I've typed that, and re-read your comment, I think it will behave badly for the case where the state is not explicitly set, and there is no target?

The answer to that is a catagorical yes. It ignores all the logs.... Thinking...

This one works better.
diff --git a/src/lib.rs b/src/lib.rs
index c99be58..8b4726a 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -1054,6 +1054,15 @@ impl<'b> Widget for TuiLoggerWidget<'b> {
                     if *level < evt.level {
                         continue;
                     }
+                } else {
+                    match state.config.default_display_level {
+                        Some(level) => {
+                            if level < evt.level {
+                                continue;
+                            }
+                        }
+                        None => (),
+                    }
                 }
                 if state.focus_selected {
                     if let Some(target) = state.opt_selected_target.as_ref() {

Thanks for the patch. I have applied it to v0.8.3


Easy context switching in Docker Desktop

Tell us about your request
I would like to see an easy docker context switching menu in Docker Desktop. Basically the same as there is for Kubernetes for switching kubeconf contexts. I do not expect it to be GUI for managing contexts (create/update/rm), just switch.
Which service(s) is this request for?
Docker Desktop (all platforms)
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Switching context is possible by docker context use mycontext which is not much, but why couldn't we have it in two clicks in parity with the Kubernetes menu item?
Are you currently working around the issue?
n/a
Additional context
none

Well, I was aiming on something that needs minimal effort, but would make life a tiny bit easier. Regarding a UI that makes possible to manage contexts (if you meant that), that would be a great addition, especially for less experienced users.
For the icon to indicate current context, honestly I don’t know. If someone has multiple contexts, how could that appear on the tiny icon? However, and I had issues with that in my own experience, if just indicating if I’m on local or a remote context would be possible, that could really help. I took me a couple of minutes and commands to realize that why I don’t get the results I was expecting was because I was on a remote context.

Hi @iben12 .  I'm currently working on the user experience of the context switching issue you brought up and would really like to get a better sense of how you are currently using contexts and how often you're switching. Any insight you could give would be helpful. For example, how many remote contexts do you usually work with?  Are there any ways switching could be improved?  You mentioned having a clearer marker into which context you're in to avoid confusion. What specific tasks are you usually attempting to complete when context switching? Thanks again for raising this!

Hi @stlucek,
At the moment I use two contexts: the local (default) and one remote for my swarm cluster. I switch between them on a daily basis. Of course mostly I work with the local context, but every now and then I need to change stuff in the swarm (deploy, update, restart services, stacks etc).
I have an alias set up in my .zshrc so I use dctx <context> to switch between them.
However I have another addition: sometimes I forget on what context I am on and do not understand why something (eg mounts, port mappings) do not work. When I use a docker command on a remote context, it would be really nice if the first line of the output would be something like:
Notice: You're using a remote Docker context, your command is executed on a remote server.
Above was kind of an idea that the Moby icon on the taskbar/panel could indicate the context: at least it could somehow indicate whether local or remote. That could be achieved, I guess.
Just ping me if I can help any further.

I'm going to add docker/for-mac#5512 into this request: if you could switch contexts in Docker Desktop, we would also need the dashboard to switch to reflect the current context (or show both, or something).

I don't have any containers on my workstation, everything is remote. It would be nice to have Docker Workstation to be able to talk to remote docker instances using context's.

I put this thing together (it was a bit of a learning go project) that at least serves as a visualizer for windows: https://github.com/sthomen/godockercontext It just observes the config.json file and updates a simple colored systray icon. It may work on mac and linux as well, but I haven't tested that. Perhaps it's useful to some you guys.
Feel free to delete this comment if it is inappropriate here.

Hello. I really think this is a good ideea - but until then, @iben12 , you mentioned that docker context switch works with the cli - which is true - but does the change currently reflect intor Docler Desktop? I am able to do all the work using the cli, but the Desktop seems to show only one context, no matter what. Any ideas please?

I've found the same behavior: docker desktop only uses the desktop-linux context

Yes I have observed same. By default docker desktop is using  desktop-linux context. But in the linux when we pull docker image from docker hub its pulled in default context. So when I open docker desktop it shows nothing.

I just ran into this issue on Ubuntu 22.04. I want to use an nvidia gpu in my container, but the nvidia container toolkit expects to work with the default context, so for gpu enabled containers I need to use that, and the containers/images are not visible in the docker desktop gui.
I suspect the situation is not straightforward based on this doc page, but wondering if it's currently possible to update some config of Docker Desktop to make it use a context different from desktop-linux

Same thing I was wondering, Im on mac.

any updates on this one?

And how to use docker context that connects with ssh to another machine? And what if I want to manage docker engine on some different servers? Docker desktop is just unusable thing now(


Attribute snippet

Summary of the changes

The overwrite section of this won't work broadly until the relevant VS commits are fully merged. I've tested some builds of it t though and it did work.
Start returning snippets like <attribute>="$0" for TagHelper/Component Attribute completion.
We also need HTML LSP to react this for a consistent experience.

Fixes part of https://github.com/dotnet/razor-tooling/issues/4436.

I've updated based on @NTaylorMullen's feedback, but I'm not able to double-check my work until a current issue in VSMain is resolved.

Tested on latest VSMain, working well. Waiting for reaction from HTML.


YAML to Python transpiler

It would be awesome to be able to convert YAML into Python.
@terrytangyuan

This could be interesting but I am not sure what use cases there are (Python to YAML is useful but probably not the other way around). Do you have anything in mind?

The goal is to help users get started using Python, by having some Python (I.e Couler) examples.
In Argo Dataflow, all YAML examples are writing in Python and the build script runs the transpiler to create the YAML examples.
So maybe a better way of achieving the goal would be to add versions of common examples in Python.
@terrytangyuan would you be interested in helping doing this?

Are you suggesting that we add Python examples in this repo? Here are some things to consider:

Currently there's still feature parity between Couler and Argo Workflows. Some features are not available in Couler yet so there isn't straightforward 1-to-1 mapping between YAML and Python examples.
Writing a transpiler may not be trivial when the example gets more complicated.
Couler is still under active development. If the Python examples are located in this repo, they may get outdated very easily.

Instead, perhaps for now we can add a link to Couler's examples in the Argo Workflows' docs and then leave the actual examples in Couler's repo to avoid duplicate maintenance efforts?

I think links would be fine. Perhaps we could add the link in the description annotation?

Sounds good. I'll add some links to the annotations.


Sister chromatid cohesion  GO:0007062 (and children) parentage issue

Sister chromatid cohesion  GO:0007062 should not be part_of sister chromatid segregation/chromosome segregation.
The reason for this is:
i) chromosome segregation should be defined as taking place in M-phase, and cohesion is established during replication.
ii) cohesion has other roles in addition to  being cleaved during chromosome segregation  (I.e it is also required for DNA repair)
I would say that cohesion is required/cusally  upstream of chromosome segregation but is not part_of it
Of course  the cohesion (rec7 subunit) is cleaved at mitosis,   but this doesn't make  the process of cohesion part_of chromosome segregation.

@pgaudet  @colinlog  could you review this.
Context:
I would like to define the starts and ends of chromosome segregation

This was definitely incorrect.
I removed the related synonym  "sister chromatid alignment" because it is confusing, alignment happens in metaphase. I moved the parentage up to "cell cycle process"
-synonym: "sister chromatid alignment" RELATED []
is_a: GO:0022402 ! cell cycle process
is_a: GO:0051276 ! chromosome organization
-relationship: part_of GO:0000819 ! sister chromatid segregation

done in
https://github.com/geneontology/go-ontology/pull/24392

I  mustn't have removed the relations from the children
GO:0007064   mitotic sister chromatid cohesion
is still under mitotic chromosome segregation
and
meiotic sister chromatid cohesion (GO:0051177)
under
meiotic sister chromatid segregation

also
mitotic sister chromatid cohesion (GO:0007064)
is still part of
mitotic sister chromatid segregation


Set up continuous integration

Travis CI?

I set the project up on Travis CI, but currently the build is still failing.

Simply piping xcodebuild through xcpretty seems to have fixed it. I have no idea why.

It's not working yet.

It's now working, without me changing anything – I simply restarted the build on Travis.


Put further Item Informations behind clickable Icons

In order to keep the tables themselves small, you could hide further information about items behind clickable icons.
This would include.
Lore: https://github.com/wolf128058/mc-dealer-yml2json/issues/24
Shulker and Bundles: https://github.com/wolf128058/mc-dealer-yml2json/issues/23
Enchantments https://github.com/wolf128058/mc-dealer-yml2json/issues/3
and Datapack Item Infos like Simple Drawer Types

+1


The L20 graphics card is extremely slow

The L20 graphics card is extremely slow

This generation speed is within our expected range, since the autoregressive models require frame-by-frame generation.

But no GPU memory is actually used

But no GPU memory is actually used

Could you run watch -n 1 nvidia-smi and check which stage does not use GPU memory: DiT generation or later VAE decoding?

It's always zero

video_generation_demo works fine


IMPROVE: LogToConsole

Add some more options to LogToConsole. (without any breaking as boolean is still a thing)

[x] option: OneLiner that is adding everything in one line (my fav)
[x] option:  function that let you customize everything
[x] tests added
[x] doc added

I Live it!!!


Update CosmWasm std dependency version to 1.2.x？

Hi，
The cosmwasm-std latest version is 1.2.6， are you going to update the dependency to this？
I noticed the sei-cosmwam latest release version before four months ago.
Thanks！

After I updated the sei-cosmwasm dependencies to latest, cargo test is ok

The version of cosmwasm-std used is 1.1. There are some incompatibilities with 1.2.6 but we are planning to upgrade to later versions of cosmwasm-std soon.

There hasn't been any updates on this issue. If there are still issues here / concerns, please just re open another issue. Closing this.


Please check peer dependency validity

Current peer dependency from package.json:
"peerDependencies": {
    "electron": "^1.4.15"
  },

Please check this, I think higher versions of electron are good too.

You're right, they should work fine. I switched the peer dependency to ">= 1.4.15" and published version 2.0.1 with the fix.


Modal Aren't Really Place In Front because Icon still can be seen in Home Component

Hi, this issue has been fixed and will be available on v0.2.1 of Todo Application.