Stuck with infinite loop of "waiting on cluster sync" and "abnormal time between runs"

Description
Observed Behavior:
Our karpenter pod suddenly stopped provisioning any nodes and the only log shows it's stuck in the infinite loop. After I restart the pod, it would start processing for some time and enter the infinite loop again.
{"level":"DEBUG","time":"2024-08-04T19:32:56.983Z","logger":"controller","message":"waiting on cluster sync","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:56.983Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 42h11m58.850461658s","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:57.983Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 42h11m59.850931899s","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:58.092Z","logger":"controller","message":"waiting on cluster sync","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:58.092Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 42h11m59.959476145s","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:59.092Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 42h12m0.960108358s","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:59.160Z","logger":"controller","message":"waiting on cluster sync","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T19:32:59.160Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 42h12m1.027746864s","commit":"490ef94","controller":"disruption"}

Any ideas about the potential cause?
Expected Behavior:
Reproduction Steps (Please include YAML):
Versions:

Chart Version: 0.37.0
Kubernetes Version (kubectl version): 1.29

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

After restart, I found these logs. Seems like caused by insufficient capacity.
But the behavior is different compared to the one I described as above. This time Karpenter succeeded provisioning new nodes and deprovisioning expired nodes.
I want to figure out why Karpenter suddenly fell into the previous dead loop.
{"level":"ERROR","time":"2024-08-04T21:21:43.151Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-7qmtr"},"namespace":"","name":"compute-ssd-spot-7qmtr","reconcileID":"d0ad9b1b-8477-40cb-8149-f85e28bd091d","error":"creating instance, insufficient capacity, with fleet error(s), InsufficientInstanceCapacity: There is no Spot capacity available that matches your request."}
{"level":"ERROR","time":"2024-08-04T21:21:43.151Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-rfck6"},"namespace":"","name":"compute-ssd-spot-rfck6","reconcileID":"c2a4d78a-037e-4802-bf0e-60dd95659cee","error":"creating instance, insufficient capacity, with fleet error(s), InsufficientInstanceCapacity: There is no Spot capacity available that matches your request."}
{"level":"ERROR","time":"2024-08-04T21:21:43.151Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-l4jkb"},"namespace":"","name":"compute-ssd-spot-l4jkb","reconcileID":"65ee3024-3d1e-44f4-9b81-572c4ef26ee2","error":"creating instance, insufficient capacity, with fleet error(s), InsufficientInstanceCapacity: There is no Spot capacity available that matches your request."}
{"level":"ERROR","time":"2024-08-04T21:21:43.151Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-mjs9j"},"namespace":"","name":"compute-ssd-spot-mjs9j","reconcileID":"3339a2f4-7089-4c93-acd1-206fde92c86a","error":"creating instance, insufficient capacity, with fleet error(s), InsufficientInstanceCapacity: There is no Spot capacity available that matches your request."}
{"level":"ERROR","time":"2024-08-04T21:21:43.151Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-zxjfd"},"namespace":"","name":"compute-ssd-spot-zxjfd","reconcileID":"16f81bb0-128f-45be-adf5-8e6a3c7b8570","error":"creating instance, insufficient capacity, with fleet error(s), InsufficientInstanceCapacity: There is no Spot capacity available that matches your request."}
{"level":"ERROR","time":"2024-08-04T21:21:43.160Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-c6nbw"},"namespace":"","name":"compute-ssd-spot-c6nbw","reconcileID":"4032f247-f473-4296-81d8-53865fc26320","error":"creating instance, insufficient capacity, with fleet error(s), InsufficientInstanceCapacity: There is no Spot capacity available that matches your request."}
{"level":"ERROR","time":"2024-08-04T21:21:43.169Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-rm2kt"},"namespace":"","name":"gpu-g5-4-rm2kt","reconcileID":"90f7451b-848f-4516-a5f0-c57ad86cbbb6","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.175Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-vfl4h"},"namespace":"","name":"gpu-g5-4-vfl4h","reconcileID":"99299752-aa51-4f80-8951-b915547ed0ee","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.185Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-nxhdf"},"namespace":"","name":"gpu-g5-4-nxhdf","reconcileID":"c958bb0a-7995-4191-a687-60da38691fbe","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.187Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-pv2pn"},"namespace":"","name":"gpu-g5-4-pv2pn","reconcileID":"3a9fb7fc-dc17-4b91-91ad-a533ef3bd3cc","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.196Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-kpxk7"},"namespace":"","name":"gpu-g5-4-kpxk7","reconcileID":"467c9a9a-8d03-428a-9001-7cd21c7a4661","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.203Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-5rnc5"},"namespace":"","name":"gpu-g5-4-5rnc5","reconcileID":"2ec00154-bc8f-4a7d-979f-0b0ba4f66c72","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.210Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-6rz6p"},"namespace":"","name":"gpu-g5-4-6rz6p","reconcileID":"6c206bbd-32bb-40cd-a595-4fbb484b13d2","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.215Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-25rcv"},"namespace":"","name":"gpu-g5-4-25rcv","reconcileID":"820078be-2139-4e14-a8bd-6e6c2c2cc7d0","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.219Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-96z2n"},"namespace":"","name":"gpu-g5-4-96z2n","reconcileID":"ca2f0e46-f5fa-4481-aaac-ae404471fa93","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.231Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-89d76"},"namespace":"","name":"gpu-g5-4-89d76","reconcileID":"4b0ab617-c4c8-438c-bd77-64b613af0fb2","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.232Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-tlx78"},"namespace":"","name":"gpu-g5-4-tlx78","reconcileID":"c419c369-6780-4e8d-ae81-c6f6cadedc99","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.240Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-6xq8g"},"namespace":"","name":"gpu-g5-4-6xq8g","reconcileID":"93131b1e-34b7-40a1-826d-fa3adf9c3dff","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.259Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-k7gd4"},"namespace":"","name":"gpu-g5-4-k7gd4","reconcileID":"194deee4-af49-4d7f-abe9-ac256c2c642e","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.261Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-b22sr"},"namespace":"","name":"gpu-g5-4-b22sr","reconcileID":"bc62fe34-1805-4362-8d6c-1b23b59f1a0e","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.266Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-h48h8"},"namespace":"","name":"gpu-g5-4-h48h8","reconcileID":"d31b26f9-895c-49b8-a231-650ba2cb9483","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.268Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-hgfg5"},"namespace":"","name":"gpu-g5-4-hgfg5","reconcileID":"6d6caf36-8707-4e67-b46b-e8e3a6430dd6","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.276Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-xjcqb"},"namespace":"","name":"gpu-g5-4-xjcqb","reconcileID":"c609358f-7554-40bd-b6ee-771fda2bec79","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.276Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-zzz78"},"namespace":"","name":"gpu-g5-4-zzz78","reconcileID":"7c8c2e22-fbf4-421d-b5f8-34b6c4c284fb","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"ERROR","time":"2024-08-04T21:21:43.290Z","logger":"controller","message":"failed launching nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"gpu-g5-4-6gdrl"},"namespace":"","name":"gpu-g5-4-6gdrl","reconcileID":"181ea2d0-632f-4372-af9c-b41664093c84","error":"insufficient capacity, all requested instance types were unavailable during launch"}
{"level":"DEBUG","time":"2024-08-04T21:21:43.340Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 35m57.380924625s","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T21:21:43.417Z","logger":"controller","message":"waiting on cluster sync","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T21:21:43.417Z","logger":"controller","message":"abnormal time between runs of *disruption.Expiration = 35m57.457949023s","commit":"490ef94","controller":"disruption"}
{"level":"DEBUG","time":"2024-08-04T21:21:43.849Z","logger":"controller","message":"removing offering from offerings","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-px22m"},"namespace":"","name":"compute-spot-ssd-px22m","reconcileID":"5e802191-c608-47c3-b1e1-3dff185fa042","reason":"UnfulfillableCapacity","instance-type":"m6id.32xlarge","zone":"us-west-2c","capacity-type":"spot","ttl":"3m0s"}
{"level":"DEBUG","time":"2024-08-04T21:21:43.857Z","logger":"controller","message":"removing offering from offerings","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-xljfq"},"namespace":"","name":"compute-spot-ssd-xljfq","reconcileID":"ef1d387d-9331-487a-8d31-4a4f4f945b79","reason":"UnfulfillableCapacity","instance-type":"m6id.32xlarge","zone":"us-west-2c","capacity-type":"spot","ttl":"3m0s"}
{"level":"DEBUG","time":"2024-08-04T21:21:44.104Z","logger":"controller","message":"created launch template","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-srfsr"},"namespace":"","name":"compute-spot-ssd-srfsr","reconcileID":"193883c2-f423-4c0d-8627-a53f7783be69","launch-template-name":"karpenter.k8s.aws/10396177074747622512","id":"lt-03eba214c01d56cd5"}
{"level":"ERROR","time":"2024-08-04T21:21:44.104Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-srfsr"},"namespace":"","name":"compute-spot-ssd-srfsr","reconcileID":"193883c2-f423-4c0d-8627-a53f7783be69","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.104Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-txjwm"},"namespace":"","name":"compute-spot-ssd-txjwm","reconcileID":"491b3b03-c122-4b68-974c-0f6e2e633cad","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.105Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-hn85j"},"namespace":"","name":"compute-spot-ssd-hn85j","reconcileID":"ba4d1c0a-df0e-460f-ba5f-bdae6956054d","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.105Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-8zqc8"},"namespace":"","name":"compute-spot-ssd-8zqc8","reconcileID":"b50d70bc-3212-4936-a37a-3c8f7fd7a376","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.105Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-lpv5w"},"namespace":"","name":"compute-spot-ssd-lpv5w","reconcileID":"44ad57ce-8adf-4387-8446-35f1d913c7ca","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.105Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-htddp"},"namespace":"","name":"compute-spot-ssd-htddp","reconcileID":"d609cd0b-1bc4-4631-b5fc-6c3964480ece","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.105Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-f8sx6"},"namespace":"","name":"compute-spot-ssd-f8sx6","reconcileID":"a34a6287-d166-4ddf-b451-562ec1edbe4b","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.106Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-8fdng"},"namespace":"","name":"compute-spot-ssd-8fdng","reconcileID":"12fe2acf-fb94-4140-ae3f-8ed5ace81d4c","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.106Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-lwkfj"},"namespace":"","name":"compute-spot-ssd-lwkfj","reconcileID":"79e4e28e-08a3-45ac-956d-a97eaae79cb1","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.106Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-cmkz4"},"namespace":"","name":"compute-spot-ssd-cmkz4","reconcileID":"ce771be5-2fac-43ba-8782-de3705e61af7","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.106Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-qhnbl"},"namespace":"","name":"compute-spot-ssd-qhnbl","reconcileID":"9f5a27d0-eea3-45fc-a413-ed25ae4ece58","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.106Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-hw88x"},"namespace":"","name":"compute-spot-ssd-hw88x","reconcileID":"9fa000df-7b17-4640-a9bb-54e80c5f917e","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.107Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-w72mw"},"namespace":"","name":"compute-spot-ssd-w72mw","reconcileID":"4a8ada8f-9630-4150-8f22-465a87ebf0a1","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.107Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-r7ctm"},"namespace":"","name":"compute-spot-ssd-r7ctm","reconcileID":"81a4acfc-b4e7-41f6-9f33-c6a2043a1292","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.107Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-rz64x"},"namespace":"","name":"compute-spot-ssd-rz64x","reconcileID":"9337981a-6b1a-4894-ade0-10bf87850856","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.107Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-j8zhg"},"namespace":"","name":"compute-spot-ssd-j8zhg","reconcileID":"5040998f-c5be-41f0-b9e3-6a4576559727","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.107Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-tmrls"},"namespace":"","name":"compute-spot-ssd-tmrls","reconcileID":"026ba85c-f765-42f7-99d6-4fe36b129139","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.108Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-k9vb7"},"namespace":"","name":"compute-spot-ssd-k9vb7","reconcileID":"dae8e77c-9704-4d89-bde2-e18ace176b6d","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
{"level":"ERROR","time":"2024-08-04T21:21:44.108Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-t5zr4"},"namespace":"","name":"compute-spot-ssd-t5zr4","reconcileID":"0907ac91-e125-4d79-98b6-f499584aaa41","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 3 instance type options"}
"level":"ERROR","time":"2024-08-04T21:21:58.715Z","logger":"controller","message":"failed while checking on-demand fallback","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-gh2qm"},"namespace":"","name":"compute-ssd-spot-gh2qm","reconcileID":"0f462406-3829-40c2-941b-bddda260ab0e","error":"at least 5 instance types are recommended when flexible to spot but requesting on-demand, the current provisioning request only has 1 instance type options"}
{"level":"INFO","time":"2024-08-04T21:21:58.913Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-4k2td"},"namespace":"","name":"compute-spot-ssd-4k2td","reconcileID":"70094f45-31ce-4137-a11b-61d32504085e","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.915Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-8jt7d"},"namespace":"","name":"compute-spot-ssd-8jt7d","reconcileID":"90de4713-9034-4bfa-b9a5-167ee736e219","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.925Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-srv46"},"namespace":"","name":"compute-spot-ssd-srv46","reconcileID":"b7f4c870-318b-49c9-960e-b816329d8366","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.930Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-w8xrs"},"namespace":"","name":"compute-spot-ssd-w8xrs","reconcileID":"50515180-1909-48b2-b1cd-ba9a1ffe5328","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.936Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-fvg7v"},"namespace":"","name":"compute-spot-ssd-fvg7v","reconcileID":"6956f2d2-33ed-40bc-ba82-3c9ed46cd839","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.942Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-khdvj"},"namespace":"","name":"compute-spot-ssd-khdvj","reconcileID":"236f3ebd-c91b-43fa-9f58-683412f44cd6","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.945Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-bwnn2"},"namespace":"","name":"compute-spot-ssd-bwnn2","reconcileID":"b7230cf0-641b-4aec-bb79-1722030d4538","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.948Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-bdfvm"},"namespace":"","name":"compute-spot-ssd-bdfvm","reconcileID":"0c222686-e31a-4e65-96af-7cf632478a87","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.949Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-449x9"},"namespace":"","name":"compute-spot-ssd-449x9","reconcileID":"ea8d2299-2bdf-4bf1-a06c-3aa761f74535","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.961Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-bmgg9"},"namespace":"","name":"compute-spot-ssd-bmgg9","reconcileID":"5d2003ba-fd34-4e4b-9558-095ac995627d","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.967Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-wr9st"},"namespace":"","name":"compute-spot-ssd-wr9st","reconcileID":"cdc32ace-1eee-4e80-b5d1-3075622d2b67","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.968Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-4g8td"},"namespace":"","name":"compute-spot-ssd-4g8td","reconcileID":"6c781641-9f91-49a2-845e-3e07fce54c1b","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.974Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-8zjjr"},"namespace":"","name":"compute-spot-ssd-8zjjr","reconcileID":"2c1c7ecb-fe00-44d6-8538-22328d801203","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.976Z","logger":"controller","message":"deleted nodeclaim","commit":"490ef94","controller":"nodeclaim.termination","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-spot-ssd-vd8rl"},"namespace":"","name":"compute-spot-ssd-vd8rl","reconcileID":"03c4a6f1-e41e-484d-b285-54d1c8034fe3","Node":{"name":""},"provider-id":""}
{"level":"INFO","time":"2024-08-04T21:21:58.977Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-9f659"},"namespace":"","name":"compute-ssd-spot-9f659","reconcileID":"facbed7e-d51b-40dc-b248-fad5171eb896","provider-id":"aws:///us-west-2b/i-0666f70deb39fdba0","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.977Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-j775t"},"namespace":"","name":"compute-ssd-spot-j775t","reconcileID":"323de3d0-ea1d-46ad-9d98-ed06b76665bf","provider-id":"aws:///us-west-2b/i-09e3a10b3549675ae","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.977Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-px7cs"},"namespace":"","name":"compute-ssd-spot-px7cs","reconcileID":"aa6b8fa8-575a-4fd7-8f75-c93454f04552","provider-id":"aws:///us-west-2b/i-0933a254ac600d7b5","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.977Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-p5cgx"},"namespace":"","name":"compute-ssd-spot-p5cgx","reconcileID":"3110e35d-5213-4c35-801d-60fa72f7fd07","provider-id":"aws:///us-west-2b/i-06192b095abf07c42","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.977Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-vlpd4"},"namespace":"","name":"compute-ssd-spot-vlpd4","reconcileID":"d3c37ba2-1ca9-4ad3-bdd0-fde53c227e97","provider-id":"aws:///us-west-2b/i-0a58c337eaa01d70b","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.978Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-m2gm4"},"namespace":"","name":"compute-ssd-spot-m2gm4","reconcileID":"cc23fb99-ec5b-4788-b36b-1984102cf898","provider-id":"aws:///us-west-2b/i-0390a351945362df1","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.978Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-gcfsf"},"namespace":"","name":"compute-ssd-spot-gcfsf","reconcileID":"21bb73c1-7c81-4b25-8b9e-a787b13c54f5","provider-id":"aws:///us-west-2b/i-00852d810a477ed18","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.978Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-jzg7s"},"namespace":"","name":"compute-ssd-spot-jzg7s","reconcileID":"024979fd-a0cb-4d24-bf72-d52bde2a68e8","provider-id":"aws:///us-west-2b/i-0fec922f996eca8d1","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.978Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-nbvjl"},"namespace":"","name":"compute-ssd-spot-nbvjl","reconcileID":"b44d458c-4b02-4679-86f3-b56f60bbe4bb","provider-id":"aws:///us-west-2b/i-073fa42bd834bbfa7","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}
{"level":"INFO","time":"2024-08-04T21:21:58.978Z","logger":"controller","message":"launched nodeclaim","commit":"490ef94","controller":"nodeclaim.lifecycle","controllerGroup":"karpenter.sh","controllerKind":"NodeClaim","NodeClaim":{"name":"compute-ssd-spot-jqmff"},"namespace":"","name":"compute-ssd-spot-jqmff","reconcileID":"bc70d909-fad0-44de-a678-911b211b7b4f","provider-id":"aws:///us-west-2b/i-0667718ba0d8c85b7","instance-type":"r6id.32xlarge","zone":"us-west-2b","capacity-type":"on-demand","allocatable":{"cpu":"127610m","ephemeral-storage":"89Gi","memory":"961470Mi","pods":"737","vpc.amazonaws.com/pod-eni":"107"}}

