AWS EKS with Calico CNI causing istio-pilot discovery is not ready

Bug description
My case is very similar to #12308.
The environment itself is similar to this, using Calico CNI, but I use AWS EKS. I already set IP in IP to Never as @Miouge1 does,  but it is still not working as expected.
I use Calico CNI instead of AWS VPC CNI to overcome Maximum Pod Issue.
Pods status:
NAME                                      READY   STATUS                       RESTARTS   AGE     IP               NODE                                              NOMINATED NODE   READINESS GATES
grafana-6dcbf89649-8zrwd                  0/1     CreateContainerConfigError   0          4h9m    <IP_ADDRESS>   ip-10-10-48-187.ap-southeast-1.compute.internal   <none>           <none>
istio-citadel-64c48497d8-2lp47            1/1     Running                      0          4h9m    <IP_ADDRESS>   ip-10-10-3-120.ap-southeast-1.compute.internal    <none>           <none>
istio-galley-74dbfbfc76-tl9mh             1/1     Running                      0          4h9m    <IP_ADDRESS>   ip-10-10-83-1.ap-southeast-1.compute.internal     <none>           <none>
istio-ingressgateway-6466646686-qgp7d     1/2     Running                      0          4h9m    <IP_ADDRESS>   ip-10-10-83-1.ap-southeast-1.compute.internal     <none>           <none>
istio-init-crd-10-1.4.2-jjpwj             0/1     Completed                    0          4h10m   <IP_ADDRESS>      ip-10-10-73-114.ap-southeast-1.compute.internal   <none>           <none>
istio-init-crd-11-1.4.2-shsc9             0/1     Completed                    0          4h10m   <IP_ADDRESS>   ip-10-10-83-1.ap-southeast-1.compute.internal     <none>           <none>
istio-init-crd-14-1.4.2-p95wj             0/1     Completed                    0          4h10m   <IP_ADDRESS>    ip-10-10-69-179.ap-southeast-1.compute.internal   <none>           <none>
istio-pilot-754d58dc7f-4l28r              1/2     Running                      2          4h9m    <IP_ADDRESS>      ip-10-10-73-114.ap-southeast-1.compute.internal   <none>           <none>
istio-policy-86bf94b9b5-qngjs             1/2     CrashLoopBackOff             93         4h9m    <IP_ADDRESS>   ip-10-10-38-106.ap-southeast-1.compute.internal   <none>           <none>
istio-sidecar-injector-84bb6c6695-ccvvs   1/1     Running                      0          4h9m    <IP_ADDRESS>      ip-10-10-73-114.ap-southeast-1.compute.internal   <none>           <none>
istio-telemetry-6c55cc74f8-s4vsk          1/2     CrashLoopBackOff             91         4h9m    <IP_ADDRESS>    ip-10-10-69-179.ap-southeast-1.compute.internal   <none>           <none>
kiali-65887977f7-p7pdw                    1/1     Running                      0          4h9m    <IP_ADDRESS>   ip-10-10-3-120.ap-southeast-1.compute.internal    <none>           <none>
prometheus-7c848697c8-8dkhv               1/1     Running                      0          4h9m    <IP_ADDRESS>   ip-10-10-83-1.ap-southeast-1.compute.internal     <none>           <none>

helm-istio-values.yml
global:
  proxy:
    resources:
      requests:
        cpu: 20m
        memory: 64Mi
gateways:
  istio-ingressgateway:
    sds:
      enabled: true
grafana:
  enabled: true
  image:
    tag: 6.5.2
prometheus:
  enabled: true
  tag: v2.12.0
  retention: 30d
kiali:
  enabled: true

istio-pilot discovery logs
2019-12-31T07:11:57.226931Z	info	mcp	(re)trying to establish new MCP sink stream
2019-12-31T07:11:57.227015Z	error	mcp	Failed to create a new MCP sink stream: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp: lookup istio-galley.istio-system.svc on <IP_ADDRESS>:53: read udp <IP_ADDRESS>:46903-><IP_ADDRESS>:53: i/o timeout"
2019-12-31T07:11:57.309378Z	info	Configuration not synced: first push for [istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/security/v1beta1/authorizationpolicies istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries] not received
2019-12-31T07:11:57.409391Z	info	Configuration not synced: first push for [istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs] not received
2019-12-31T07:11:57.509385Z	info	Configuration not synced: first push for [istio/security/v1beta1/authorizationpolicies istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings] not received
2019-12-31T07:11:57.609389Z	info	Configuration not synced: first push for [istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies] not received
2019-12-31T07:11:57.709369Z	info	Configuration not synced: first push for [istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/networking/v1alpha3/destinationrules istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies istio/config/v1alpha2/httpapispecs istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/gateways istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/virtualservices] not received
2019-12-31T07:11:57.809376Z	info	Configuration not synced: first push for [istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings] not received
2019-12-31T07:11:57.909379Z	info	Configuration not synced: first push for [istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars] not received
2019-12-31T07:11:58.009384Z	info	Configuration not synced: first push for [istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs] not received
2019-12-31T07:11:58.109349Z	info	Configuration not synced: first push for [istio/security/v1beta1/authorizationpolicies istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings] not received
2019-12-31T07:11:58.209371Z	info	Configuration not synced: first push for [istio/config/v1alpha2/httpapispecs istio/rbac/v1alpha1/clusterrbacconfigs istio/security/v1beta1/authorizationpolicies istio/networking/v1alpha3/gateways istio/networking/v1alpha3/serviceentries istio/mixer/v1/config/client/quotaspecs istio/authentication/v1alpha1/policies istio/rbac/v1alpha1/servicerolebindings istio/networking/v1alpha3/virtualservices istio/networking/v1alpha3/envoyfilters istio/networking/v1alpha3/sidecars istio/networking/v1alpha3/destinationrules istio/config/v1alpha2/httpapispecbindings istio/mixer/v1/config/client/quotaspecbindings istio/authentication/v1alpha1/meshpolicies istio/rbac/v1alpha1/serviceroles istio/rbac/v1alpha1/rbacconfigs] not received

istio-pilot Pod Events
Events:
  Type     Reason     Age                     From                                                      Message
  ----     ------     ----                    ----                                                      -------
  Warning  Unhealthy  73s (x2999 over 4h11m)  kubelet, ip-10-10-73-114.ap-southeast-1.compute.internal  Readiness probe failed: HTTP probe failed with statuscode: 503

istio-telemetry Pod Events
Events:
  Type     Reason     Age                  From                                                      Message
  ----     ------     ----                 ----                                                      -------
  Warning  Unhealthy  40m (x53 over 75m)   kubelet, ip-10-10-69-179.ap-southeast-1.compute.internal  Liveness probe failed: Get http://<IP_ADDRESS>:15014/version: dial tcp <IP_ADDRESS>:15014: connect: connection refused
  Warning  BackOff    39s (x323 over 74m)  kubelet, ip-10-10-69-179.ap-southeast-1.compute.internal  Back-off restarting failed container

istio-policy Pod Events
Events:
  Type     Reason     Age                 From                                                      Message
  ----     ------     ----                ----                                                      -------
  Warning  Unhealthy  40m (x52 over 74m)  kubelet, ip-10-10-38-106.ap-southeast-1.compute.internal  Liveness probe failed: Get http://<IP_ADDRESS>:15014/version: dial tcp <IP_ADDRESS>:15014: connect: connection refused
  Warning  BackOff    7s (x323 over 74m)  kubelet, ip-10-10-38-106.ap-southeast-1.compute.internal  Back-off restarting failed container

Calico IP Pool
calicoctl get ippool -o wide
NAME                  CIDR            NAT    IPIPMODE   VXLANMODE   DISABLED   SELECTOR
default-ipv4-ippool   <IP_ADDRESS>/16   true   Never      Never       false      all()

Expected behavior
Istio working as expected, same as before implementing Calico CNI
Steps to reproduce the bug

Delete (or use node affinity on) daemonset/aws-node
Install Calico from with manifest from here
Install istio from helm from this guide

Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
kubectl version
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:23:26Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.9-eks-c0eccc", GitCommit:"c0eccca51d7500bb03b2f163dd8d534ffeb2f7a2", GitTreeState:"clean", BuildDate:"2019-12-22T23:14:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

helm version
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

How was Istio installed?
Install with Helm and Tiller via helm install
Environment where bug was observed (cloud vendor, OS, etc)

Istio version: 1.4.2
Calico version: v3.11
Orchestrator version: AWS EKS 1.14.7
OS version: Amazon Linux 2 (Linux 4.14.146-119.123.amzn2.x86_64)

The error is from pilot not being able to connect to galley. From the error
lookup istio-galley.istio-system.svc on <IP_ADDRESS>:53: read udp <IP_ADDRESS>:46903-><IP_ADDRESS>:53: i/o timeout" this looks like you may have some DNS issues in your cluster.

@puzzloholic
do you resovle it?

@puzzloholic
it seems that you may have some DNS issues in your cluster. Could you test the network?


Enable GitHub Discussions

