Skip to content

[CF-4208] Add --filter to on-prem Flink application list - #3428

Open
Paras Negi (paras-negi-flink) wants to merge 1 commit into
mainfrom
cli-cf-4208-application-filtering
Open

[CF-4208] Add --filter to on-prem Flink application list#3428
Paras Negi (paras-negi-flink) wants to merge 1 commit into
mainfrom
cli-cf-4208-application-filtering

Conversation

@paras-negi-flink

@paras-negi-flink Paras Negi (paras-negi-flink) commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

Release Notes

New Features

  • Added a --filter flag to the on-prem (Confluent Platform / CMF) confluent flink application list command, to filter large environments server-side instead of "list everything then grep".

Checklist

  • I have successfully built and used a custom CLI binary, without linter issues from this PR.
  • I have clearly specified in the What section below whether this PR applies to Confluent Cloud, Confluent Platform, or both.
  • I have attached manual CLI verification results in the Test & Review section below.
  • I have added appropriate CLI integration or unit tests for any new or updated commands and functionality.
  • I confirm that this PR introduces no breaking changes or backward compatibility issues.
  • I have indicated the potential customer impact if something goes wrong in the Blast Radius section below.
  • I have put checkmarks below confirming that the feature associated with this PR is enabled in:
    • Confluent Cloud prod
    • Confluent Cloud stag
    • Confluent Platform
    • Check this box if the feature is enabled for certain organizations only

Builds on #3424 (--page-size), now merged into main; this PR targets main directly and contains only the filtering change.

What

Confluent Platform (CMF on-prem) only — filtering half of CF-4208; Confluent Cloud flink commands are untouched.

flink application list had no filtering, so at scale the only pattern was "list everything then grep" (CF-4202). This adds a single --filter flag that takes a CMF filter expression and applies it server-side:

  • Comma-separated key=value terms, e.g. --filter name=my-app*,state=RUNNING.
  • name supports a trailing * wildcard and its value is case-sensitive (Kubernetes resource names).
  • state filters by Flink job state; its value is case-insensitive (state=running behaves like state=RUNNING).

This mirrors the generic filter shape the CLI code generator will produce for CMF resources, rather than inventing per-field flags — per review feedback on this PR. ListApplications gains a filter argument applied before pagination. The CLI upper-cases only state= values before sending (CMF matches the job-state enum case-sensitively); every other term is passed through verbatim, and there is no client-side validation — an unknown state is forwarded and simply matches nothing.

Blast Radius

  • Scoped to application list; with no --filter set, behavior is unchanged (no filter param). No CmfClientInterface/mock change. Non-breaking, easy to revert.

References

Test & Review

  • Unit TestNormalizeApplicationFilter: state folded to upper case (value and key case-insensitive), name and unknown keys passed through verbatim.
  • Integration: --filter name= exact + wildcard, --filter state= in lower- and upper-case resolving to the same result (proves case-folding), unknown state → empty, combined name=...,state=...; help golden regenerated. make lint clean.
# name wildcard + state; state is case-insensitive (lower-case works)
$ confluent flink application list --environment default --filter name=default-application-1*,state=reconciling
          Name          | Environment |     Job Name      | Job Status
------------------------+-------------+-------------------+--------------
  default-application-1 | default     | State machine job | RECONCILING

# unknown state is forwarded as-is and simply matches nothing (no client-side validation)
$ confluent flink application list --environment default --filter state=bogus -o json
[]

🤖 Generated with Claude Code

@confluent-cla-assistant

confluent-cla-assistant Bot commented Aug 2, 2026

Copy link
Copy Markdown

🎉 All Contributor License Agreements have been signed. Ready to merge.
Please push an empty commit if you would like to re-run the checks to verify CLA status for all contributors.

@paras-negi-flink
Paras Negi (paras-negi-flink) marked this pull request as ready for review August 6, 2026 18:50
@paras-negi-flink
Paras Negi (paras-negi-flink) requested a review from a team as a code owner August 6, 2026 18:50
Copilot AI lite review requested due to automatic review settings August 6, 2026 18:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds application-list filtering support for Flink on-prem by wiring CLI flags into the CMF “filter” query parameter and updating the on-prem test server + integration fixtures to exercise name/status filtering behavior.