So it seems like you're getting a bunch of ICEs. Can you post your NodePool so I can see how flexible your instance type requests are? When Karpenter detects an ICE, it'll opt that instance type out from being chosen in future scheduling decisions, and try another instance type.
I don't actually see as many cluster state logs as I was expecting. Did you redact the number of these logs? This seems wrong to me that we would just indefinitely ICE and never look at anything. We should cleanup the nodeclaims on an ICE and cluster state should sync.
Can you post your NodePools, and also the nodeclass? I want to see if I can reproduce this, and we're not properly cleaning up our nodeclaims in our cluster state correctly.

Thanks for replying!
I didn't redact the logs. Please note there was availability issue for g5 and g4 instances so karpenter was creating/deleting NodeClaims before entering infinite ICE.
I have opened a support ticket and attached all our nodepools and nodeclasses. Our TAM will probably approach you later.

It happened again today. @njtran
There is no availability issue this time.
I doubt it's related to tens of OOM nodes. https://github.com/aws/karpenter-provider-aws/issues/6670

Thanks for opening the case. I haven't gotten a chance to look at this, but I'm wondering if you have reproduction steps since you've hit this again. For my understanding, it only remediates after you restart the controller? How long do you let it try to sync before you restart the controller pod?

I also want to reproduce this but honestly I don't know how. This happens in one of our three dev clusters. Other two were running fine.
As for the wait tine, I found this issue after almost two days for the first time. You can see the node count only decreased meaning nodes expiring.

