[Spce-user] GET /api/subscriberregistrations/ total_count broken (mr13.5.1) - recommended way to get active registration count?

[Ml Ml]

Hi all,

We're running Sipwise mr13.5.1 and use GET
/api/subscriberregistrations/ (the classic v1-style URL, we are not
calling /api/v2/... explicitly) for external monitoring (Nagios) to
track how many SIP
subscribers are currently registered system-wide.

Until recently this worked for mr6.5.1 by reading the total_count
field from an unfiltered/lightly-paginated request, which reflected
the true total independent of the "rows" pagination parameter. At some
point this
changed:

total_count now simply echoes back the requested "rows" value instead
of the real total:
- ?page=1&rows=1 -> total_count: 1
- ?page=1&rows=100 -> total_count: 100
- ?page=1&rows=1000 -> the request itself never completes; it times
out server-side after ~60s with no response at all.

We noticed from the mr13.5.1 changelog that several endpoints have
been migrated to a new "API v2" backend while keeping their original
v1-style URL. We don't know whether /api/subscriberregistrations/
received the same treatment, but the symptom (total_count now equals
whatever
"rows" was requested, and large requests time out) looks exactly like
the kind of regression that backend swap could cause. Can anyone
confirm whether this endpoint was migrated, and if so, whether this
is a known issue?

We tried working around it by requesting larger row counts to force
total_count up to the true value, but any request above roughly
500-1000 rows for this endpoint reliably times out, so that isn't
viable
at our scale (~6k active subscribers).

So, two questions for the list:
1. Is the total_count regression on GET /api/subscriberregistrations/
a known issue, and is a fix planned/available?
2. What is the currently recommended way, via API, to get an accurate
count of currently active/registered SIP subscribers?

Thanks,
Michael