As the title says. Here is documentation.
My actual need is to understand, why for this package it is impossible/impractical to make Windows installation "simple"; or how to make it simple (without WSL and Docker). All other DBT-Bigquery-VSCode extensions I use can work without a "complicated" setup. Together they could have done all the same Wizard package claims to be able to do, but they are dispersed and impossible to tune to work simultaneously (because of fixed file associations).
Further note: it seems the problem is with rpc, which is necessary to query BQ Servers. But BigQuery Runner minodisk.bigquery-runner which extra hustle.

@pgrivachev, thanks for the reply!
I see dbt-rpc (not reliable?) and ZetaSQL (not now, but in TBD) are the cause. What unique functionality do they provide that cannot be achieved using Windows-compatible substitutes? It seemed to me that there are packages for everything DBT Wizard provides, but not under one roof (and that causes great friction in a work process)

@Gregory108,
We use dbt-rpc to run dbt commands, on Windows we can use dbt CLI for this purpose and we will work on it soon. ZetaSQL is used for analyzing SQL query, for highlighting errors in query, for column suggestions and so on.

Hey @Gregory108!
We released v0.7.0 which have support Windows but in limited mode without ZetaSQL.

Hi @pgrivachev!
Thank you so much! You buuuurn! I will test it as soon as I can=)

Now we support all functionality for BQ on Windows. It is only requried to install WSL and Ubuntu-20.04 (updated docs):
wsl --install -d Ubuntu-20.04


BIG HACK

There is large-scale hack that is destroying sandspiel. Please fix it

There is someone that is spamming with the Polish flag


Add PolymorphicComponentProps

Adds a collection of generic types to help create strongly typed Polymorphic Components.
This came up while creating a Polymorphic component(which was easy) and then having to define types without knowing in advance which element was going to be the basis (which was a hassle). These types should make the process less of a chore.

I'm not extremely seasoned in writing tests for this particular kind of utility, but I would hazard that we'd need to test:

Compare two examples of a Polymorphic Component's types using a different as value and find them not equal.
Use invalid props for a given as and have it fail.

Input would be most appreciated.


Unable to remove failed "agents"

I have some agents that are no longer running in the mesos cluster but they are still showing up in the mesos UI commonly found at 5050.  I would like to delete them but I cannot.  Can someone suggest where to  start looking to see what piece of software is broken.

I believe this is same as https://github.com/jenkinsci/mesos-plugin/issues/226


macOS applications fail to open

After packaging a mac app with the Deploy script, it successfully creates an app. When trying to open the app, it immediately closes itself with no error. The Console simply reports
com.apple.xpc.launchd[1] (Launcher.35004[17163]): Service exited with abnormal code: 127

For the newest Mono, the path needs to be set within Deploy.sh:
echo "# Set new Mono path" >> temp
echo "export PATH=\$PATH:/Library/Frameworks/Mono.framework/Versions/Current/bin/" >> temp


Add graphQL endpoint template resolve as in graphiql controller.

Hello! I added url templating for graphQL endpoint as in graphiql controller.

Thanks for the contribution!


wrapper_class not working for select's

hey there,
  = f.date_select :start_time, wrapper: { class: 'has-warning', data: { foo: 'bar' } }  <-- not working
  = f.text_field :description, wrapper: { class: 'has-warning', data: { foo: 'bar' } }  <-- works

Thanks!

There is something diffrent for the two calls. For the FIELD_HELPERS (text_field) form_group_builder(name, options) do and DATE_SELECT_HELPERS (date_select) form_group_builder(name, options, html_options) do.
The correct call for you should be = f.date_select :start_time,{}, wrapper: { class: 'has-warning', data: { foo: 'bar' } }

Aii.... so it was probably a RTFM on my part. Mea culpa! Thanks for the solution!


Fix crash when try torch.cuda.set_device in worker

The new usage status collector add vllm.model_executor.model_loader import which cause transformers start to init the context with the cuda environment which hasn't configured by _init_workers_ray@RayGPUExecutor with set_cuda_visible_devices func yet.
So that with wrong context inited, it would cause crash when we use tp > 1 case.
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44] Error executing method init_device. This might cause deadlock in distributed execution. (RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44] Traceback (most recent call last):
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44]   File "/data/dev/vllm/vllm/engine/ray_utils.py", line 37, in execute_method
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44]     return executor(*args, **kwargs)
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44]   File "/data/dev/vllm/vllm/worker/worker.py", line 91, in init_device
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44]     torch.cuda.set_device(self.device)
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44]   File "/usr/local/lib/python3.10/dist-packages/torch/cuda/init.py", line 404, in set_device
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44]     torch._C._cuda_setDevice(device)
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44] RuntimeError: CUDA error: invalid device ordinal
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44] CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44] For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
(RayWorkerVllm pid=515753) ERROR 04-01 15:42:25 ray_utils.py:44] Compile with TORCH_USE_CUDA_DSA to enable device-side assertions.
FILL IN THE PR DESCRIPTION HERE
FIX #xxxx (link existing issues this PR will resolve)
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