Changes:

  • Add --name (wildcard suffix supported) and --status flags to flink application list, and build a CMF filter query from them.
  • Extend the CMF REST client ListApplications to accept an optional filter and include it in requests.
  • Update the on-prem test server to emulate CMF-side filtering and add new integration test cases + golden outputs.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
test/test-server/flink_onprem_handler.go Emulates CMF filter behavior for on-prem application listing.
pkg/flink/cmf_rest_client.go Adds filter support to the REST client listing call.
internal/flink/command_application_list.go Introduces --name/--status flags and composes the CMF filter query.
internal/flink/command_application_list_test.go Unit-tests the filter composition helper.
test/flink_onprem_test.go Adds integration scenarios for list filtering.
test/fixtures/output/flink/application/*.golden Golden outputs for the new filtering scenarios and updated help text.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +174 to +193
switch key {
case "name":
name, _ := app.Metadata["name"].(string)
if prefix, isWildcard := strings.CutSuffix(value, "*"); isWildcard {
return strings.HasPrefix(name, prefix)
}
return name == value
case "state":
if app.Status == nil {
return false
}
jobStatus, ok := (*app.Status)["jobStatus"].(map[string]interface{})
if !ok {
return false
}
state, _ := jobStatus["state"].(string)
return strings.EqualFold(state, value)
default:
return true
}
Comment on lines +157 to +161
for _, expr := range strings.Split(filter, ",") {
key, value, found := strings.Cut(expr, "=")
if !found {
continue
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I have a few comments:


cmd.Flags().String("environment", "", "Name of the Flink environment.")
cmd.Flags().String("name", "", `Filter the Flink applications by name. Supports wildcards, for example "my-app*".`)
cmd.Flags().String("status", "", "Filter the Flink applications by status.")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should name this state to match the filter key.

// "state=" filter, per the cmf-sdk-go GetApplications filter documentation. Unknown values are
// still forwarded (the server returns no matches rather than erroring); this list only drives
// the advisory --status warning.
var allowedApplicationStatuses = []string{"RUNNING", "FINISHED", "FAILED", "CANCELED", "RECONCILING", "COMPLETED", "UNKNOWN"}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm: are all of these statuses accepted filter arguments? The spec's description for filterParam implies that only RUNNING or FAILED are valid; so the description may be out of date for the spec.

@airlock-confluentinc
airlock-confluentinc Bot force-pushed the cli-cf-4208-application-filtering branch 2 times, most recently from f5c4f57 to 7a68092 Compare August 7, 2026 19:02
@airlock-confluentinc
airlock-confluentinc Bot force-pushed the cli-cf-4208-application-filtering branch from 7a68092 to bbb15bf Compare August 8, 2026 04:08
@airlock-confluentinc
airlock-confluentinc Bot force-pushed the cli-cf-4208-application-filtering branch from bbb15bf to a153efd Compare August 8, 2026 05:08
Base automatically changed from cli-cf-4208-flink-list-limit-filter to main August 8, 2026 08:04
@paras-negi-flink Paras Negi (paras-negi-flink) changed the title [CF-4208] Add --name/--status filtering to on-prem application list [CF-4208] Add --filter to on-prem Flink application list Aug 11, 2026
@airlock-confluentinc
airlock-confluentinc Bot force-pushed the cli-cf-4208-application-filtering branch from a153efd to 9c11d37 Compare August 11, 2026 13:28
Add a single `--filter` flag to `confluent flink application list` that takes
a CMF filter expression, for example `name=my-app*,state=RUNNING` (comma-
separated `key=value` terms; `name` supports a trailing `*` wildcard). This
mirrors the generic filter shape the CLI code generator will produce for CMF
resources instead of inventing per-field flags.

`state=` values are upper-cased before the request so users need not match
CMF's case-sensitive job-state enum (`state=running` behaves like
`state=RUNNING`); every other term, including case-sensitive Kubernetes
`name` values, is passed through verbatim.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@airlock-confluentinc
airlock-confluentinc Bot force-pushed the cli-cf-4208-application-filtering branch from 9c11d37 to c83835e Compare August 11, 2026 15:10
@sonarqube-confluent

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants