feat(drain): filter the drain list by recipient type - #1113
Open
KannarFr wants to merge 1 commit into
Open
Conversation
|
🔎 A preview has been automatically published! If you created the alias to the preview script, you can run this command to download and install this preview: clever-preview update feat-drain-filter-by-typeYou can also run it from your local repository: ./scripts/preview.js update feat-drain-filter-by-type
This preview will be deleted once this PR is closed. |
Adds `clever drain --type <drain-type>` so a resource with several drains
can be narrowed to one recipient type, in both human and JSON output:
clever drain --type elasticsearch
clever drain --type datadog -F json
The option reuses DRAIN_TYPE_CLI_CODES, so it validates at parse time, is
shell-completed, and stays in sync with the types `drain create` accepts.
Filtering happens client side: the resource scoped endpoint the CLI calls
(`GET /v4/drains/organisations/{ownerId}/resources/{resourceId}/drains`)
only takes status and executionStatus query parameters. `recipientType`
exists on the admin `GET /v4/drains` endpoint, which is not reachable here.
The response is bounded by the drains of a single resource and never
paginates, so there is nothing to miss by filtering after the call.
The empty-list message names the type when one is set, so an empty result
reads as an empty filter rather than a resource with no drains at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KcPGoR5eyRZtYWhCFvyqvs
KannarFr
force-pushed
the
feat/drain-filter-by-type
branch
from
August 3, 2026 13:11
7da7a0e to
b95d575
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1112, independent of it (branched from
master, no shared files beyond the generated docs).clever drainlisted every drain of a resource with no way to narrow it down. This adds--type:The option reuses
DRAIN_TYPE_CLI_CODES, so it is validated at parse time, shell-completed, and stays in sync with whateverdrain createaccepts — including new types as they ship.Why the filter is client side
The endpoint the CLI calls,
GET /v4/drains/organisations/{ownerId}/resources/{resourceId}/drains, only takesstatus,executionStatusandexecutionStatusNotIn.recipientTypeexists, but on the adminGET /v4/drainsendpoint, which isn't reachable from here. The response is bounded by the drains of a single resource and never paginates, so filtering after the call can't miss anything. IfrecipientTypeis ever added to the resource-scoped endpoint, moving the filter server-side is a one-line change insrc/clever-client/drains.js.The filter applies to both output formats, and the empty-list message names the type when one is set, so an empty result reads as an empty filter rather than a resource with no drains at all.
Checks
npm run validatepasses. Verified by hand that an unknown--typeis rejected at parse time with the list of valid values, and that shell completion offers the drain types after--type.Not included, still open if you want it: the multi-drain table shows ID / Status / Execution status / URL but no Type column, so an unfiltered list still doesn't tell you what to filter on.