@leiwen83  FYI: We pinned to this version of ray (2.9.3) instead of using 2.10.0, and it worked for us (https://github.com/vllm-project/vllm/pull/3699).

@WoosukKwon @simon-mo I wonder why the test tests/distributed/test_basic_distributed_correctness.py in CI did not catch the problem?

I was able to replicate this issue running CUDA_VISIBLE_DEVICES=0,1 TEST_DIST_MODEL=facebook/opt-125m pytest -s -v tests/distributed/test_basic_distributed_correctness.py. I am also confused why this wasn't caught in CI
Running right before this fix, I can show that test_basic_distributed_correctness.py hangs/fails quickly:
> git checkout main~1
> CUDA_VISIBLE_DEVICES=0,1 TEST_DIST_MODEL=facebook/opt-125m pytest -s -v tests/distributed/test_basic_distributed_correctness.py
====================================================================================================================== test session starts =======================================================================================================================
platform linux -- Python 3.10.12, pytest-8.0.0, pluggy-1.4.0 -- /home/michael/venvs/vllm/bin/python3
cachedir: .pytest_cache
rootdir: /home/michael/code/vllm
plugins: anyio-4.2.0
collected 1 item

tests/distributed/test_basic_distributed_correctness.py::test_models[5-half-facebook/opt-125m] huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
2024-04-02 19:09:04,234 INFO worker.py:1724 -- Started a local Ray instance.
INFO 04-02 19:09:05 llm_engine.py:75] Initializing an LLM engine (v0.4.0) with config: model='facebook/opt-125m', tokenizer='facebook/opt-125m', tokenizer_mode=auto, revision=None, tokenizer_revision=None, trust_remote_code=True, dtype=torch.float16, max_seq_len=1024, download_dir=None, load_format=auto, tensor_parallel_size=2, disable_custom_all_reduce=True, quantization=None, enforce_eager=False, kv_cache_dtype=auto, device_config=cuda, seed=0)
(raylet) [2024-04-02 19:09:13,176 E<PHONE_NUMBER>29] (raylet) file_system_monitor.cc:111: /tmp/ray/session_2024-04-02_19-09-01_184666_907017 is over 95% full, available space:<PHONE_NUMBER>92; capacity:<PHONE_NUMBER>104. Object creation will fail if spilling is required.
INFO 04-02 19:09:13 selector.py:51] Cannot use FlashAttention because the package is not found. Please install it for better performance.
INFO 04-02 19:09:13 selector.py:25] Using XFormers backend.
(RayWorkerVllm pid=913486) INFO 04-02 19:09:13 selector.py:51] Cannot use FlashAttention because the package is not found. Please install it for better performance.
(RayWorkerVllm pid=913486) INFO 04-02 19:09:13 selector.py:25] Using XFormers backend.
INFO 04-02 19:09:13 pynccl_utils.py:45] vLLM is using nccl==2.18.1
(RayWorkerVllm pid=913486) INFO 04-02 19:09:13 pynccl_utils.py:45] vLLM is using nccl==2.18.1
INFO 04-02 19:09:15 weight_utils.py:177] Using model weights format ['*.bin']
(RayWorkerVllm pid=913486) INFO 04-02 19:09:15 weight_utils.py:177] Using model weights format ['*.bin']
INFO 04-02 19:09:16 model_runner.py:104] Loading model weights took 0.1185 GB
(RayWorkerVllm pid=913486) INFO 04-02 19:09:16 model_runner.py:104] Loading model weights took 0.1189 GB
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44] Error executing method profile_num_available_blocks. This might cause deadlock in distributed execution.
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44] Traceback (most recent call last):
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/engine/ray_utils.py", line 37, in execute_method
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return executor(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return func(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/worker/worker.py", line 131, in profile_num_available_blocks
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     self.model_runner.profile_run()
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return func(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/worker/model_runner.py", line 742, in profile_run
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     self.execute_model(seqs, kv_caches)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return func(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/worker/model_runner.py", line 663, in execute_model
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     hidden_states = model_executable(**execute_model_kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self._call_impl(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return forward_call(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/model_executor/models/opt.py", line 301, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     hidden_states = self.model(input_ids, positions, kv_caches,
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self._call_impl(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return forward_call(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/model_executor/models/opt.py", line 276, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self.decoder(input_ids, positions, kv_caches, attn_metadata)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self._call_impl(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return forward_call(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/model_executor/models/opt.py", line 250, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     hidden_states = layer(hidden_states, kv_caches[i], attn_metadata)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self._call_impl(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return forward_call(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/model_executor/models/opt.py", line 158, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     hidden_states = self.self_attn(hidden_states=hidden_states,
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self._call_impl(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return forward_call(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/model_executor/models/opt.py", line 102, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     attn_output = self.attn(q, k, v, kv_cache, attn_metadata)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1518, in _wrapped_call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self._call_impl(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1527, in _call_impl
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return forward_call(*args, **kwargs)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/attention/layer.py", line 46, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return self.impl.forward(query, key, value, kv_cache, attn_metadata)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/attention/backends/xformers.py", line 258, in forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     output = self._run_memory_efficient_xformers_forward(
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/code/vllm/vllm/attention/backends/xformers.py", line 335, in _run_memory_efficient_xformers_forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     out = xops.memory_efficient_attention_forward(
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/xformers/ops/fmha/__init__.py", line 244, in memory_efficient_attention_forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return _memory_efficient_attention_forward(
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/xformers/ops/fmha/__init__.py", line 337, in _memory_efficient_attention_forward
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     op = _dispatch_fw(inp, False)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/xformers/ops/fmha/dispatch.py", line 120, in _dispatch_fw
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     return _run_priority_list(
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/xformers/ops/fmha/dispatch.py", line 53, in _run_priority_list
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     not_supported = op.not_supported_reasons(inp)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/xformers/ops/fmha/decoder.py", line 41, in not_supported_reasons
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     reasons = super(FwOp, cls).not_supported_reasons(d)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/xformers/ops/fmha/common.py", line 304, in not_supported_reasons
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     device_capability = torch.cuda.get_device_capability(d.device)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/cuda/__init__.py", line 435, in get_device_capability
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     prop = get_device_properties(device)
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]   File "/home/michael/venvs/vllm/lib/python3.10/site-packages/torch/cuda/__init__.py", line 452, in get_device_properties
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44]     raise AssertionError("Invalid device id")
(RayWorkerVllm pid=913486) ERROR 04-02 19:09:17 ray_utils.py:44] AssertionError: Invalid device id
(raylet) [2024-04-02 19:09:23,188 E<PHONE_NUMBER>29] (raylet) file_system_monitor.cc:111: /tmp/ray/session_2024-04-02_19-09-01_184666_907017 is over 95% full, available space:<PHONE_NUMBER>36; capacity:<PHONE_NUMBER>104. Object creation will fail if spilling is required.

Running with this change on main, it works fine:
> git checkout main
> CUDA_VISIBLE_DEVICES=0,1 TEST_DIST_MODEL=facebook/opt-125m pytest -s -v tests/distributed/test_basic_distributed_correctness.py
====================================================================================================================== test session starts =======================================================================================================================
platform linux -- Python 3.10.12, pytest-8.0.0, pluggy-1.4.0 -- /home/michael/venvs/vllm/bin/python3
cachedir: .pytest_cache
rootdir: /home/michael/code/vllm
plugins: anyio-4.2.0
collected 1 item

tests/distributed/test_basic_distributed_correctness.py::test_models[5-half-facebook/opt-125m] huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
        - Avoid using `tokenizers` before the fork if possible
        - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
2024-04-02 19:10:08,058 INFO worker.py:1724 -- Started a local Ray instance.
INFO 04-02 19:10:09 llm_engine.py:74] Initializing an LLM engine (v0.4.0) with config: model='facebook/opt-125m', tokenizer='facebook/opt-125m', tokenizer_mode=auto, revision=None, tokenizer_revision=None, trust_remote_code=True, dtype=torch.float16, max_seq_len=1024, download_dir=None, load_format=auto, tensor_parallel_size=2, disable_custom_all_reduce=True, quantization=None, enforce_eager=False, kv_cache_dtype=auto, device_config=cuda, seed=0)
INFO 04-02 19:10:13 selector.py:51] Cannot use FlashAttention because the package is not found. Please install it for better performance.
INFO 04-02 19:10:13 selector.py:25] Using XFormers backend.
(RayWorkerVllm pid=921495) INFO 04-02 19:10:15 selector.py:51] Cannot use FlashAttention because the package is not found. Please install it for better performance.
(RayWorkerVllm pid=921495) INFO 04-02 19:10:15 selector.py:25] Using XFormers backend.
INFO 04-02 19:10:15 pynccl_utils.py:45] vLLM is using nccl==2.18.1
(RayWorkerVllm pid=921495) INFO 04-02 19:10:15 pynccl_utils.py:45] vLLM is using nccl==2.18.1
INFO 04-02 19:10:17 weight_utils.py:177] Using model weights format ['*.bin']
(RayWorkerVllm pid=921495) INFO 04-02 19:10:17 weight_utils.py:177] Using model weights format ['*.bin']
(raylet) [2024-04-02 19:10:18,005 E<PHONE_NUMBER>99] (raylet) file_system_monitor.cc:111: /tmp/ray/session_2024-04-02_19-10-06_009742_915090 is over 95% full, available space:<PHONE_NUMBER>68; capacity:<PHONE_NUMBER>104. Object creation will fail if spilling is required.
INFO 04-02 19:10:18 model_runner.py:104] Loading model weights took 0.1185 GB
(RayWorkerVllm pid=921495) INFO 04-02 19:10:18 model_runner.py:104] Loading model weights took 0.1189 GB
INFO 04-02 19:10:19 ray_gpu_executor.py:240] # GPU blocks: 152793, # CPU blocks: 0
INFO 04-02 19:10:19 model_runner.py:791] Capturing the model for CUDA graphs. This may lead to unexpected consequences if the model is not static. To run the model in eager mode, set 'enforce_eager=True' or use '--enforce-eager' in the CLI.
INFO 04-02 19:10:19 model_runner.py:795] CUDA graphs can take additional 1~3 GiB memory per GPU. If you are running out of memory, consider decreasing `gpu_memory_utilization` or enforcing eager mode. You can also reduce the `max_num_seqs` as needed to decrease memory usage.
(RayWorkerVllm pid=921495) INFO 04-02 19:10:19 model_runner.py:791] Capturing the model for CUDA graphs. This may lead to unexpected consequences if the model is not static. To run the model in eager mode, set 'enforce_eager=True' or use '--enforce-eager' in the CLI.
(RayWorkerVllm pid=921495) INFO 04-02 19:10:19 model_runner.py:795] CUDA graphs can take additional 1~3 GiB memory per GPU. If you are running out of memory, consider decreasing `gpu_memory_utilization` or enforcing eager mode. You can also reduce the `max_num_seqs` as needed to decrease memory usage.
INFO 04-02 19:10:23 model_runner.py:867] Graph capturing finished in 4 secs.
(RayWorkerVllm pid=921495) INFO 04-02 19:10:23 model_runner.py:867] Graph capturing finished in 4 secs.
Processed prompts: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 8/8 [00:00<00:00, 79.99it/s]
PASSED

======================================================================================================================== warnings summary ========================================================================================================================
tests/distributed/test_basic_distributed_correctness.py::test_models[5-half-facebook/opt-125m]
  /home/michael/venvs/vllm/lib/python3.10/site-packages/torch/_utils.py:831: UserWarning: TypedStorage is deprecated. It will be removed in the future and UntypedStorage will be the only storage class. This should only matter to you if you are using storages directly.  To access UntypedStorage directly, use tensor.untyped_storage() instead of tensor.storage()
    return self.fget.__get__(instance, owner)()

tests/distributed/test_basic_distributed_correctness.py::test_models[5-half-facebook/opt-125m]
  /home/michael/venvs/vllm/lib/python3.10/site-packages/ray/_private/pydantic_compat.py:2: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
    from pkg_resources import packaging

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
================================================================================================================= 1 passed, 2 warnings in 21.46s =================================================================================================================

Based on @hongxiayang's comment above, it may be due to a different version of Ray being used in the CI workers?


Add version injection at build time

/assign @hopkiw

/gobuild

/gobuild

looks good except for one variable needs pruning or updating. thanks


Regenerate IDR PNG logos with transparent background

