Problem: Limit field silently drops hosts when given an Ansible numeric range

[arthur-lbchn]

Issue

Description

Ansible's [x:y] host-range syntax works when defining hosts in a YAML inventory, so
it is natural to assume it works in a Limit entry too. It doesn't: the Limit value is
a host pattern, where [x:y] is treated as an fnmatch character class. The range
endpoints match and everything in between is skipped, with no warning or error. The
task reports success, so it is easy to believe the whole range ran.

Inventory

---
all:
  hosts:
    web0[1:9].example.com:

This expands correctly: web01 through web09 all appear in the inventory, nine
hosts in total.

Steps to reproduce

1. Open New Task on a template using the inventory above.
2. Under Limit, click + Add limit and enter web0[1:3].example.com.
3. Click RUN.

Expected

All three hosts are targeted, or the input is rejected as invalid.

Actual

Only web01.example.com and web03.example.com are targeted. web02.example.com
is excluded, with no warning or error.

Notes

I appreciate that [x:y] is inventory-definition syntax and that Ansible's behaviour
here is documented once the string is passed through as a pattern - the problem is
that Semaphore accepts the exact same syntax in two places and silently means
different things by it. Two things would help:

1. Warn or fail when a Limit matches zero hosts, or matches fewer hosts than the
   number of Limit entries supplied. The silent success is the dangerous part,
   especially on a task that changes state.
2. Add a hint on the Limit field describing accepted syntax (host names, groups,
   globs, comma-separated lists).

Thank you in advance!

Impact

Ansible (task execution)

Installation method

Binary

Database

MySQL

Browser

Chrome

Semaphore Version

2.18.12-8a4dcf0-1780941761

Ansible Version

2.16.3

Logs & errors

No response

Manual installation - system information

Linux REDACTED 6.8.0-136-generic #136-Ubuntu SMP PREEMPT_DYNAMIC Wed Jul 1 21:53:05 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Configuration

No response

Additional information

No response