[bastion] Concurrent tunnel connections overwrite last_token; only last session is cleaned up #10137

Describe the bug

With concurrent local TCP accepts on az network bastion tunnel, each connection requests a Bastion token via POST /api/tokens and stores it in a single instance field self.last_token. When active_connections reaches 0, cleanup() only DELETEs that last token.
Browsers / SOCKS clients that open multiple connections therefore create multiple Bastion active sessions (often with the same start time). After the tunnel stops, earlier sessions can remain visible in getActiveSessions / Portal until idle timeout.

Related command

az network bastion tunnel

Errors

no error but does not close all opened connections

Issue script & Debug output

the script does not error it just doesn't close all sessions

Expected behavior

When I close the tunnel I expect all sessions created to be closed.

Environment Summary

azure-cli 2.88.0

core 2.88.0
telemetry 1.1.0

Extensions:
account 0.2.5
ad 0.1.0
amg 3.0.0
azure-devops 1.0.6
bastion 1.4.3
databricks 1.3.2
datadog 3.0.0
front-door 2.3.0
resource-graph 2.1.1
ssh 2.0.9
stream-analytics 1.0.5

Dependencies:
msal 1.36.0
azure-mgmt-resource 24.0.0

Additional context

Summary

With concurrent local TCP accepts on az network bastion tunnel, each connection requests a Bastion token via POST /api/tokens and stores it in a single instance field self.last_token. When active_connections reaches 0, cleanup() only DELETEs that last token.

Browsers / SOCKS clients that open multiple connections therefore create multiple Bastion active sessions (often with the same start time). After the tunnel stops, earlier sessions can remain visible in getActiveSessions / Portal until idle timeout.

Related

• Concurrent connections were added to fix bastion tunnel does not accept concurrent connections azure-cli#24600 (bastion extension ≥ 1.0.1)
• Adjacent: az network bastion tunnel quietly drops connection azure-cli#28367 (tunnel drop / cleanup races)

Environment

• azure-cli 2.88.0
• bastion extension 1.4.3
• Observed while using a local SOCKS5 proxy through az network bastion tunnel (multiple concurrent local accepts)

Code path (azext_bastion/tunnel.py)

1. Each accept → _handle_client → _get_auth_token() overwrites self.last_token / self.node_id
2. On client exit, when active_connections == 0, cleanup() deletes only self.last_token

So if connections A/B/C obtained tokens T1/T2/T3, only T3 is deleted when the last client leaves. T1/T2 are never deleted by this path.

Steps to reproduce

1. Start az network bastion tunnel to a TCP/SOCKS resource port
2. Open 2–3 concurrent local connections to the local tunnel port (or drive traffic through a browser SOCKS proxy)
3. Check Bastion active sessions (getActiveSessions / Portal) — expect multiple sessions for the same user, same/near start time
4. Stop the tunnel (Ctrl+C / kill the process)
5. Re-check active sessions — earlier sessions may still appear

Expected

All tokens/sessions created by this tunnel process are cleaned up when their connections close and/or when the tunnel process exits.

Ask

Track tokens per connection (or a set of outstanding tokens) and DELETE each on close / process exit, instead of a single overwritten last_token.