Also generate a white version of the logo as used in presentations
The SVG files are unchanged but the PNG files have been regenerated with transparent background (to facilitate the embedding e.g. in presentations) and a white version of the PNG, similar to the ones used in the header of the standard IDR slides has been created.
NB: I am parallely starting to look into managing the sources and the generation of the raster image (see https://github.com/sbesson/artwork and https://github.com/sbesson/artwork/actions/runs/1414246457). I currently envision modifications to the logos would be release assets of the artwork repository and could be consumed in this repository (and others). I am happy to take any suggestions on tying (or not) both efforts.

https://github.com/sbesson/artwork is probably now in a state where it can be reviewed:

sources (SVG versions) are kept under version control
PNG versions are generated with a transparent background (ImageMagick 7/OSX)
a build script generates all PNGs and creates 3 zips (OME, OME products, IDR)
GHA runs the builds and creates artifacts for each PR and create a release with assets on tag - see https://github.com/sbesson/artwork/releases/tag/2021.11.16

If we are happy with this approach, I'd propose to migrate the repo to the ome org, recreate a release to test the process and update the zips in this repository with official release assets.

Happy with the approach
The PNGs look good
Outwith this PR:

I could imagine some of them with white or black backgrounds
I could almost imagine as well having them unzipped for hot-linking but an alternative would be to have a single page that consumes all of them in some re-usable display

Cheers. I'll leave another day for comments and then go ahead with the repo transfer.

Outwith this PR:
I could imagine some of them with white or black backgrounds
I could almost imagine as well having them unzipped for hot-linking but an alternative would be to have a single page that consumes all of them in some re-usable display

Proposing to capture these as issues/RFE. For the second one, I assume https://www.openmicroscopy.org/artwork/ could become this page and give access either to bundles (like https://github.com/logos) and/or individual files (like https://git-scm.com/downloads/logos). There might be a case for generating another release artifact with all the logos (SVG + PNG) that could easily be extracted here.

Proposing to capture these as issues/RFE.

:+1:
Also: https://calibreapp.com/blog/compress-images-in-prs

I'll leave another day for comments and then go ahead with the repo transfer.

:+1:

Sorry I completely missed this PR. Things look good. Include in the next deployment?

Re-reading the thread, I think there are two issues which conflated and put this  on hold:

the generation of PNG with transparent background
the management of the SVG sources for all our logos/icons

The latter is still  waiting on a decision regarding the licensing.
The former should be ready to go although looking at it again, it raises the question of whether we would want to generate both types of PNG (white background and transparent background) and use a suffix to differentiate them.

Sorry for letting this slip. Concentrating on the former, my ordering would be:

All (e.g. here)
Just transparent
Whatever else

But since this is currently in place with the second best choice, I'm happy to get it in and we can go from there. Thanks, @sbesson!


tests(readme): Use skeptic to test the readme

This can't actually be merged in until serde_json 0.7 can be released.

:umbrella: The latest upstream changes (presumably a84b6aa) made this pull request unmergeable. Please resolve the merge conflicts.

Why is this test added in serde_macros instead of serde_tests?


[WARN] Cannot find rule of module

Hello,thanks for your excellent job . But，there is a warning i don‘t understand.
what is the rule of module ? Can you give an example how to use it in individual module.
WARN:
[WARN] Cannot find rule for <class 'net.model.DC_blocks'>. Treat it as zero Macs and zero Params.
ps(DC_blocks is my model )

This means there is no count rule for net.model.DC_blocks as it is defined by 3rd party / yourself. By default, the FLOPs of such modules is the summation of all child modules.

Hi, I encounter the same problem. Does it mean that the final FLOPs include my defined module? Is it OK to just ignore the warning?

@Mhaiyang Yes, it is safe (in most cases) to ignore the warning. I will improve the log to make users more comfortable : )

@Lyken17 Thanks!

@Lyken17

This means there is no count rule for net.model.DC_blocks as it is defined by 3rd party / yourself. By default, the FLOPs of such modules is the summation of all child modules.

Sorry, but I am still confused about this warning. As you suggested, it is ok that the module is not recognizable. And the default rule to calculate is to take sum for all the child modules. But is there any risk to cause wrong calculation?


fix: ValueError target column of train dataframe has NaN or Inf.

@AkiraUra
Raises an error if there are more than a certain number of nan or inf value rows in the target column of the training data.
This PR is a part of the following PRs.

core: fix/target_column_has_nan_or_inf
loaddata: fix/target_column_has_nan_or_inf

Please take a review on it.

@AkiraUra
We have taken additional measures based on the following PR.

https://github.com/sapientml/core/pull/55

This fix assumes that you have applied the following changes:

https://github.com/sapientml/core/pull/67


Implement USDS "official government website" super banner

Describe the solution you'd like
In order to continue to build trust with applicants and TIs, we want to confirm with users that the CiviForm website is an official government website of their city or state. To help do this, we are going to implement the USDS official government website component / super banner.
Done when
This issue is done when the banner and it's expanded view are complete and @sijiayam confirms that the implementation matches the design here: https://www.figma.com/file/RmhVJCLgAKWGENJLWWAtNS/CiviForm%3A-Components%2C-Styles?type=design&node-id=807-4205&mode=design&t=aycLkjlVarJCp8Dn-0 and below:

As a super banner, it is always visible on every view.

@sijiayam will link to the component

@melanie-exygy I have updated the figma link as well attached a zeroheight documentation link with colors.
Let me know if that works for you/any outstanding questions

@sijiayam and I discussed that adding the banner brings out some design debt that we should address in separate issues.  Two design debt problems are:

We need a full page container which includes the header and footer and which has a max-width that is less wide than we have now.  There should be space on both sides when in a wide view.  A good example is  seattle.gov.
Admin and applicant facing pages should have a consistent look, especially for the nav.  For example, the logo should be the same and the nav in both views should either be fixed or not fixed.  Right now, it is not fixed in the applicant-facing pages and fixed on the admin pages.


URDF links as frames in the scene graph

Hi,
I'm combining URDF and .robray files. I would like to define a frame in robray with its parent being a link in the URDF file. If I use the link name of URDF it doesn't work.
I guess my more general question is: how is URDF transformed into frames of the scene graph?
Thanks!

Alright, figured it out. It's the joint name.


feat: Add billing email to checkout for receipt

This commit passes the billing email to the checkout endpoint on backend. This allows the backend to send the email receipt to the specified billing email.
[SCSE-107]
Related: ntuscse/be#41

DO NOT MERGE: Converting to draft as ntuscse/be#40 affects the name of the field to pass the email in.

This change has been completed by d661e20.


Merge Ta2json into Master

[x] run branch locally
[x] look at basic functionality: subset, transform, model

Note: to revert back to rook mode, at the top of src/app.js, set var d3m = false;

e.g. this brings back the fearonlaitin data


Rancher 1.2.0 - TLS handshake timeout github access control

Rancher Version:
1.2.0
Docker Version:
1.12.3
OS and where are the hosts located? (cloud, bare metal, etc):
I have tried with ubuntu 16.04 and CentOS 7
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
internal db
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
none
Steps to Reproduce:
start the rancher contianer and try to add the github integration
Results:
I am getting errors like this during start of rancher:
time="2016-12-05T20:41:16Z" level=error msg="Error processing event" err="Get https://github.com/packethost/docker-machine-driver-packet/releases/download/v0.1.2/docker-machine-driver-packet_linux-amd64.zip: net/http: TLS handshake timeout" eventId=a1eacac7-f046-48ca-9876-732fd7985539 eventName="machinedriver.activate;handler=goMachineService-machine" resourceId=1md1

and this when I am trying to add the github access control:
time="2016-12-05T20:46:41Z" level=error msg="Received error from github: Post https://github.com/login/oauth/access_token: net/http: TLS handshake timeout"
time="2016-12-05T20:46:41Z" level=error msg="Github getAccessToken: GET url https://github.com/login/oauth/access_token received error from github, err: Post https://github.com/login/oauth/access_token: net/http: TLS handshake timeout"
time="2016-12-05T20:46:41Z" level=error msg="Error generating accessToken from github Post https://github.com/login/oauth/access_token: net/http: TLS handshake timeout"
time="2016-12-05T20:46:41Z" level=error msg="GetToken failed with error: Post https://github.com/login/oauth/access_token: net/http: TLS handshake timeout"
2016-12-05 20:46:41,843 ERROR [:] [] [] [] [tp1830712962-15] [.a.a.i.e.ExternalServiceAuthProvider] Got error from Auth service. statusCode: 500

Expected:
github integration should successfully be added.

GitHub Authentication works fine here. As you are also experiencing this with the download of a machine driver, are you sure it's not on your network end? Seems like a unstable internet connection /proxy/firewall situation?

hmm, I just tried to spin up a new machine without any firewall or restrictions on the internet connection. I still got the TLS handshake issues. So that did not help. Any more suggestions on what to try?
@superseb what os and which docker version are u running?

hmm..it did work locally on my laptop (OSX). So it might be the underlying OS or the internet connection since I am running my laptop on a different network.

Just tried on AWS with Ubuntu 16.04 and Docker 1.12.3. Where are your hosts running?

Hmm..I am running on a openstack provider called citycloud. If i do docker exec -ti <container-id> bash and then do a curl to the url that is timing out everything seems to work just fine. So I dont think it is the network.
Are you running the latest, stable or v1.2.0 tag? I am running the v1.2.0 tag.

Maybe some certificate issues? Does anyone know if there is a way of getting more detailed information about the error? Like enabling debug or something.

Seems to be some kind of issue with the ca-certificates. If I did the following everything seems to work (at least for CentOS7):
sudo docker run -d -v /etc/pki/tls/certs/ca-bundle.crt:/etc/ssl/certs/ca-certificates.crt:ro --restart=unless-stopped --name rancher rancher/server:v1.2.0