Hi team, we hit similar issue here, basically from the metrics, the cluster sync state drops to 0 and no provisioning actions performed at all.
The huge jump between the second graph's data points are because missing data.

Restart controller helped

@njtran Also ran into this in testing with v1 with EC2 Spot Contexts & do-not-disrupt annotations. Sent specifics in an AWS Support case.


"Define and operate on a type represented as a bitfield" recipe

Use the bitflags crate.

Maybe show the creation of the type and a few representative operators and method calls, just to give a taste of what's possible.

duplicate of https://github.com/brson/rust-cookbook/issues/114


Serverless deployments: Just making a schema level change to a repository does not invalidate node_modules cache that contains generated Client

This is more a theory than a bug report, but this could explain why sometimes deployments to Netlify and other deployment providers do not actually deploy a new schema.
Example: https://github.com/netlify/build-image/blob/d51b4da41df1087448804e27626a32d83f50380f/run-build-functions.sh#L184-L197 npm install is only run if the sha of package.json is different, which it does not have to be if you only updated your schema. No npm install means not post install hook, means no prisma generate.
We should get a better overview here by designing a few test setups, and testing them at a few of these potentially affected providers to see how they handle that.

Most platforms provide a manual postinstall hook which can be used as a workaround here.

We should find a way to trigger that automatically or tell affected users about this, to avoid general confusion. This is one of the cases where we do not get issues, as "just try it again" often makes it work in the eyes of the user.

Related https://github.com/prisma/docs/issues/3590


docs: add two more examples

This PR introduces two new examples for the ClusterCIDR resource to demonstrate potential use cases.

/lgtm
/approve
Thanks


Add Japan Open Chain Mainnet

Network information

Name: Japan Open Chain Mainnet
ChainId: 81
RPC http/s address: https://rpc-1.japanopenchain.org:8545
Link to https://chainlist.org/: https://chainlist.org/chain/81
Blockexplorer: https://mainnet.japanopenchain.org/

When we provide a PR please deploy the singleton and if possible post an answer on this issue with the links to the blockexplorer addresses.

Hi @Uxio0, Thank you for your support:

[x] I have run RPC='http://my-rpc-address' yarn estimate

$ ts-node scripts/estimate.ts
{ chainId: 81 }
{ estimate: '68131' }
{ gasPriceGwei: '100.0', gasPrice: '100000000000' }
{ requiredFunds: '0.0068131' }
✨  Done in 4.96s.

[x] I have sent requiredFunds to 0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37
https://mainnet.japanopenchain.org/tx/0x9b1a0e5b5e9a56cabdd520e791b7467dfe9d7d7d04979fe1346f5d05e02458fbv

It has been deployed it at https://mainnet.japanopenchain.org/tx/0x6a29f77cf817188c27adc67b79777612883f9b17367715d1010f197b0e115023. Could you close this?


Programmatically select range

Hi, is it possible to select a range not clicking to dates but for example clicking on  a button like "Last 3 months" and then view the range selected on the calendar? Thanks

@davidecampello I'm wondering about the same issue, if You get rid of this please let me know.

Hi! unfortunatly not. As a workaround I created a custom modal with three buttons. When clicked they dismiss the modal passing the range I want.

Thanks for the reply. I have done it the same way, without integration with the calendar.
In my case, I need to pass the selected range by button when getting the calendar modal again, but there is a field for that in options input.


fix exclude undefined error

The original code have a potential bug. when use exclude option in query api. I fixed it and hope to update the code asap

Thanks for fixing this


Allow scrolling to move cursor without centering

Issue:
Scrolling the window (<C-e>, <C-y>, mouse, etc.) would center the screen if the cursor was at the top or bottom and the user scrolled down or up respectively. This made scrolling (especially with the mouse) very inconvenient when the plugin was active.
Fix:
Allows scrolling to move cursor by default, also provides option to use old behavior if the user wants

@xfzv can you confirm in Lazy that your plugin commit is c1cad1c?

Maybe there's been a miscommunication, my PR doesn't make scrolling center the cursor. It just fixes the issue where scrolling to the top/bottom of the screen caused the cursor to center itself making scrolling near impossible.
If you want scrolling to center the screen, it is probably easiest to rebind scroll wheel to jk:
vim.keymap.set('n', '<ScrollWheelUp>', '3k')
vim.keymap.set('n', '<ScrollWheelDown>', '3j')

No problem, thanks for finding the problem with scrolloff. I pushed a fix so scrolloff > 0 can be used with the plugin.

Pushed a change to allow natural mouse selection, I don't use the mouse often so let me know if there are any other mouse functions that break with the plugin.


Windows Installer - "Could not create SSL/TLS secure channel"

Expected Behavior
dapr needs to be installed without any issues.
Actual Behavior
PS C:\dapr> powershell -Command "iwr -useb https://raw.githubusercontent.com/dapr/cli/master/install/install.ps1 | iex"
Installing Dapr...
Creating c:\dapr directory
Invoke-RestMethod : The request was aborted: Could not create SSL/TLS secure channel.
At line:49 char:13
+ $releases = Invoke-RestMethod -Headers $githubHeader -Uri "https://ap ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

PS C:\dapr>

Steps to Reproduce the Problem

open powershell command window
run

powershell -Command "iwr -useb https://raw.githubusercontent.com/dapr/cli/master/install/install.ps1 | iex"

