Fix: port forwarding in VS Code

[lalver1]

Closes #2642

This PR changes the behavior of the dev container to only auto forward the ports associated with the docs and server services in the compose file. By setting "otherPortsAttributes": { "onAutoForward": "ignore" }, any other ports should not be auto-forwarded at all.

Reviewing

1. Exit your current dev container
2. Switch to this branch
3. Rebuild and reopen the dev container
4. Start the debugger
5. Verify that the app is always reachable from your browser at localhost:DJANGO_LOCAL_PORT/ (open the benefits app, submit the eligibility form, navigate to the admin, etc.) and that the PORTS tab in VS Code always only shows 2 ports, the server and docs ports

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[thekaveman]

I'm still not quite sure about the underlying issue here. I've never experienced the situation described in #2642, and it doesn't seem straightforwardly reproducible (e.g. does it happen that way every single time going through an Agency Card flow?)

In any case, on Linux at least, this change appears to have no effect. I'm still seeing all the various ports on the ports tab:

[machikoyasuda]

I tested this locally on my macOS.

My ports tab looks like this:

I am able to access the server and healthcheck:

And the docs: http://localhost:8001/benefits/

But not the Benefits client app at http://localhost:11369/ after running the debugger. Am I mising something?

[machikoyasuda]

Confirmed on VS Code Insiders (pre-release) 1.97.0-insider. Ran the app in container, opened docs, server and the client. Went through client flow.

[thekaveman]

@machikoyasuda:

But not the Benefits client app at http://localhost:11369/ after running the debugger. Am I mising something?

I'm guessing, but from the screenshot it looks like maybe DJANGO_LOCAL_PORT was not set to 11369?

I would expect that very last entry to have 0.0.0.0:11369 in the Forwarded Address column.

[lalver1]

I added dev:8000 to forwardPorts

  "forwardPorts": ["docs:8001", "server:8000", "dev:8000"],
  "otherPortsAttributes": { "onAutoForward": "ignore" },

but did not quite get the behavior I was expecting:

VS Code did not open extra ports when debugging (that's good) but dev was available at both ports 11369 and 51422. This may be confusing for the dev experience, so I'm leaning to not making changes to this branch.

My guess was that dev would have behaved just like docs and server, but there are 2 differences that may be the reason for this behavior:

1. dev is the dev container service in devcontainer.json ("service": "dev"), somehow making port allocation in the Ports tab different compared to the other services
2. In the compose file, dev is assigned a specific port on the host but docs and server get allocated any unassigned port of the host, and this creates a different behavior in the Ports tab of VS Code

[angela-tran]

So I noticed in your screenshots @lalver1 that you don't have any "Statically forwarded" ports.

In mine, I have two.

I've realized they correspond with the ports being published in compose.yml for dev.

If I comment out ports for dev, they go away. Then, if I start my app through the debugger, I see I can not reach it when I go to http://localhost:11369 in my browser, which makes sense because I'm not forwarding the port from the devcontainer to my host.

(Side note: I'm not sure why I have two since we're just publishing one port, but I guess they are for the same port number, just with different hosts.)

I'm not sure why your VS Code isn't showing you the ports corresponding to the published ports for dev, but clearly they are being forwarded for you since you can reach the app at http://localhost:11369.

[angela-tran]

I was also curious about the "Auto Forwarded" ports that y'all have, and I've learned that "auto-forwarding" is referring to a feature in VS Code where the terminal will detect ports being allocated and set up forwarding for that port.

I didn't find this in any official documentation, but rather from piecing together various comments online:

• Here, someone is asking how the feature works: How does VSCode's terminal autodetect port launched by a process and auto port forward. microsoft/vscode#143958
• Here's another comment confirming that it's a thing: Add setting to disable automatic port fowarding. microsoft/vscode#108346 (comment)
• Someone asking how to turn off auto-forwarded ports: https://stackoverflow.com/questions/65496520/vscode-remote-dev-django-avoiding-forwarding-ports
• Some more info on configuring auto-forward behavior: Remove multiple or all forwarded ports  microsoft/vscode#121780
• Someone asking for reasons for auto-forwarding: https://stackoverflow.com/questions/73741583/why-automatic-port-forwarding-how-to-prevent-vs-code-from-doing-it

I think auto-forwarding is what's happening when we click the Starting development server at http://0.0.0.0:8000/ link in the VS Code terminal and see a new port in the Ports tab.

@lalver1 Maybe the extra port that would show up and cause hanging is from the auto-forwarding feature?

[angela-tran]

I noticed I don't get auto-forwarded ports 🤔 and then I found that in my User Settings, I have it turned off:

I don't remember doing this, but in my Firefox history, I see I searched for "vs code keeps adding auto forwarded port" on June 5, 2024, so maybe I did change it? 🤣

[thekaveman]

Oh this seems relevant too... from that same settings pane:

The "will not be un-forwarded" bit seems like a potential to cause a hang.

[angela-tran]

With what we know now, does @lalver1's solution seem ok? I guess there are multiple places where the behavior can be changed (Settings vs. devcontainer.json)

[thekaveman]

With what we know now, does @lalver1's solution seem ok? I guess there are multiple places where the behavior can be changed (Settings vs. devcontainer.json)

Oh yeah I think it seems OK, but also maybe we should disable this automatic forwarding? Seems like it doesn't matter (you've had it disabled) and it also seems like it could be the source of the some of the problems @lalver1 and @machikoyasuda experience on Mac.