I close this one, seems like @superseb where correct. I recreated the whole network-stack at our openstack provider and now everything seems to work. ⛈


cmd/go: applying swig's %go_import directive to non-builtin packages is not supported

One of swig's useful language-specific directives for the Go language is %go_import.  It allows defining typemaps and wrappers (with "%insert(go_wrapper)"), among others, using symbols defined in a user-defined package found under $GOPATH/src.  However, the go build system only allows %go_import of builtin packages.  User-defined packages are not accessible in the temporary workspace which go creates to build a package that uses swig interface files.
The following, while not really interfacing with any C/C++ library, demonstrates this problem.  It's using go1.7 on darwin/amd64.  But this problem is seen on all platforms.
The first attempt at making and executing the main package at swig-sandbox/import relies on the go build system's support for swig.  It fails.  The second attempt is made after invoking swig manually (removing *.swigcxx to prevent the go build system to also try to invoke swig).  It succeeds, obviously.
bash-3.2$ [ $GOPATH/src/swig-sandbox/import == $PWD ] && echo 'We are at swig-sandbox/import in Go sources directory'
We are at swig-sandbox/import in Go sources directory
bash-3.2$ ls -R
.:
main.i  main.swigcxx  mytime  printNextYear.go
./mytime:
consts.go
bash-3.2$ head *.{i,swigcxx,go} /.go
==> main.i <==
%go_import("fmt", c "swig-sandbox/import/mytime")
%insert(go_wrapper) %{
func myprint(a ...interface{}) {
fmt.Print("[myprint] ")
fmt.Println(a...)
}
func nextYear() uint {
return c.Year + 1
}
==> main.swigcxx <==
%include "main.i"
==> printNextYear.go <==
package main
func main() {
myprint("Next year is:", nextYear())
}
==> mytime/consts.go <==
package consts
const Year uint = 2016
bash-3.2$ go build -o main && ./main
# swig-sandbox/import
/tmp/go-build726259823/swig-sandbox/import/_obj/main.go:40: can't find import: "swig-sandbox/import/mytime"
bash-3.2$ rm main.swigcxx
bash-3.2$ swig -go -cgo -intgosize 64 -module main main.i
bash-3.2$ go build -o main && ./main
[myprint] Next year is: 2017
bash-3.2$
As can be seen, the workaround is to not use *.swigcxx files and instead do a two-step compilation -- explicitly invoke swig and then use go build.  But it's desirable to have the go build system to call swig.  Note also that %go_import of "fmt" was fine.  It was the %go_import of "swig-sandbox/import/mytime", a user-defined package, that was problematic.

A more tangible example showing why %go_import is useful follows.  (This is partly for clarification and partly in response to a comment received on issues #18339 where the utility of the use case was questioned.)
Consider two C++ libraries, one whose declarations are exported in the header foo.hpp and another in bar.hpp.  Consider further that bar.hpp uses symbols from foo.hpp.  In the following example, foo.hpp defines an enum called state and bar.hpp defines a predicate IsUp on that enum.  It's desirable to wrap each of these libraries in a separate go package and be able to import them in another package and have the go bindings work in a similar way to how they would be used in a C/C++ program (see the imports in go/test/main.go and the call to b.IsUp).
The first version of the bar package simply wraps bar.hpp which results in the enum to become a type different than the same enum wrapped in the foo package (bar.State vs. foo.State), and as such, the program fails to compile in type-checking the call to b.IsUp.
The second version of the bar package maps the enum to the State type defined in the foo package, allowing the program to type-check correctly.  However, this can only be done by explicitly invoking swig and not relying on the go build system's support for swig.
If one wants to avoid the two-step build, one has to wrap both foo.hpp and bar.hpp in a single package, say foo_and_bar, with a swig file that %includes both headers.  But that's also undesirable because a package that only needs bindings of symbols from one header would have to import bindings from the other header too.  Good programmers really need %go_import to achieve proper abstractions and modularity in their code, and therefore support for it in the go build system is highly desired.
bash-3.2$ BUGREPT=swig-sandbox/bug-reports/go-swig/go_import
bash-3.2$ cd $GOPATH/src/$BUGREPT
bash-3.2$ find -E cpp -type f -iregex '.*.(h|hpp|cpp)' -print0 | xargs -0 head
==> cpp/include/bar.hpp <==
#pragma once
#include "foo.hpp"
static inline bool isUp(enum state s) {
  return(s == UP);
}
==> cpp/include/foo.hpp <==
#pragma once
enum state { UP, DN };
bash-3.2$ find -L -E go -type f -iregex '.*.(go|swigcxx)' -print0 | xargs -0 head -n20
==> go/bar/bar.swigcxx <==
%{
#include "bar.hpp"
%}
%include "bar.hpp"
==> go/bar/package.go <==
package bar
// #cgo CXXFLAGS: -I${SRCDIR}/../../cpp/include
import "C"
==> go/foo/foo.swigcxx <==
%{
#include "foo.hpp"
%}
%include "foo.hpp"
==> go/foo/package.go <==
package foo
// #cgo CXXFLAGS: -I${SRCDIR}/../../cpp/include
import "C"
==> go/test/main.go <==
package main
import (
	"log"
	b "swig-sandbox/bug-reports/go-swig/go_import/go/bar"
	f "swig-sandbox/bug-reports/go-swig/go_import/go/foo"
)
func main() {
	if !b.IsUp(f.UP) {
		log.Fatal("f.UP is not up!")
	}
	log.Println("A-OK")
}
bash-3.2$ go install $BUGREPT/go/test
# swig-sandbox/bug-reports/go-swig/go_import/go/test
go/test/main.go:10: cannot use foo.UP (type foo.State) as type bar.State in argument to bar.IsUp
bash-3.2$ head go/bar/bar.swigcxx
%{
#include "bar.hpp"
%}
%go_import(f "swig-sandbox/bug-reports/go-swig/go_import/go/foo")
%typemap(gotype) enum state "f.State"
%include "bar.hpp"
bash-3.2$ go install $BUGREPT/go/test
# swig-sandbox/bug-reports/go-swig/go_import/go/bar
/var/folders/m6/8y6rbg4s2td16l0z7f1pm1_c0000gn/T/go-build810351302/swig-sandbox/bug-reports/go-swig/go_import/go/bar/_obj/bar.go:40: can't find import: "swig-sandbox/bug-reports/go-swig/go_import/go/foo"
bash-3.2$ cd go/bar
bash-3.2$ ls -l
total 24
-rw-r--r--  1 hormozzarnani  staff  148 Dec 15 21:27 bar.i
lrwxr-xr-x  1 hormozzarnani  staff    5 Dec 15 21:01 bar.swigcxx -> bar.i
-rw-r--r--  1 hormozzarnani  staff   72 Dec 15 20:14 package.go
bash-3.2$ rm bar.swigcxx
bash-3.2$ swig -go -cgo -intgosize 64 -c++ -I../../cpp/include -module bar bar.i
bash-3.2$ ls -l
total 40
-rw-r--r--  1 hormozzarnani  staff  1534 Dec 15 21:29 bar.go
-rw-r--r--  1 hormozzarnani  staff   148 Dec 15 21:27 bar.i
-rw-r--r--  1 hormozzarnani  staff  6972 Dec 15 21:29 bar_wrap.cxx
-rw-r--r--  1 hormozzarnani  staff    72 Dec 15 20:14 package.go
bash-3.2$ tail bar.go
}
func IsUp(arg1 f.State) (_swig_ret bool) {
	var swig_r bool
	_swig_i_0 := arg1
	swig_r = (bool)(C._wrap_isUp_bar_7f645dbcfef3df15(C.swig_intgo(_swig_i_0)))
	return swig_r
}
bash-3.2$ go install $BUGREPT/go/test
bash-3.2$ $GOPATH/bin/test
2016/12/15 21:30:53 A-OK
bash-3.2$

I agree it would be nice to fix this problem.
Although I haven't tested it, I think that another workaround would be to run go install swig-sandbox/import/mytime before trying to build swig-sandbox/import.  That is, the problem is not that the package can not be found.  The problem is that the go tool does not see the dependency between the packages, because the go tool only looks at .go files to determine import dependencies.
Yet another workaround would be to modify some .go file in the directory to say
import _ "sandbox/import/mytime"

I'm not sure how to actually fix this problem, because a proper fix would require the go tool to parse the .swig file.  It seems to me that fully correct parsing of a .swig file requires implementing the C preprocessor and requires parsing some C or C++ code to distinguish the SWIG directives from other code in the file.  SWIG uses a yacc parser with the comment "This file is a bit of a mess and probably needs to be rewritten at some point.  Beware."  I don't really foresee the go tool incorporating its own version of the SWIG parser.
One plausible approach might be to add an option to SWIG to essentially dump the list of go_imports.  Then the go tool could invoke SWIG with that option and use that to get the list of dependencies.  I'm not sure whether or not that is a good idea, since it means that go get would behave differently on different systems based on whether SWIG was installed or not.

Putting 'import _ "user/def/pkg"' in some go file is a good workaround.  Thanks.
I'm sure there are reasons for go build working this way, but I think the go build system should first run swig to generate go files and then proceed to the normal build as if swig isn't present.   That way, a package could simply contain an interface file and still build (but today the build fails with the "no buildable source files" error)


VS Code breakpoints ignored during "amplify mock function"

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
14.15.5
Amplify CLI Version
4.45.2
What operating system are you using?
Windows 10
Amplify Categories
function
Amplify Commands
Not applicable
Describe the bug
I recently updated to the latest Amplify CLI, from version 4.17.2. Before the update, when I used amplify function invoke [functionName] from launch.json, I was able to set/hit break points in Visual Studio Code. Following the upgrade, when I run the debugger in VS Code using amplify mock function [functionName], breakpoints are ignored and the code runs to completion. I know the code is executing correctly because I'm seeing expected output written to the console.
I'm currently making use of this workaround from cjihrig: https://github.com/aws-amplify/amplify-cli/issues/1158#issuecomment-801195432
Expected behavior
When running amplify mock function in VS Code debugger, execution halts on breakpoints and allows interrogation of runtime variables, etc.
Reproduction steps

Create a Lambda function via Amplify CLI. Mine were created using v4.17.2, if that matters. Lambda node runtime version is nodejs12.x
Add configuration to launch.json to mock function (example below).
In VS Code, set a breakpoint inside Lambda's handler in index.js.
Run the new configuration from "Run and Debug" tab in VS Code.
Function runs to completion without hitting any breakpoints.

Log output
# Put your logs below this line

launch.json:
{
      "type": "node",
      "request": "launch",
      "name": "myFunction",
      "env": {
        "ENV": "mySandbox",
        "REGION": "my-region-9000",
      },
      "program": "someFolder/amplify",
      "args": [
        "mock",
        "function",
        "myFunction"
      ],
      "console": "integratedTerminal"
    },

I'd been using the solution proposed by  @cjihrig in https://github.com/aws-amplify/amplify-cli/issues/1158#issuecomment-800782576_

For Node.js lambda functions, you can use the inspector module in your code as a workaround:
require('inspector').open(9229, '<IP_ADDRESS>', true);
debugger;

This will start the debugger on port 9229 and wait for you to connect. You'll want to make sure:

The mock run is started with a long enough timeout to give you time to you debug.
This code is removed before shipping to a cloud environment.

This stopped working probably after upgrade to amplify-cli version 8. Now the amplify mock command doesn't use the Node installed in the system, but runs its custom runtime (supposedly to mimic the AWS Lambda environment as closely as possible) - you can see it in the example below, I have node 16 installed and mock uses node 14.
However, the Amplify-provided runtime does not offer the inspector module and throws and error:
PS C:\Users\Adam Kučera\dev\dnytra\dreamroi-recommender\amplify\backend\function\productupdater\test> node --version
v16.13.1
PS C:\Users\Adam Kučera\dev\dnytra\dreamroi-recommender\amplify\backend\function\productupdater\test> amplify mock function productupdater --event ./src/event.json --timeout 100
Ensuring latest function changes are built...
Starting execution...
Started!
Starting inspector... Waiting for debugger to attach on port 9229
v14.18.1
productupdater failed with the following error:
{
  stack: 'Error [ERR_INSPECTOR_NOT_AVAILABLE]: Inspector is not available\n' +
    '    at new NodeError (internal/errors.js:322:7)\n' +
    '    at inspector.js:25:9\n' +
    '    at NativeModule.compileForInternalLoader (internal/bootstrap/loaders.js:286:7)\n' +
    '    at NativeModule.compileForPublicLoader (internal/bootstrap/loaders.js:226:10)\n' +
    '    at loadNativeModule (internal/modules/cjs/helpers.js:40:9)\n' +
    '    at Function.Module._load (internal/modules/cjs/loader.js:772:15)\n' +
    '    at Module.require (internal/modules/cjs/loader.js:974:19)\n' +
    '    at Module.require (pkg/prelude/bootstrap.js:1719:31)\n' +
    '    at require (internal/modules/cjs/helpers.js:93:18)\n' +
    '    at initDebug (C:\\Users\\Adam Kučera\\dev\\dnytra\\dreamroi-recommender\\amplify\\backend\\function\\productupdater\\src\\index.js:48:9)',
  message: 'Inspector is not available',
  code: 'ERR_INSPECTOR_NOT_AVAILABLE'
}
Finished execution.

The code that throws the error:
console.log('Starting inspector... Waiting for debugger to attach on port 9229');
console.log(process.version);
require('inspector').open(9229, '<IP_ADDRESS>', true);

Is there any workaround with this ? Being able to debug the Amplify lambdas from my local machine (with pdb for Python or inspector for node) seems like a pretty strong requirement. How is this a P4 ???

current workaround for me:

create debug.js file inside .vscode folder with the following code inside

const { handler } = require("../amplify/backend/function/yourFunctionNameHere/src/index");
const event = require("../amplify/backend/function/yourFunctionNameHere/src/testEvents/event1.json");

(async function(){
    const response = await handler(event)
    console.log(response)
})()

add this config to your .vscode/launch.json file:

  {
      "name": "Debug Amplify Function",
      "program": "${workspaceFolder}/.vscode/debug.js",
      "request": "launch",
      "skipFiles": ["<node_internals>/**"],
      "type": "pwa-node",
      "console": "externalTerminal",
      "env": {
        "AWS_REGION": "eu-west-1"
      }
    }

Be sure to add any env variables needed for the lambda to run under "env". Note: if lambda is using aws4 keys you either need to have aws profile set with them under '~/.aws/credentials/` and use '@aws-sdk/credential-provider-node' to get them or pass them as env variables which is not recommended due to security. (never commit aws4 keys to github!)

Set a breaking point and run the debugger.

It is nasty because handler and event are both hardcoded and need to be changed for diffferent scenarios but at least you can debug locally without console.log on each new line 🤣

Hello to everyone who are on this topic. It has been few years now, since we started using amplify as a backbone to our products and back in the time, there was a working solution on how to do REAL inline step debugging with VS Code. At the time, we had to develop a complex layer on top of our custom resolvers which wouldn't be possible without the ability to inspect the process internally.
Ever since amplify cli changed the way it spawns the child process that call the resolver in the appropriate context, while running locally, I feel like I lost both of my hands. It has been a real pain to keep the dev performing the same as before.
Finally, it has been two days, since I hit an impossible to trace issue in our code base, for which I desperately needed a way to inspect (in real scenario) the code, running on my machine with a debugger...
Following everything that I have read so far during the last two years, including the last 30 hours of non sleep, had finally resulted in the following 100% working solution to get the job done.
First, I had recently configured my localhost to point to local ip v6 address. It was the main reason, that I had to clone the entire amplify cli source and build it my self, so that reverse engineering it, I found out that there is lower communication layer for the dynamodb emulator, that cannot handle the ip v6 (hopefully yet!).
This was the moment that I finally figured out where does this package amplify-nodejs-function-runtime-provider comes from and where it goes to. Basically, this is the layer that receives the mocked context from the local dev server and instantiates a spawned process from the dev server, emulating a serverless way of cold starting our resolver.
It became clear, after inspecting closer this comment  that even tough the code has changed, it should be possible to send --inspect argument to the spawned process, to which we could later attach with remote debugger. So:

Remove your currently installed amplify cli from your global node modules.
git clone https://github.com/aws-amplify/amplify-cli.git and optionally checkout your preferred version tag/branch
cd amplify-cli&&yarn
Edit amplify-cli/packages/amplify-nodejs-function-runtime-provider/src/utils/invoke.ts at line 6 as follows

After I experimented with execa, it turned out that the first argument to execa.node is the first argument passed to the node process where the next argument of array, are the every next argument that should be passed to the spawned process. Unfortunately, adding the --inspect param to the arguments list after the executable file does not work, that is how I ended switching their places.
--inspect and --inspect-brk can be used, depending on your preference of testing, you have to understand, the the --inspect-brk will make the process wait for the debugger to connect, before it proceeds with execution. This gives you the ability to debug async requests in sync way, one after another, because the port can't be used for more than one instance of the resolve at a time.

You can also add some basic logic, check env variable and change the parameters for example, just so you dont need to recompile the cli every time.
So far, so good, run yarn setup-dev and leave it for few minutes. It will compile the whole cli. Keep in mind, if you make more changes, you must run yarn clean before running yarn setup-dev again.
Create two files in your local .vsconfig folder as follows

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "cli:run",
        "type": "node",
        "preLaunchTask": "runAmplifyHost"
      },
      {
        "name": "cli:attach",
        "type": "node",
        "request": "attach",
        "port": 9229,
        "restart": true
      },
    ],
    "compounds": [
      {
        "name": "amplify:debbug",
        "configurations": ["cli:run", "cli:attach"]
      },
    ]
  }