Reference:
[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls" https://stackoverflow.com/questions/41618766/powershell-invoke-webrequest-fails-with-ssl-tls-secure-channel


Restore using the class ClusterInfoRequest and ClusterInfoRequestBuilder from package 'org.opensearch.action.support.master.info' for subclasses

Description
[Describe what this change achieves]
Issues Resolved
https://github.com/opensearch-project/OpenSearch/issues/4203
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #4307 (3c4d86d) into main (1bfabed) will increase coverage by 0.06%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #4307      +/-   ##
============================================
+ Coverage     70.65%   70.72%   +0.06%
+ Complexity    57230    57219      -11
============================================
  Files          4610     4610
  Lines        275105   275105
  Branches      40283    40283
============================================
+ Hits         194376   194565     +189
+ Misses        64450    64238     -212
- Partials      16279    16302      +23

Impacted Files
Coverage Δ

...arch/action/admin/indices/get/GetIndexRequest.java
55.31% <ø> (ø)

...tion/admin/indices/get/GetIndexRequestBuilder.java
66.66% <ø> (ø)

.../admin/indices/mapping/get/GetMappingsRequest.java
50.00% <ø> (ø)

...indices/mapping/get/GetMappingsRequestBuilder.java
100.00% <ø> (ø)

...a/org/opensearch/tasks/TaskCancelledException.java
50.00% <0.00%> (-50.00%)
:arrow_down:

...cluster/coordination/PendingClusterStateStats.java
20.00% <0.00%> (-48.00%)
:arrow_down:

...regations/metrics/AbstractHyperLogLogPlusPlus.java
51.72% <0.00%> (-44.83%)
:arrow_down:

...opensearch/persistent/PersistentTasksExecutor.java
22.22% <0.00%> (-44.45%)
:arrow_down:

...adcast/BroadcastShardOperationFailedException.java
55.55% <0.00%> (-44.45%)
:arrow_down:

.../admin/cluster/reroute/ClusterRerouteResponse.java
60.00% <0.00%> (-40.00%)
:arrow_down:

... and 494 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[SMALLFIX] Merge 1.3

This PR merges branch-1.3. Conflicts are resolved in the latest commit.

LGTM

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11984/
Test PASSed.

Merged build finished. Test PASSed.


Permissions for Lookup access

In my solution sometimes I'm including Lookup from diferent modules. For instance, if I have a Module for Movies and a Module for Person then in Movies I use the Person Entity for Lookup CastCrew.
If I have two Roles that manage Movies and Persons separately the problem becomes that when I allow Read Permission for Person Entity the Person Module shows up in the Menu navigator.
What should be the best practice?
Add another type of permission?
Add a second Person Lookup specific for the Movie Module (Redundant)?
Change the navigation menu to check for aditional permissions?
Thanks!

Set lookups permission to empty string or ? for logged in users.
Or if lookups has sensitive info, need to define a separate permission.

Like this?
PersonRow.cs
....
[LookupScript("Persons.Person"), RequiredPermission("?")]
....
MovieRow.cs
    ...
    [DisplayName("Movies"), Column("IDMovie"), ForeignKey("[dbo].[Movies]"...
    [LookupEditor("Persons.Person")]
    public Int32? IdPerson
    {

This does not work... :-(

LookupScript("Persons.Person", Permission = "?")


pytorch quantizer error

When using the pruned restnet50 model of  pytorch quantizer (Vitis-AI-Quantizer)  provided by Vitis AI, I encountered the following problems

I use torch.load() import model like this

How to solve it? Thanks.

@niuxjamd
Thank you for your reply，I modified it on the basis of the above code. The original model can be quantified, but I pruned the model to solve the above problems.


[e2e]: container-based schedule main gcp-workload-identity slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6464285773
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Tue Oct 10 03:20:38 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6477533810
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Wed Oct 11 03:20:25 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6490809115
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Thu Oct 12 03:20:34 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6503587003
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Fri Oct 13 03:21:01 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6515253702
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Sat Oct 14 03:20:26 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6521643007
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Sun Oct 15 03:16:14 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6521665165
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Sun Oct 15 03:22:15 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6528561488
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Mon Oct 16 03:21:02 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/6542077260
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.schedule.main.gcp-workload-identity.slsa3.yml
Trigger: schedule
Branch: main
Date: Tue Oct 17 03:25:21 UTC 2023
Tests are passing now. Closing this issue.


jacoco cannot instrument classes when using testcontainers

Haven't done too much digging yet, but I noticed that any integration tests which use testcontainers don't show up in the instrumented classes list in a jacoco coverage report resulting in coverage of 0%. Commenting out any use of testcontainers (and allowing the tests to file) will result in properly instrumented classes.
Does testcontainers rewrite any of the class files when it runs?

I think this may actually be related to issue #163 so closing for now.

Hi Adam
I've not tested this in conjunction with jacoco., but there shouldn't be
any big issues I can foresee You say you think this relates to #163, but
that's a pretty different issue which I can't see how could be linked to
use of Jacoco. Is this just a case of mysterious symptoms/coincidence
leading you to think that jacoco was involved in the problem?
I'd just like to be confident that you've not encountered #163 plus another
unknown bug at the same time :)
Thanks
Richard
On Tue, 28 Jun 2016 at 02:34 Adam Kunicki<EMAIL_ADDRESS>wrote:

Closed #165
https://github.com/testcontainers/testcontainers-java/issues/165.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/testcontainers/testcontainers-java/issues/165#event-705744872,
or mute the thread
https://github.com/notifications/unsubscribe/AAIET0k2ZvSWXP3fvIFPOuBIuyNsa-iGks5qQHo3gaJpZM4I_p_S
.

--
Richard

Created a fresh setup with a downgraded docker and it was def just #163. Was a bit too quick to open an issue.
	_____________________________

From: Richard North<EMAIL_ADDRESS>Sent: Tuesday, June 28, 2016 12:16 AM
Subject: Re: [testcontainers/testcontainers-java] jacoco cannot instrument classes when using testcontainers (#165)
To: testcontainers/testcontainers-java<EMAIL_ADDRESS>Cc: Adam Kunicki<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Hi Adam
I've not tested this in conjunction with jacoco., but there shouldn't be
any big issues I can foresee You say you think this relates to #163, but
that's a pretty different issue which I can't see how could be linked to
use of Jacoco. Is this just a case of mysterious symptoms/coincidence
leading you to think that jacoco was involved in the problem?
I'd just like to be confident that you've not encountered #163 plus another
unknown bug at the same time :)
Thanks
Richard
On Tue, 28 Jun 2016 at 02:34 Adam Kunicki<EMAIL_ADDRESS>wrote:

Closed #165
https://github.com/testcontainers/testcontainers-java/issues/165.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/testcontainers/testcontainers-java/issues/165#event-705744872,
or mute the thread
https://github.com/notifications/unsubscribe/AAIET0k2ZvSWXP3fvIFPOuBIuyNsa-iGks5qQHo3gaJpZM4I_p_S
.

--
Richard
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

Cool, no probs. Thanks for the update!
On Tue, 28 Jun 2016 at 08:18 Adam Kunicki<EMAIL_ADDRESS>wrote:

Created a fresh setup with a downgraded docker and it was def just #163.
Was a bit too quick to open an issue.

From: Richard North<EMAIL_ADDRESS>Sent: Tuesday, June 28, 2016 12:16 AM
Subject: Re: [testcontainers/testcontainers-java] jacoco cannot instrument
classes when using testcontainers (#165)
To: testcontainers/testcontainers-java <
<EMAIL_ADDRESS>Cc: Adam Kunicki<EMAIL_ADDRESS>State change <
<EMAIL_ADDRESS>Hi Adam
I've not tested this in conjunction with jacoco., but there shouldn't be
any big issues I can foresee You say you think this relates to #163, but
that's a pretty different issue which I can't see how could be linked to
use of Jacoco. Is this just a case of mysterious symptoms/coincidence
leading you to think that jacoco was involved in the problem?
I'd just like to be confident that you've not encountered #163 plus another
unknown bug at the same time :)
Thanks
Richard
On Tue, 28 Jun 2016 at 02:34 Adam Kunicki<EMAIL_ADDRESS>wrote:

Closed #165
https://github.com/testcontainers/testcontainers-java/issues/165.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/testcontainers/testcontainers-java/issues/165#event-705744872
,
or mute the thread
<
https://github.com/notifications/unsubscribe/AAIET0k2ZvSWXP3fvIFPOuBIuyNsa-iGks5qQHo3gaJpZM4I_p_S
.

--
Richard
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/testcontainers/testcontainers-java/issues/165#issuecomment-228970944,
or mute the thread
https://github.com/notifications/unsubscribe/AAIET1Z-Nhy6y7KXqMimapY7vzWt_pIsks5qQMragaJpZM4I_p_S
.

--
Richard

Is it solved. In my case, I am not able to get code coverage as though I am able to attach jacoco agent to container. I am trying with -javaagent:/tmp/conf/jacocoagent.jar=output=file,destfile=/opt/test.exec
It is possible to get coverage report if I pass output as tcpserver instead of output=file. But in this case I have to make explicitly send http request. I am not sure how should I do this in test container.
I mean as per my knowledge the container terminated immediately after test completed. Could you please suggest how to handle it or is there any other mechanism to extract code coverage.


Move suppression from method to class level

Type: (bugfix / feature / refactoring / documentation update)
Issue: Resolves #.. the corresponding issue for this PR (if exist)
Breaking change: yes/no (if yes explain why)

Can you please fill the template of the description and explain the reason of this change.
Both method-level and class-level suppression are possible in theory and I would recommend to be as precise as possible when bypassing a rule. I personally use only method-level ones.

Ah, I need to delete this then and open a bug fix then because the warning is not suppressed when I add it to a method but it goes away when added to class-level. Example:
Warning not suppressed:
`/**

@ApiResource()

@ODM\EmbeddedDocument

@SuppressWarnings(PHPMD.LongVariable)
/
class Affiliate
{
/*

@ODM\Id(strategy="increment", type="integer")
@var int
*/
private $id;

/**

@Groups({"client:read", "client:update", "siteConfig:read", "siteConfig:write"})
@ODM\Field(type="string", nullable=true)
@var string|null
*/
private $affiliateLink;

public function getId(): int
{
return $this->id;
}
public function getAffiliateLink(): ?string
{
return $this->affiliateLink;
}
public function setAffiliateLink(?string $affiliateLink): void
{
$this->affiliateLink = $affiliateLink;
}
}`

Warning suppressed
`class Affiliate
{
/**
* @ODM\Id(strategy="increment", type="integer")
* @var int
*/
private $id;
/**
 * @ODM\Field(type="string", nullable=true)
 * @var string|null
 *
 * @SuppressWarnings(PHPMD.LongVariable)
 */
private $affiliateLink;

public function getId(): int
{
    return $this->id;
}

public function getAffiliateLink(): ?string
{
    return $this->affiliateLink;
}

public function setAffiliateLink(?string $affiliateLink): void
{
    $this->affiliateLink = $affiliateLink;
}

}`

OK, I see, suppression is possible on classes and methods, but probably not on properties (I never tried). So it's more likely a request for a new feature.
So the documentation could be improved to tell about what is know to work properly such as a mention:

Annotation can either be added over methods or classes.

Rather than remove the method example with UnusedLocalVariable that actually works.
Then an other issue would be to handle the case of property annotations.

Ah, of course. Good spot. Thank you.


This thing is a freaking ghost

I removed this.
No search engine finds any remain of this.
Why won't this go away.

I have no idea.  I don't know how you installed it or how you removed it.

@facelessuser First I downloaded the folder. Then I deleted it.

You've clearly left some files somewhere.  I would check in you packages folder and your installed packages folder.  This isn't a problem with this plugin, but with something you've done.

As this is not reproducible, I am closing this issue.


When response its 401 promise keeps pending

Hey how are you? nice project thanks for making it! Well im here to let you know that when we make a POST request with credentials keys username, password, domain defined, and for example the username its wrong, the server responses with 401 Unauthorized but the axios promise keeps pending, so i cant get the statusCode or the message, i view the code i see that you use interceptors, maybe there its a problem. I wait for youre reply and again thanks for all! if you need to debug it or more information about the bug please tell me. Thanks

i closed because its duplicated https://github.com/Catbuttes/axios-ntlm/issues/4
i follow it in that issue


Unable to find the mlx package

While running the pip install mlx-vlx i am unable to find the mlx library or package

Is the mlx package available only for the macos and is the mlx-vlx only for macos


[Gally]: master <- dev

Automatically created by Git-Ally

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update Multiple Nodes Demo

Use QueryDispatchLibrary Class

The code was tested locally with the following script:
pushd loadgen

# Start 3 servers. with Names Node1, Node2, Node3.
# store thier pids so we could kill them later.
pids=()
for i in {1..3}
do
    port=$(( 8000 + $i ))
    python demos/lon/sut_over_network_demo.py --port ${port} --node Node${i} &
    pids+=($!)
    echo "Started server on port ${port} with pid ${pids[$i-1]}"
done

# Create the list of sut servers. It is a comma seperated list with IP:port
# In our case, IP=http://localhost, and port is 8001, 8002, 8003
sut_servers=`for i in {1..3}; do echo -n "http://localhost:$(( 8000 + $i )),"; done`
# Remove the last comma
sut_servers=${sut_servers::-1}

# Start the test:
python demos/lon/py_demo_server_lon.py --sut_server ${sut_servers}
# check return code. If it is not 0, then the test failed.
retval=$?
if [ $retval -ne 0 ]; then
    echo "Test failed with return code $retval"
else
    echo "Test Finished Successfully"
fi

echo "Killing servers"
# Kill the servers
for pid in ${pids[@]}; do kill -9 $pid; done

popd

I used this to setup the env and build:
# git clone
REPO_URL="git@github.com:liorkhe/inference.git"
BRANCH_NAME="liorkhe-MNodes-patch-1"

git clone ${REPO_URL}
cd inference
# switch to branch
git checkout ${BRANCH_NAME}

# create a new virtual env
python3 -m venv venv
# activate the virtual env
source venv/bin/activate

# Install dependencies
pip install absl-py numpy wheel flask requests

# change git submodule to reflect the branch
# before:
# url = ../power-dev
# after:
# url = https://github.com/mlcommons/power-dev.git
new_url="url = https://github.com/mlcommons/power-dev.git"
# in file .gitmodules
sed -i 's|url = ../power-dev|'"${new_url}"'|g' .gitmodules
# Now, update the submodule
git submodule update --init --recursive
# NOTE: May need to do:
# git submodule sync --recursive

pushd loadgen
# build debug mode
# CFLAGS="-std=c++14 -O0 -g" python setup.py bdist_wheel
CFLAGS="-std=c++14 -O3" python setup.py bdist_wheel
cd ..; pip install --force-reinstall loadgen/dist/`ls -r loadgen/dist/ | head -n1` ; cd -
popd


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/101724

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/103179

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/103178

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/109909

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/118504


Add implementation of Trie in Java

Add implementation of Trie in Java using one example of a dictionary-based graph and comment on the code properly.

Hi @dubesar, I'd like to help out with this one!

@iishyfishyy  go for it!!

Created PR.


[Bug]: unexpected parse result for 'with ( nolock )' and multibyte utf8 string

What happened?
when 'with (nolock) ' comes with multibyte utf8 string, the parser generate unexpected result.
Example:
select "你好世界" from tbl with(nolock);

Will generate incomplete table name or "wstring_convert::from_bytes" error.
This is because Antlr4 Token index returns an UTF32 char index in function
https://github.com/babelfish-for-postgresql/babelfish_extensions/blob/95c1a016f1ca835bb57cc38f89238e7e501ea614/contrib/babelfishpg_tsql/src/tsqlIface.cpp#L3382.
but expr->query is UTF8 encoded, memset with UTF32 index will break query.
In my test, a function to get real uint8 byte index will solve this problem.
size_t utf8RealIndex(char * s, size_t idx){
	size_t real=0;
	for (int i=idx;i>0;i--){
		if (s[real]==0){
			return real;
		}else if(s[real]<=0x7f){
			real++;
		}else if((s[real]&0xE0)==0xC0){
            real+=2;
        }else if((s[real]&0xF0)==0xE0){
            real+=3;
        }else if((s[real]&0xF8)==0xF0){
            real+=4;
        }
	}
    return real;
}

I wish there is a better solution merged in.
Version
BABEL_1_X_DEV (Default)
Extension
babelfishpg_tsql (Default)
Which flavor of Linux are you using when you see the bug?
Ubuntu (Default)
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct.

My fork works for this problem
https://github.com/yjhatfdu/babelfish_extensions/tree/BABEL_2_3_STABLE


Serialize doc comments

This issue existed before the move to toml_edit https://github.com/toml-rs/toml-rs/issues/274
The issue was also brought up to serde https://github.com/serde-rs/serde/issues/1430
It would be a nice feature to write comments for config files, whether it uses serde or a macro
(I think the prior would be the cleanest) :+1:

Seeing as this was rejected by serde, there isn't room for this to exist in the toml crate which will be focusing on serde support going forward.  You can manually set comments via the toml_edit crate, though.    Creating a whole new serialization system with derives to handle this would be out of scope though people are welcome to experiment with it.

writing to a toml file with comments creates an unreadable corrupted file at worst,

In what way are corrupted files written?

wipes out the comments at best

As I said, toml_edit is an option.  It is a format preserving parser / writer.  It is used by cargo add to preserve your Cargo.toml while adding or modifying dependency entries.

Is it possible to add a comment type as another variant to the Value enum?  I too would like to be able to serialize comments into the TOML files that I output as TOML is meant to be human-readable.
Mainly, I want to be able to produce partially customized files that the reader can read through and customize afterwards.  They are partially customized in two ways:

I have a tool that scans their system to preset options appropriate for them.  That means that one size doesn't fit all.
I want the comments to be in their native language.  Once again, one size doesn't fit all.

Thus, the comments are more than just whitespace, they are a necessary feature of the file.

OK, I just checked it out.  I think that will work for my use case.  Thank you!

Just mentioning it here because it took me a while to figure out - the way to add comments with toml_edit is by calling decor_mut on a Formatted Value and then calling Decor::set_prefix with your comment as the argument.

Just mentioning it here because it took me a while to figure out

Thanks this was very helpful! Here's an example for posterity:
use documented::DocumentedFields;
use serde::Serialize;
use struct_field_names_as_array::FieldNamesAsArray;
use toml_edit::ser::to_document;

/// A test struct
#[derive(Default, DocumentedFields, FieldNamesAsArray, Serialize)]
struct TestMe {
    /// First field
    ///
    /// Second line
    field1: u32,
    /// Second field
    field2: String,
}

let test = TestMe::default();
let mut doc = to_document(&test).unwrap();

for (mut key, _value) in doc.iter_mut() {
    let key_name = key.get().to_owned();
    let decor = key.decor_mut();
    let docstring = TestMe::get_field_comment(key_name).unwrap();

    let mut comment = String::new();
    for line in docstring.lines() {
        let line = if line.is_empty() {
            String::from("#\n")
        } else {
            format!("# {line}\n")
        };
        comment.push_str(&line);
    }
    decor.set_prefix(comment);
}

let actual = doc.to_string();
let expected = "# First field\n#\n# Second line\nfield1 = 0\n# Second field\nfield2 = \"\"\n";
assert_eq!(actual, expected);

@Notgnoshi Thanks for the example. I'm trying to generate a default config file that includes comments, so this is pretty much exactly what I need.
P.s. It's wild to see what was originally just my own toy crate (documented) being used by actual people. I'm glad you're finding it useful!

And this is what I ended up with. Just thought I'd share it with anyone who needs a simple (well, somewhat simple) and practical example.

I've spent two days trying to add doc comment support to my personal config derive macro crate. Getting the comments was easy, especially with the documented crate.
However, I made things harder on myself by trying to use toml_edit for TOML. Working with leaf and dotted decor ended up being much more complex than I needed.
I realize this isn't really what toml_edit was designed for, and my limited understanding of its internals doesn't help. Even after spending $35 in Sonnet 3.5 credits with Cline to analyze toml_edit’s source and various examples above, it couldn't get it right, but it was able to create a line-by-line version that worked perfectly without.


[Marketing] SWOT analysis

Goal is to provide the Client with detailed SWOT analysis from the research task.

To determine the strengths, weaknesses, opportunities and threats of the project

SWOT Analysis - LearnHub.docx
Completed


0.11.7 broken custom templates

i've updated to 0.11.7, but custom templates still doesn't work

Hi @lustrumnews, when you pressed "new issue" there was a template showing what info to provide. Please take a moment to fill that out explaining the exact problem, as there's nothing I can do with this report - a quick test shows no issue.


IntlProvider doesn't even render children components.

This has been frustrating trying everything to get this to work, since l18n is something I need. I have a basic app just to get everything working, but it doesn't even work, even if its the same as in the examples in the documentation... Snippet:
render() {
    console.log("This prints");
    const AppB = () => {
      console.log("This doesn't even print for some reason");
      return (

content

      );
    }
    return (
      <IntlProvider definition={defaultDefinition}>
        <AppB />
      </IntlProvider>
    );
  }

AppB functional component is not rendered, ITS NOT EVEN BEING CALLED, somehow?!

You may need to check that your version of preact is in sync with your preact-i18n version. If you have preact>=10 you will want to use the preact-i18n@preactx version with npm install preact-i18n@preactx.
I think it may have been a long enough time that we can cut over the preactx tag to the latest version so people don't run into this too often.


Destructive installation

Installing mermaid to use with jupyter (installed by anaconda) in windows destroy my installation of jupyter, no one kernel cant work, they just fail to start.
I did two times (the first time I wasnt sure that it was after install mermaid). What I see is that installing mermaid by pip install nb-mermaid uninstall the previous installed ipython to install an old version, this mess up everything.
Please, fix it.

Happened to me too when doing a pip install.

Same


Tweak Optional types so that type assertions in arcade are not necessary

There are two different Optional types in pytiled_parser affecting us in pythonarcade/arcade#1751
Based on discussion, these types can be made non-optional in pytiled_parser which will (eventually) eliminate the need for the downstream assertions in arcade.
Discord conversation:
https://discord.com/channels/458662222697070613/458662458198982676/1108508437832270034
Tile.width and Tile.height are Optional
https://github.com/pythonarcade/pytiled_parser/blob/47297a72c700f9b8cd558ef26420bc742b84f7f2/pytiled_parser/tileset.py#L124-L125
So we use type assertions here:
https://github.com/pythonarcade/arcade/blob/4d7d846b5c853a509ae818bf98152623451eeb6f/arcade/tilemap/tilemap.py#L70-L73
TiledMap.map_file is Optional
https://github.com/pythonarcade/pytiled_parser/blob/47297a72c700f9b8cd558ef26420bc742b84f7f2/pytiled_parser/tiled_map.py#L72
So we use a type assertion here:
https://github.com/pythonarcade/arcade/blob/4d7d846b5c853a509ae818bf98152623451eeb6f/arcade/tilemap/tilemap.py#L419-L421

This is fixed in 2.2.3, none of these are optional anymore.
map_file is always guaranteed to be set now, and width, and height will default to 0 if they are somehow not set(though under normal circumstances with a valid map/tileset file they will always be set)


Fix numbered list formatting in markdown.

Fixes the numbering scheme 1., 1., 1., etc., as seen in the screenshot:

The numbering above is incorrect because the code blocks were not indented correctly. Also, although, the numbering scheme 1,1,... works correctly with markdown, I think it's confusing for a developer opening the file in an editor that doesn't support markdown format. The corrected markdown format looks like this.
/CC: @clintropolis, thanks!

Sorry, if this slipped between the cracks. @jihoonson / @vogievetsky, could you please take a look when you get a chance? Thanks!


Fix trade_client IndentationError

Remove an indentation level from the convert_volume function in trade_client.py to fix an IndentationError.

LGTM

Thanks! Merging this in now


docs: fixes minor typo (pefectly -> perfectly)

Quite possibly the smallest contribution I could make. Should have read through the docs sooner, incredible.

Thanks a ton for this, and sorry for the huge delay!


Colour coding Marks

Hi, thanks a lot for this project. It has been super useful so far!
I am having a little bit of an issue while colour coding marks in scatter plots. If I choose classical colours as 'red' or '#FF0000' it works fine, however if I select more exotic colours such as '#3B0B39' it doesn't plot anything.
gmap.scatter(lats, lons, '#FF0000', marker=True) -> works, yeyy :)
gmap.scatter(lats, lons, '#3B0B39', marker=True) -> doesn't work :(
Any idea of why I am having this problem?
#I am using python 3.6 on a mac

Just realised that the code loads a marker with the specific colour rather than creating one so that solves my question!


Download CSV button on search page should download all results

Overview
Clicking "Download CSV" after conducting a search should download all search results, not just the first 500
Is your feature request related to a problem? Please describe.
It is confusing that the downloaded CSV does not return all the listed search results. Several brands and users have reported confusion around this feature.
Describe the solution you'd like
Include all search results in the CSV
Additional Context
@katieashaw and @nataliegrillon Please add any other pertinent information that users have reported about this issue.

Superseded by #743


fix update_sensors function not filtering correctly attr

Hello,
A fix for the update_sensors() function.
The conditions should be 'and' instead of 'or'.
Also filter device_id and endpoint_id, no need to push them as a sensor, they are available in json attributes topic.

Hi @NathanKun ,
LGTM 👍
Thank you for your contribution !

Released as 3.3.0.


Add generator and GAN

Along with fixing load data and redoing normalization scheme.

@Victoria-Williamson had a merge conflict but that should be fixed now.

Also sorry I ended up doing something that was assigned to you.


Cant get to work with exclude with merge.smart

Test case:
merge.smart({
  module: {
    loaders: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loaders: ['babel']
      }
    ]
  }
}, {
  module: {
    loaders: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loaders: ['coffee', 'thing']
      }
    ]
  }
});

