Counting things, and why it takes a moment

Recurly does not report how many records match a question, so counting means reading through them. Small numbers are quick; large ones are a job for later, and Retrixus will say so rather than guess.

Ask "how many active subscriptions do we have?" and you would expect one number, straight away. Sometimes you get one. Sometimes Retrixus reads through several pages first, and for a very large site it will tell you it cannot answer yet.

That is worth understanding, because it is not a bug and it is not going to be fixed by waiting.

Recurly does not keep a running count

When Retrixus asks Recurly for subscriptions, Recurly replies with a batch of records and one extra fact: there are more. It does not say how many more. There is no total anywhere in the answer, and there is no separate "count" question you can ask it.

So the only way to know how many there are is to read all of them and count as you go.

What that means in practice

A few hundred records. Retrixus reads through them and gives you the number. It takes a few seconds longer than a normal question and you get an exact answer.

Tens of thousands. Reading every one would mean hundreds of requests against your Recurly site — requests that share a rate limit with your own billing systems. Retrixus will not quietly do that. It will tell you the question is too large and what to do instead.

A rough answer is never invented. If Retrixus has read 100 of an unknown number, it says "100 so far, and there are more". It does not estimate the rest and present it as a count. A confident wrong number is worse than an honest partial one, especially about money.

A question that stops partway gets no answer. When a question's time range holds more records than Retrixus may read in one go, it stops and tells you how far it got, for example "read up to Tuesday 9:12". It does not hand you rows from part of the range that look like a full answer. Your AI can ask for what was read anyway, clearly marked as incomplete, if you only want to explore. A batch is never planned from a partial answer.

What to do with a large site

Narrow the question. Most counting questions have a date range hiding in them, and a range makes the answer both faster and more useful:

• "How many subscriptions started last month?" — a bounded question, answered directly.
• "How many active subscriptions in total?" — unbounded, and on a large site not yet answerable.

Filters help the same way. "How many past-due invoices this quarter?" reads far less than "how many invoices?" Some filters are applied by Recurly itself, so the records left out are never read at all: the kind of payment (a purchase, a refund), and the state of an invoice or a subscription.

Invoices still being collected, however old. Questions about dunning ("which invoices have failed five times and are still being retried?") look at every past-due invoice, whenever it was created, not only those from the last few days. For each one Retrixus counts the failed attempts so far and lists the plans it bills.

Every row, not just the first 50

An answer shows at most 50 rows in the conversation. The rest are kept for a day, and your AI can read them a page at a time, up to 500 rows a page, without asking Recurly again. It can also hand the whole result to a batch: "cancel every account in that result" works on all of them, even thousands, and the rows never have to pass through the conversation. After a day the result is deleted; ask the question again for a fresh one.

This gets better

Full-book totals, revenue summaries and cohort analysis are what the analytics engine is for. It runs as a background job rather than a conversation, reads in much larger batches, and returns a computed answer instead of records — so the questions that are too large today are exactly the ones it is built for.

Until then, Retrixus would rather tell you it cannot count something than hand you a number it cannot stand behind.