{
   "version": "2.0.0",
   "tasks": [
     {
       "type": "shell",
       "command": "node <PATH TO YOUR AMPLIFY CLI REPO/amplify-cli/packages/amplify-cli/bin/amplify mock api --timeout 30",
       "problemMatcher": [],
       "label": "runAmplifyHost",
       "isBackground": true,
     },
   ]
 }

in the tasks.json file, replace the command place holder with the path of your cli build

Hope it helps you as well :)

@fakedob Looks like you worked really hard to get that solution. But it appears to require monkey patching amplify and implementing a non-standard setup, which can cause all sorts of problems down the line.
I think we need the amplify CLI to support this natively instead so I'm adding my voice to this issue. Step-through debugging greatly increases development speed compared to using console.log on everything. Here's hoping the amplify devs can raise the priority of this!


ignite config redux

Renames IgniteTicketRegistryConfiguration @Component annotation and moves configuration of that class to boot.

This passes all tests and should be correct, but I get strange errors when I try to use it.
Caused by: org.springframework.beans.ConversionNotSupportedException: Failed to
convert value of type [java.lang.String] to required type [org.apache.ignite.cac
he.CacheAtomicityMode]; nested exception is java.lang.IllegalStateException: Can
not convert value of type [java.lang.String] to required type [org.apache.ignite
.cache.CacheAtomicityMode]: no matching editors or conversion strategy found