module.loaders =
[
  {
    test: /\.js$/,
    exclude: /node_modules/,
    loaders: [ 'coffee', 'thing' ]
  },
  {
    test: /\.js$/,
    exclude: /node_modules/,
    loaders: [ 'babel' ]
  }
]

Hi,
The current behavior is explained by this test.
The case you mention is a subset of this, though, as exclude is exactly the same. Based on that it would be safe to merge loaders so that we end up with a declaration like loaders: ['babel', 'coffee', 'thing'].
Do you want to PR that?
Btw, I made an initial test case for this:
...

describe('Smart merge', function () {
  const merge = webpackMerge.smart;

  smartMergeIssueTests(merge);
  smartMergeTests(merge, 'preLoaders');
  smartMergeTests(merge, 'loaders');
  smartMergeTests(merge, 'postLoaders');
  mergeTests(merge);
});

...

function smartMergeIssueTests(merge) {
  it('should merge with exclude and loaders', function () {
    const a = {
      module: {
        loaders: [
          {
            test: /\.js$/,
            exclude: /node_modules/,
            loaders: ['babel']
          }
        ]
      }
    };
    const b = {
      module: {
        loaders: [
          {
            test: /\.js$/,
            exclude: /node_modules/,
            loaders: ['coffee', 'thing']
          }
        ]
      }
    };
    const result = {
      module: {
        loaders: [
          {
            test: /\.js$/,
            exclude: /node_modules/,
            loaders: ['babel', 'coffee', 'thing']
          }
        ]
      }
    };

    assert.deepEqual(merge(a, b), result);
  });
}

