Setting 'Urls' environment variable in kubernetes deployment causes bridge to kubernetes to fail

[Woazboat]

Describe the bug Bridge to Kubernetes debugging fails to connect when the Urls environment variable is set in the target deployment that is supposed to be debugged

Loaded Bridge To Kubernetes environment file 'KubernetesLocalProcessConfig.yaml'.
Waiting for 'dummy-target-d6895b9ff-qzzv2' in namespace 'dummy-namespace' to reach running state...
Deployment 'dummy-namespace/dummy-target' patched to run agent.
Remote agent deployed in container 'dummy-target' in pod 'dummy-target-d6895b9ff-qzzv2'.
Preparing to run Bridge To Kubernetes configured as pod dummy-namespace/dummy-target-d6895b9ff-qzzv2 ...
Connect operation failed.
Stopping workload and cleaning up...
Restore: Deployment 'dummy-target' restored to original state with image 'dummy-image'.
An unexpected error occurred: 'An error occurred while sending the request.'
To see our active issues or file a bug report, please visit https://aka.ms/bridge-to-k8s-report.
For diagnostic information, see logs at '/tmp/Bridge To Kubernetes'.
Failed to establish a connection. Error: Connect operation failed.
An unexpected error occurred: 'An error occurred while sending the request.'
To see our active issues or file a bug report, please visit https://aka.ms/bridge-to-k8s-report.
For diagnostic information, see logs at '/tmp/Bridge To Kubernetes'.

I have previously successfully used the bridge to kubernetes vs code extension to debug the same application in kubernetes. After updating the deployment specification for the application, bridge to kubernetes was no longer able to connect to the remote agent in the pod (which it managed to create successfully).

One of the changes to the deployment was the addition of the Urls environment variable which had not been set before:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dummy-target
spec:
  (...)
  template:
    (...)
    spec:
      containers:
      - image: dummy-image
        name: dummy-target
        env:
          - name: Urls
            value: http://0.0.0.0:1234

After removing the Urls environment variable from the deployment, bridge to kubernetes debugging was able to connect successfully and started to work again.

To Reproduce Create a deployment for a target application that is supposed to be debugged and set the Urls environment variable in the deployment specification.

**Expected behavior** Bridge to kubernetes connection and debugging should work regardless of the environment variable settings of the target deployment. **Logs** [bridge-mindarocli-2021-10-06-15-00-34-629141.txt](https://github.com/microsoft/mindaro/files/7295409/bridge-mindarocli-2021-10-06-15-00-34-629141.txt) [bridge-library-2021-10-06-15-00-35-629141.txt](https://github.com/microsoft/mindaro/files/7295460/bridge-library-2021-10-06-15-00-35-629141.txt) **Environment Details** Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux VS Code mindaro.mindaro@1.0.120210803

[lolodi]

Hi @Woazboat, Thanks for reporting this issue. Definitely an interesting one. I was able to repro it but I'm still not sure of why this specific env variable is causing this issue. I'll report back when I'll know more.

[lolodi]

Hi @Woazboat , It looks like "Urls" is a reserved env variables in ASP.NET Core. When we replace the remote container with our agent, we inherit all the env variables and this specific one is trying to override the port that our agent runs on. If you were to set Urls="http://0.0.0.0:50051" you'll see that everything works again, because that's the port the remote agent runs on. I've opened a task on our end to fix this by removing the env variables that are reserved, when deploying the remote agent, and restoring them back when the workload id restored. I'll update this thread when a fix is ready. In the meantime I'd recommend you use a different env variable to pass the information you need.

[jasase]

Hello any new information regarding this topic?