I just found ignite-spring. It should help clean this up a bunch. I'll give it a shot tomorrow.

Sounds good. Let me know if you need any help.

This looks like it's ready.
Do we need to update the docs?
Do we need to update the app.properties?
I know this is targeted towards letsboot. Could I ask you to target it against master? I can live it with it as is, and cherry pick it over to master.

I haven't had a chance to work on this in a while. There are/were some bugs somewhere in 5.0.0-SNAPSHOT that prevent this from working right just yet. This is currently setup for spring boot as well. I'll take a look shortly and provide an update.


[For Discussion] Current key upload validation does not prevent mass upload of keys for a single day period.

In going through discussions with various legal/policy folks, I opined that there may be some loopholes in our upload path that were open given our preference to prioritize privacy.
One that seems to have come up is the ability to upload 28 keys for a single RSIN (day) period.
There is currently a check for overlapping / dupe RSIN's https://github.com/cds-snc/covid-shield-server/blob/ba42406661a651050e8e85aae36d4ddd4a0ba8f7/pkg/server/upload.go#L258 however, it is trivially bypassed by uploading keys one at a time, as we do not have any method to track other than 'remainingKeys'.
Initial idea is to create a simple upload/rsin map, something along the lines of "100100111100.." representing upload on day 1, 4, 7,8,9, 10 .... This in theory does not break the privacy guarantees of having the diagnosis keys unassociated with a single entity in the encryption keys table, but it potentially does reduce it, so we'll hold on any implementation until we understand and can weigh the two attack vectors accordingly.

cc: @burke Thoughts?

My thought process here was that if a user obtains an OTC and wants to use it maliciously, one way or another, they'll eventually get to insert 28 keys into the database. I didn't think there was a whole lot of difference in whether those would be all one day or correctly distributed, especially since correct behaviour would be up to 14ish keys on day zero.

This issue requires a story definition to align on the outcomes, acceptance criteria and approach.


update reliable

Codecov Report

Merging #59 into release-rc2 will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release-rc2      #59   +/-   ##
==============================================
  Coverage          37.39%   37.39%
  Complexity           127      127
==============================================
  Files                 46       46
  Lines               1214     1214
  Branches              75       76    +1
==============================================
  Hits                 454      454
  Misses               743      743
  Partials              17       17

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73e277e...3b76bc3. Read the comment docs.


Allow Gmail filters to work in newly backed-up SMS

I was wanting to forward new SMS backups to another email address so I thought I'd set up a gmail filter to forward emails however something in the way that the app stores backups on Gmail seems to bypass gmail filters. When I manually run the filter it works.
Hopefully this is a feature request, and not a user error on my part.

I can confirm this bug. I have setup filter that skips call logs and sms email-s from Inbox, but smsbackup+ emails are not filtered, so i have to run this filter manually every week.
If it is not an easy task to apply gmail filters to smsbackup+ emails, it would be great to have "Skip Inbox" option in app.


Production Release - October 7th 2024

What does this PR do?

Create a Production build from the main branch

[x] I have verified that I am promoting the main branch, and not another development branch

What are the Trello stories being promoted in this release (please link)?

https://trello.com/c/aWplWDoO/49-move-space-to-its-own-repository

Infrastructure Changes

[x] Relevant environment variables (and s3 uploads) have been updated before deployment

 Move /space to it's own repository


General Type Refactor

CoordinateTransformations.jl
Remove obtuse parameterizations

Right now we are not using coordinate transforms, but I have implemented context specific transform types.


Grouping different layers of ShapeSource using SymbolLayer

I have a problem with ShapeSource clusterization using SymbolLayer. I have several layers and I want them to look like independent icons. But when it comes to layer overlapping some part of my icons(layer) overlaps others as shown in the screenshot.

The best solution I've found now is to add marker images with stars as one image but solution is pretty hucky and it will be much harder to maintain.

So the question or request for the feature: is there a possibility to group several layers as one that acts as an independent element on the map? So on clusterization grouped layers will be treated as one.
I'm pretty much satisfied with the abilities ShapeSource provides but I really need such behavior I've described above if it's not possible can you please provide me with some alternatives that may be used? I was thinking about MarketView but I'm not sure whether I will be able to implement clusterization.

Pls move this to discussions. Also I'm not sure I understand what you want to achieve. Not sure what layers are on your picture. Not sure if the issue is about blue starts not being in front, or it's about black and red icons overlapping or just overlap of red icons. Also clustering is a feature of symbol layer, are you referring to that?!  https://docs.mapbox.com/mapbox-gl-js/example/cluster/, or you mean something else?


[SPARK-40924][SQL][3.3] Fix for Unhex when input has odd number of symbols

What changes were proposed in this pull request?

Fix for a bug in Unhex function when there is an odd number of symbols in the input string.
This is backport of #38402
Why are the changes needed?

Unhex function and other functions depending on it (e.g. ToBinary) produce incorrect output.
Does this PR introduce any user-facing change?

No
How was this patch tested?

Unit tests

All GAs passed:

Merging to 3.3. Thank you, @vitaliili-db.


More strict parsing of hostname (authority) part of URLs

Applies to emails, plain domains URLs (e.g. example.com/foo) and URLs with schemes where a host is expected (e.g. https).
This fixes a few problems that have been reported over time, namely:

https://www.example..com is no longer parsed as an URL (#41)
<EMAIL_ADDRESS>is no longer parsed as an email address (#29)
https://*.example.org is no longer parsed as an URL (#38)

It's a tricky change and hopefully this solves some problems while not introducing too many new ones. If anything unexpectedly changed for you, please let us know!

As a nice side effect of this change, the benches have improved as well, 15% for some (comparing 9a6ce3981003b2140a16eda863ded477bf1488f0 with 5bfb5167340e0436cd7d1b74f7d4997c58cec9e2):
no_links                time:   [25.885 ns 25.892 ns 25.901 ns]
                        change: [-2.2092% -2.0791% -1.9485%] (p = 0.00 < 0.05)
                        Performance has improved.

some_links              time:   [314.23 ns 314.37 ns 314.54 ns]
                        change: [-2.6413% -2.1750% -1.7947%] (p = 0.00 < 0.05)
                        Performance has improved.

heaps_of_links          time:   [1.0488 us 1.0502 us 1.0515 us]
                        change: [-14.292% -14.133% -13.997%] (p = 0.00 < 0.05)
                        Performance has improved.

some_links_without_scheme
                        time:   [389.63 ns 390.09 ns 390.54 ns]
                        change: [-15.163% -15.040% -14.905%] (p = 0.00 < 0.05)
                        Performance has improved.

Thanks for your work and congratulations to the new release.


go1.4 compile error in Mac OS 10.11

When I try to install Go 1.4 via gvm, I get a compile error.
Trace
$ gvm install go1.4
Installing go1.4...
 * Compiling...
ERROR: Failed to compile. Check the logs at /Users/andrew/.gvm/logs/go-go1.4-compile.log
ERROR: Failed to use installed version

$ cat /Users/andrew/.gvm/logs/go-go1.4-compile.log
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, darwin/amd64.
lib9
libbio
liblink
cmd/cc
cmd/gc
cmd/6l
cmd/6a
cmd/6c
/Users/andrew/.gvm/gos/go1.4/src/cmd/6c/txt.c:995:28: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value]
/Users/andrew/.gvm/gos/go1.4/src/cmd/6c/txt.c:1045:28: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value]
go tool dist: FAILED: clang -Wall -Wstrict-prototypes -Wextra -Wunused -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -Wuninitialized -O2 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -mmacosx-version-min=10.6 -c -m64 -I /Users/andrew/.gvm/gos/go1.4/include -I /Users/andrew/.gvm/gos/go1.4/src/cmd/6c -o /Users/andrew/.gvm/gos/go1.4/pkg/obj/cmd/6c/txt.o /Users/andrew/.gvm/gos/go1.4/src/cmd/6c/txt.c