...

@bebraw are you suggesting that we alter the current behavior to accommodate smarter merges when the excludes matches too?
If so, yes I'll take a stab at that.

Yeah. Satisfying that test I made would be enough.

So, seems like this might be a bit challenging since both allow regex values. Comparing regex can't be done plainly afaik. You would have to compare them as string values, but then they could also be arrays...
Any thoughts?

SO suggest converting to string so maybe that could work.
Good point about arrays. Consider that as a special case and test separately. Array.isArray should do the trick.


Fix timeline for one host [fixes #12]

@just-boris could you please take a look

@just-boris change name with camelCase

Actually, the code was changed so much since I touched that last time, so I just checked that it looks like it is supposed to be, not deeply looking into details.

@sseliverstov thanks!


Dynamic XML3D objects initialization problem

Hi,
I'm having a problem with loading new xml3d objects dynamically. What I am trying to achieve is to use xml3d to visualize a 3d .stl file, which has been uploaded using ajax file upload. Once the file gets uploaded, the server returns a json response containing some html, which is inserted via jquery to a specific container. The document already contains all the necessary xml3d scripts, including xml3d.js, camera.js and the xml3d-stl-pligin.js.
After the html with the xml3d tag gets inserted to the container, the model does not get visualized.
The app is an ASP.NET MVC web app, tested it on the current Chrome, Firefox, Opera and IE11 and the model is not getting visualized in any of them.
You can find a snippet below.
Main document's head part: (1)

... other head scripts and styles ...

Main document's body part: (2)

Your model is being prepared. Please wait...

				@Html.Partial("_VisualizerFileUpload", Model)

The after-upload html response part: (3)

    <xml3d style="width:676px;height:378px" id="myxml3d">
        <shader id="phongShader" script="urn:xml3d:shader:phong">
            <float3 name="emissionColor" id="shaderemissionColor">1 1 1</float3>
            <float3 name="ambientColor" id="shaderambientColor">1 1 1</float3>
            <float3 name="specularColor" id="shaderspecularColor">1 1 1</float3>
            <float3 name="reflectionColor" id="shaderreflectionColor">1 1 1</float3>
            <float3 name="diffuseColor" id="shaderdiffuseColor">1 0.5 0</float3>
            <float name="shininess" id="shadershininess">0.5</float>
            <float name="ambientIntensity" id="shaderambientIntensity">0.5</float>
        </shader>

        <lightshader id="directionalLight" script="urn:xml3d:lightshader:directional">
            <float3 name="intensity" id="lightIntensity">1 0.5 0</float3>
            <float3 name="position" id="cameraPosition1">-100 -50 -458.801</float3>
            <float3 name="direction" id="cameraDirection1">0 20 -46.827</float3>
            <bool name="castShadow">false</bool>
        </lightshader>

        <light shader="#directionalLight"></light>

        <view position="0 0 200" id="myView"></view>
        <navigation revolvearound="0 0 0" id="myRotation"></navigation>
        <group shader="#phongShader" style="transform: translate3d(0px,-20px,0px)">
            <mesh id="xml3dmesh" src="uploaded/samplestlfile.stl" type="triangles"></mesh>
        </group>
    </xml3d>

A piece of javascript from the file uploader: (4)
$('#fileupload').fileupload({
        maxNumberOfFiles: 1,
        dataType: 'json',
        start: function (e, data) {
            //show file upload progress
        },
        done: function (e, data) {
            if (data.result.IsError) {
                //an error occurred, show error messages
            }
            else {
                $('#VisualizerContainer').html(data.result.ResponseView);
// data.result.ResponseView contains the html part with the xml3d object (3)
                //some other javascript (hide overlays, etc)
            }
        },
        progress: function (e, data) {
            //manage progress bar
        },
        dropZone: $('.files-uploader .drop-zone')
    });

Might have been a quick fix :)
I've just deployed it to the xml3d.js hosted at xml3d.org, could you test your application again and see if it works properly now?

