This logic was originally left in place to help future test writers, but
its presence was vexing because it was not exercised in existing test
cases. It has been commented out should future tests need to leverage
it.
Kapacitor responses are paginated, and sometimes users have more than
the default 100 tasks that are returned from Kapacitor. This replaces
the previous Kapa client with one that automatically follows paginated
responses from Kapacitor's ListTasks endpoint and returns the full
response.
Tests for the KapacitorRulesGet endpoint had to be updated because they
did not account for "limit" and "offset", and so led to an infinite
loop with the paginated client. A correct kapacitor backend will not
have this behavior
The kapacitor client used in the kapacitor endpoints is limited to
fetching whatever limit you provide it. If you provide no limit, it
defaults to a limit of 100. We use this default behavior currently.
Some users have more than 100 tasks, so we need a client that's capable
of continually fetching tasks from Kapacitor until there are none left,
and returning the full response to the frontend.
This introduces a PaginatingKapacitorClient which does exactly that.
Also, test coverage was added around the KapacitorRulesGet endpoint,
since it was previously untested.
Deniz Kusefoglu
Jared Scheib
Chris Goller
deniz kusefoglu
Michael Desa
Nathan Haugo
Tim Raymond