System
$ gvm version
Go Version Manager v1.0.22 installed at /Users/andrew/.gvm

$ clang --version
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ system_profiler SPSoftwareDataType | grep 'System Version'
      System Version: OS X 10.11.6 (15G31)

Workaround
$ gvm install go1.4 --binary

Same issue for me. The workaround works for now.
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool for host, darwin/amd64.
lib9
libbio
liblink
cmd/cc
cmd/gc
cmd/6l
cmd/6a
cmd/6c
/Users/xo/.gvm/gos/go1.4/src/cmd/6c/txt.c:995:28: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value]
/Users/xo/.gvm/gos/go1.4/src/cmd/6c/txt.c:1045:28: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value]
go tool dist: FAILED: clang -Wall -Wstrict-prototypes -Wextra -Wunused -Wno-sign-compare -Wno-missing-braces -Wno-parentheses -Wno-unknown-pragmas -Wno-switch -Wno-comment -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe -Wuninitialized -O2 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -mmacosx-version-min=10.6 -c -m64 -I /Users/xo/.gvm/gos/go1.4/include -I /Users/xo/.gvm/gos/go1.4/src/cmd/6c -o /Users/xo/.gvm/gos/go1.4/pkg/obj/cmd/6c/txt.o /Users/xo/.gvm/gos/go1.4/src/cmd/6c/txt.c

Have you tried compiling without CGO_ENABLED?
CGO_ENABLED=0 gvm install go1.4

Just run into the same problem and CGO_ENABLED=0 gvm install go1.4, unfortunately, doesn't help!

@mcandre try this:
gvm install go1.4 -B

@mindworker Yep, the binary option works around the issue on my machine.

I've only got success when using --binary

Well the --binary was working yesterday, but now I have no working option...

gvm install go1.12 --binary # don't install go1.4


vscode-lldb packages are now called codelldb

Starting with version 1.5.0 the needed packages of the vscode-lldb project of vadimcn are called codelldb-*.
lldb.json needs to be updated to reflect this.

Fixed in #60


Julia for Charge Transport in Condensed Matter | Jürgen Fuhrmann | JuliaCon2021

Julia for Charge Transport in Condensed Matter, https://www.youtube.com/watch?v=plJKkBES69I
This video is not even 2 minutes long, but as showcase I made some timestamps.
00:00 Welcome!
00:20 Charge transport in condensed matter
00:57 Showcase of VoronoiFVM.jl package for Voronoi Finite Volume Method

Added, thanks!


But there are so much bug and I always mess up something, so it'd be useful.

You can assign this to me. I will try to raise my PR in the coming weeks.
I will use pytest.

I've added a bunch of test in the new main branch, but all of them feel like an afterthought. Maybe we should move to TDD.


New version: Jackett.Jackett version 0.22.656

Pull request has been created with WinGet Releaser :rocket:
Microsoft Reviewers: Open in CodeFlow

🔥

Automatic Validation ended with:

Installation failed with exit code -1978335187
2024-09-20 22:55:41.704 [FAIL] Installer failed security check. Url: https://github.com/Jackett/Jackett/releases/download/v0.22.656/Jackett.Installer.Windows.exe Result: 0x80004005

Automated error analysis suggests -1978335187 may mean Installer failed security check. Another script should retry this every 18 hours.
Automated error analysis suggests 80004005 may mean Resource missing
(Automated response - build 896.)

@wingetbot run


📝[Docs]:  add data_fetcher.py

What Docs changes are you proposing?
To handle live market data fetching from various APIs.
Why do the Docs need this improvement? What is the motivation for this change? How will this change benefit the community?
Functions to connect to data providers, fetch real-time data, and handle errors.
Describe the solution you'd like
Provide a clear and concise description of the changes you'd like to see implemented in the documentation.
Describe alternatives you've considered
If you've thought about alternative approaches or solutions, briefly describe them here.
Additional context
Add any additional context, examples, or screenshots related to the proposed documentation changes.

add this file in risk assessment

I can add all the changes through one pull request

please assign me the issue

add a issue and PR of 1 project, not individual files

Yeah I will do that


Add safety check for 'production' to Jenkinsfile

As per https://github.com/GoogleCloudPlatform/continuous-deployment-on-kubernetes/issues/91

FYI @viglesiasce


Update requirements.txt

Affected versions of this package are vulnerable to Sandbox Bypass in split_region in uc.c.
Upgrade unicorn to version 2.0.0rc5 or higher.

Change based on https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44078

Change comitted


con.execute doesn't necessarily return proper dtype

Update: filed internally as https://jira.omnisci.com/browse/BE-3467 for decimal downcast
When using the execute method to return a list of tuples, the following types lose precision:

~double downcast to float~ EDIT: python float is actually double precision for modern platforms
decimal downcast to float (https://github.com/omnisci/pymapd/issues/212)

In the case of integers, columns are returned as int, which is the system word size int, which is probably okay. For smaller width ints on OmniSci, this is ok, since there is no precision loss. Might be unexpected though to have a tinyint column return a 32- or 64-bit int column.
Bool is returned as 1/0, which is conventionally correct, but odd since Python itself has True/False
Modifying these behaviors are necessarily a breaking change, but in the case of losing precision, it seems like the correct thing to do.

Per https://docs.python.org/3/tutorial/floatingpoint.html:

Why is that? 1/10 is not exactly representable as a binary fraction. Almost all machines today (November 2000) use IEEE-754 floating point arithmetic, and almost all platforms map Python floats to IEEE-754 “double precision”. 754 doubles contain 53 bits of precision, so on input the computer strives to convert 0.1 to the closest fraction it can of the form J/2**N where J is an integer containing exactly 53 bits. Rewriting

Closing this in lieu of #212 for decimal issues. Bool and Int issues are moot I think, if someone else brings them up then we can revisit.


Smooth transitions for useZoomPanHelper using built-in d3 functions

Smooth transitions were a highly requested feature for react-flow that could be implemented using external libraries like popmotion or tween.js, but this approach is a bit messy since you need to use the reactFlowRef and change its internal viewport directly.
There are some built-in functions in D3.js that can help with smooth transitions without using any external libraries.
I've refactored the useZoomPanHelper hook functions to use d3 transitions and added the corresponding examples to /examples/UseZoomPanHelper directory.
I've also added an optional duration argument to the zoomIn, zoomOut, zoomTo, transform, fitView, setCenter and fitBounds functions to help the user to change the duration of d3 transitions.
By default, all the functions above have a 300ms transition, but their animations can be disabled by setting their duration to 0.
Here is the UseZoomPanHelper example with zoomIn set to 1200ms, zoomOut set to 0 and setCenter set to the default value of 300ms:
https://user-images.githubusercontent.com/17250923/142758194-8c296261-bbe6-45ad-a0dd-52e35fde1e47.mp4

In case anyone wonders why transitions are implemented in such a way:
const getTransition = (selection: D3Selection<Element, unknown, null, undefined>, duration: number = 300) => {
  return selection.transition().duration(duration);
};

return {
// ...
  zoomIn: (duration?: number) => d3Zoom.scaleBy(getTransition(d3Selection, duration), 1.2),
  zoomOut: (duration?: number) => d3Zoom.scaleBy(getTransition(d3Selection, duration), 1 / 1.2),
  zoomTo: (zoomLevel: number, duration?: number) =>
          d3Zoom.scaleTo(getTransition(d3Selection, duration), zoomLevel),
// ...
}

and not like this:
const animatedSelection = d3Selection.transition().duration(300);

return {
// ...
  zoomIn: (duration?: number) => d3Zoom.scaleBy(animatedSelection , 1.2),
  zoomOut: (duration?: number) => d3Zoom.scaleBy(animatedSelection , 1 / 1.2),
  zoomTo: (zoomLevel: number, duration?: number) =>
            d3Zoom.scaleTo(animatedSelection , zoomLevel),
// ...
}

The answer is: d3 transitions are not reusable and have to be built using a factory function. If you try to reuse a transition, you'll get the following error: Uncaught error: transition not found

@moklick
Do you have any updates/suggestions about this feature?

Looks good to me :) Could you just set the default duration to 0 ?

Yes of course!
I'll create new commit and change it.

nice work!

awesome, thanks!

released in 9.7.0. We will probably change the API a bit in v10 in order to always use an object for the options.


Add HotelTable component

In this PR, we add the HotelTable component for displaying hotels (closes #12).
This depends on #11; perhaps we should rebase this branch after that is merged.

Rebase this branch with main and then LGTM to merge.

Still need to add the storybook page.

LGTM


More phrases missing on the JSON  translation files

As more components are being added, translations are left behind. A lot of phrases are not being updated or added in the JSON translation files. Is there a way of  doing that automatically?

in kofta there was npm run i18 that would add the keys for you and write the eng translation for it

i believe in kibbeh you can run yarn i18 and it should yield a similar result

so kofta or kibbeh?

in kofta npm run i18 and kibbeh yarn i18 should work. should fill out empty feilds for you but obv wont translate them, will just fill them with eng translations

Focusing on kibbeh is smart as it will become the main platform very very soon.

yea we're switching today 100%