After the fix it does visualize the model so that's great.
However what is still not ok, is that the camera.js doesn't work. I can't rotate, zoom or pan the visualized model.

I think you'll need to initialize the camera after the XML3D element has been initialized. I would use a framedrawn listener on the XML3D element after you insert it into the DOM:
$('#VisualizerContainer').html(data.result.ResponseView);

$("#myxml3d").on("framedrawn", function() {
    var cam = new XML3D.Xml3dSceneController($("#myxml3d")[0]);
});

Yes, that did the trick, although I had to use the load event instead of framedrawn, because the model got very crazy after I zoomed in/out or panned the view.
So I used:
$('#VisualizerContainer').html(data.result.ResponseView);

$("#myxml3d").on("load", function () {
    var cam = new XML3D.Xml3dSceneController($("#myxml3d")[0]);
});

So this solved my problem completely and I think this issue can be closed. :)

You're right the load event is a better choice, if you don't remove the framedrawn listener after the first frame it re-initializes the camera every frame :o
Thanks for the example code! I'm glad we could finally squash this bug.


Improve README indetation formatting of code snippets

Use two spaces for code indentations everywhere.
Did this to unify the formatting.
Initialize Memphis connection in OnModuleInit lifecycle method.
The OnModuleInit method is the best place for such asynchronous callback.
This is because it is a lifecycle method
Did this "OnModuleInit-Change" for only the first snippet.
Supposedly, the developer might do other things with the "value-setting"
initializations of the other code snippets.

Hi @obumnwabude, thanks for the feedback, it seems like we can merge your changes, but please open this PR to branch named staging

Hi @idanasulinmemphis, I switched the base branch to staging instead of recreating a new pull request. I think it should solve the issue.

There are a few changes made by us in the last week, so please notice the differences between the parameters passing to the connect function.
So please take a look and commit that and then I'll be able to approve your PR

It's like those changes do not affect this pull request. Or rather, its like I have addressed the changes. You know this pull request only targeted the README file. And GitHub is not showing the resolve conflicts again as it is showing in the other PR.

I noticed it is only the readme file, but if you will take a closer look there is a section of the connect function (line 95).
We have made some changes there

As discussed on Discord, please open this PR to master branch


Optionally convert variable to casadi format before evaluating

Right now, for fast models such as the SPM, solving the model takes 2 ms but evaluating the voltage takes 160 ms.
Under the right combination of conditions, it might be faster to convert a variable to casadi before evaluating it. The converted variable could be saved to a dictionary such as model.casadi_variables which would then be available to the next solution. This could also bypass the need for doing y.full() after solving to convert from casadi format to numpy format (y.full() takes as much time as doing the integration itself, 0.5 ms).
Could also try vectorizing as suggested in #788

