starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] headscale nodes approve-routes list-routes -i flag doesn't filter by node ID #1165

New Issue
Closed
opened 2025-12-29 02:28:40 +01:00 by adam · 0 comments
adam commented 2025-12-29 02:28:40 +01:00
Owner
Copy Link

Originally created by @DueFaith on GitHub (Dec 1, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

After updating to the latest version of Headscale, there appears to be a regression in the CLI for route management commands that breaks existing automation and scripts.

When using the -i <node_id> flag with route listing commands, only the routes for the specified node should be returned, similar to how the previous headscale routes list -i <node_id> command worked.

The previous CLI command headscale routes list -i <node_id> -o json correctly filtered output to only show routes for the specified node ID.

Expected Behavior

The new command headscale nodes approve-routes list-routes -i <node_id> -o json ignores the -i flag entirely and returns route information for all nodes in the network, not just the specified node.

Steps To Reproduce

Have a Headscale instance with multiple nodes (subnet routers)
Run: headscale nodes approve-routes list-routes -i 12 -o json
The output contains route information for ALL nodes, not just node ID 12

Environment

- OS: MacOS Sequoia 15.7.2
- Headscale version: v0.27.0-debug
- Tailscale version: 1.80.2
- Deployment method: Podman container

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

Impact on Automation
This issue specifically affects:

Ansible role for subnet router configuration
Scripts that need to verify specific node route configurations
Monitoring systems that check route status per node

The workaround of fetching all nodes and filtering client-side is not feasible for production environments with many nodes due to:

Performance overhead
Security concerns (exposing all node data)
Breaking existing automation that expects node-specific output

Note: This is a CLI-specific issue and does not appear to affect the actual routing functionality - routes work correctly once configured. The issue is purely with the management interface returning unfiltered results.

Originally created by @DueFaith on GitHub (Dec 1, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior After updating to the latest version of Headscale, there appears to be a regression in the CLI for route management commands that breaks existing automation and scripts. When using the `-i <node_id>` flag with route listing commands, only the routes for the specified node should be returned, similar to how the previous `headscale routes list -i <node_id>` command worked. The previous CLI command `headscale routes list -i <node_id> -o json` correctly filtered output to only show routes for the specified node ID. ### Expected Behavior The new command `headscale nodes approve-routes list-routes -i <node_id> -o json` ignores the -i flag entirely and returns route information for all nodes in the network, not just the specified node. ### Steps To Reproduce Have a Headscale instance with multiple nodes (subnet routers) Run: `headscale nodes approve-routes list-routes -i 12 -o json` The output contains route information for ALL nodes, not just node ID 12 ### Environment ```markdown - OS: MacOS Sequoia 15.7.2 - Headscale version: v0.27.0-debug - Tailscale version: 1.80.2 - Deployment method: Podman container ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information **Impact on Automation** This issue specifically affects: Ansible role for subnet router configuration Scripts that need to verify specific node route configurations Monitoring systems that check route status per node The workaround of fetching all nodes and filtering client-side is not feasible for production environments with many nodes due to: Performance overhead Security concerns (exposing all node data) Breaking existing automation that expects node-specific output Note: This is a CLI-specific issue and does not appear to affect the actual routing functionality - routes work correctly once configured. The issue is purely with the management interface returning unfiltered results.
adam added the bughelp wantedgood first issueroutes labels 2025-12-29 02:28:41 +01:00
adam closed this issue 2025-12-29 02:28:41 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug good first issue help wanted routes
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1165
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?