Would this work best for the volume averaged properties? If this were a CFD solver you could define monitoring points etc in the mesh to keep an eye on certain variables - not sure wee need to go that far and we're not monitoring convergence but I really like the idea of getting a few bits of key info on the fly - would help me solve the jellyroll problem a bit faster

I don't think volume-averaged or not makes a difference. There is no way to evaluate at just a single point without evaluating the whole thing first. (In general) the volume-averaged variables are the explicit integral (i.e. the dot product of a vector of ones and the variable) so you have to evaluate the full distribution before you can get the volume-averaged variable.


Add support for deploy freeze

One of the CI CD related setting Gitlab provides is to configure deploy freeze. Would be great if we could manage this setting through gitlabform.

Hi, thanks for the suggestion @amimas! It looks like a fairly typical multi-entity API -https://docs.gitlab.com/ee/api/freeze_periods.html. As always, we are open to PRs with this feature added.


Occasional crash after 'flutter run' has been running for 15 seconds - Android

I happened to perform an action on the UI at the time of the crash but I'm not convinced it's related:
01-10 10:47:23.761   504   525 I ActivityManager: Displayed com.google.fuchsia.armadillo/org.domokit.sky.shell.SkyActivity: +690ms
01-10 10:47:23.872  3841 21801 I Icing   : Indexing 736E1589B5AE0A06414B8B4044200F3C3F4F8ADD from com.google.android.gms
01-10 10:47:23.890 18771 20057 W SearchService: Abort, client detached.
01-10 10:47:23.900 18771 18771 I MicroDetector: Keeping mic open: false
01-10 10:47:23.903 18771 19591 I MicroRecognitionRunner: Stopping hotword detection.
01-10 10:47:23.905 18771 22122 I AudioController: internalShutdown
01-10 10:47:23.905 18771 22122 I MicrophoneInputStream: mic_close com.google.android.apps.gsa.speech.audio.ae@a8565f1
01-10 10:47:23.906 18771 21997 I DeviceStateChecker: DeviceStateChecker cancelled
01-10 10:47:23.907 18771 22002 I PBSessionCacheImpl: Deleted sessionId[21050532253856346] from persistence.
01-10 10:47:23.912   504  3657 I WindowManager: Destroying surface Surface(name=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL) called by com.android.server.wm.WindowStateAnimator.destroySurface:2014 com.android.server.wm.WindowStateAnimator.destroySurfaceLocked:881 com.android.server.wm.WindowState.destroyOrSaveSurface:2073 com.android.server.wm.AppWindowToken.destroySurfaces:363 com.android.server.wm.AppWindowToken.notifyAppStopped:389 com.android.server.wm.WindowManagerService.notifyAppStopped:4456 com.android.server.am.ActivityStack.activityStoppedLocked:1252 com.android.server.am.ActivityManagerService.activityStopped:6873
01-10 10:47:23.931   246   325 I SoundTriggerHwService::Module: void android::SoundTriggerHwService::Module::onCallbackEvent(const sp<android::SoundTriggerHwService::CallbackEvent> &) mClient == 0
01-10 10:47:23.938 18771 21998 I MicroRecognitionRunner: Detection finished
01-10 10:47:23.941  3841 21801 I Icing   : Indexing done 736E1589B5AE0A06414B8B4044200F3C3F4F8ADD
01-10 10:47:23.944  3841 21801 I Icing   : Indexing DDBD0DEF07769388B09FC9B4321A6BC5EFD04345 from com.google.android.googlequicksearchbox
01-10 10:47:23.961   504   525 I WindowManager: Destroying surface Surface(name=Starting com.google.fuchsia.armadillo) called by com.android.server.wm.WindowStateAnimator.destroySurface:2014 com.android.server.wm.WindowStateAnimator.destroySurfaceLocked:881 com.android.server.wm.WindowState.destroyOrSaveSurface:2073 com.android.server.wm.AppWindowToken.destroySurfaces:363 com.android.server.wm.WindowStateAnimator.finishExit:565 com.android.server.wm.WindowStateAnimator.stepAnimationLocked:491 com.android.server.wm.WindowAnimator.updateWindowsLocked:303 com.android.server.wm.WindowAnimator.animateLocked:704
01-10 10:47:23.981  3841 21801 I Icing   : Indexing done DDBD0DEF07769388B09FC9B4321A6BC5EFD04345
01-10 10:47:27.288 18771 18771 I GrammarCompilationSvcCt: #startService for null, APP_NAMES.
01-10 10:47:27.320 18771 22764 I ContextCompilationHandl: Compiling grammar for: en-US, type=APP_NAMES
01-10 10:47:27.597  3841 22081 I Icing   : Query from com.google.android.googlequicksearchbox package restrict com.google.android.gms start 0 num 1000
01-10 10:47:27.662  3841 21801 I Icing   : Usage reports 0 indexed 0 rejected 0 imm upload true
01-10 10:47:27.711  3841 21801 I Icing   : Usage reports 0 indexed 0 rejected 0 imm upload true
01-10 10:47:27.831 18771 22764 I ContextCompilationHandl: Recognition context unchanged for APP_NAMES en-US
01-10 10:47:28.558   186   202 E hwc-drm-compositor-worker: Failed to squash all -114
01-10 10:47:29.230  3841  3850 W SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/com.google.android.gms/databases/metrics.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.
01-10 10:47:29.236  3841  3850 W SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/com.google.android.gms/databases/help_responses.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.
01-10 10:47:29.241  3841  3850 W SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/com.google.android.gms/databases/auto_complete_suggestions.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.
01-10 10:47:29.248  3841  3850 W SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/com.google.android.gms/databases/metrics.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.
01-10 10:47:29.251  3841  3850 W SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/com.google.android.gms/databases/help_responses.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.
01-10 10:47:29.255  3841  3850 W SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/com.google.android.gms/databases/auto_complete_suggestions.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.
01-10 10:47:32.373   590   590 I DownloadManagerWrapper: onReceive() : Charging = true
01-10 10:47:32.918   186   202 E hwc-drm-compositor-worker: Failed to squash all -114
01-10 10:47:37.671 18959 19009 I Finsky  : [6765] com.google.android.finsky.d.g.run(1151): Replicating app states via AMAS.
01-10 10:47:37.674   504   561 I WifiHAL : Got channel list with 11 channels
01-10 10:47:37.675   504   561 I WifiHAL : Got channel list with 9 channels
01-10 10:47:37.676   504   561 I WifiHAL : Got channel list with 15 channels
01-10 10:47:37.691 22727 22749 F libc    : Fatal signal 11 (SIGSEGV), code 128, fault addr 0x0 in tid 22749 (ui_thread)
01-10 10:47:37.695   167   167 W         : debuggerd: handling request: pid=22727 uid=10115 gid=10115 tid=22749
01-10 10:47:37.745 18959 19009 I Finsky  : [6765] com.google.android.finsky.d.e.a(313): Completed 0 account content syncs with 0 successful.
01-10 10:47:37.745 18959 18959 I Finsky  : [1] com.google.android.finsky.services.j.a(148): Installation state replication succeeded.
01-10 10:47:37.769 22785 22785 E         : debuggerd: process stopped due to unexpected signal 27
01-10 10:47:37.770   167   167 W         : debuggerd: resuming target 22727
01-10 10:47:37.770   504 22786 W ActivityManager:   Force finishing activity com.google.fuchsia.armadillo/org.domokit.sky.shell.SkyActivity
01-10 10:47:37.770   504   522 I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
01-10 10:47:37.777   184   184 E lowmemorykiller: Error writing /proc/22727/oom_score_adj; errno=22
01-10 10:47:37.781 22788 22788 E crash_dispatcher: Failed to read. errno = 0
01-10 10:47:37.824   504  6722 I OpenGLRenderer: Initialized EGL, version 1.4
01-10 10:47:37.824   504  6722 D OpenGLRenderer: Swap behavior 2
01-10 10:47:37.830   504   515 E JavaBinder: !!! FAILED BINDER TRANSACTION !!!  (parcel size = 68)
01-10 10:47:37.836   504   516 I WindowManager: WIN DEATH: Window{7983de1 u0 com.google.fuchsia.armadillo/org.domokit.sky.shell.SkyActivity}

If you can add /data/tombstones/tombstone_05 (or the text of it) we can help you debug.  We also need to know your flutter version or flutter engine version so we can symbolicate:
https://github.com/flutter/engine/wiki/Symbolicating-production-crash-stacks

Closing as not actionable. Please file a new bug if there still is an issue!