Add a `tiger feedback` command by aprimakina · Pull Request #226 · timescale/tiger-cli

aprimakina · 2026-09-10T11:38:31Z

Adds tiger feedback, which relays feedback, a bug report, or a support request to the Tiger Data team through the gateway's new /feedback endpoint. Modeled on ghost's feedback command.

tiger feedback "I can't connect to my service after resuming it"
echo "Great tool!" | tiger feedback
tiger feedback   # reads from stdin, prompting on a terminal

The submitter's email is resolved from the caller's credentials and the client version and OS from the User-Agent, so neither is sent in the body. The command opens no support case and returns no ticket.

Re-sync openapi.yaml from the Tiger Cloud API spec, at savannah-gateway 40dde95, and regenerate the client, types, and mocks. Nothing here is hand-edited except the three MetricsAggFn call sites described below, and no path, operation, or schema the CLI had before was dropped. The sync picks up everything that landed upstream since the last one: - New endpoints: submitFeedback, enableDataTiering, the backup-regions and backup-retention operations, getServiceMetricDetails, the IP allow list operations (create, get, list, update, delete, and the service attach/detach pair), and the exporter operations (list, get, create, update, delete, and their own service attach/detach pair). - New component schemas for the exporter families (CloudWatch, Datadog, Prometheus, Azure Monitor), their AWS credential types, and their create/update variants, along with AllowList, BackupRegion, BackupRetentionByTime, MetricDetails, and DataTiering. - x-tigerdata-owner annotations on nearly every existing operation, which is why the diff touches so many paths without changing them. - x-tigerdata-internal, marking an operation as being for first-party clients only and excluded from the public docs and SDKs, described in the spec's own preamble and applied to submitFeedback and the two analytics operations. It is a visibility marker rather than a stability one, so `tiger feedback` and the feedback tool stay ungated. The aggregation enum on `service metrics series` moved out of the request body into a shared MetricsAggFn schema, renaming the generated constants from MetricsSeriesRequestFn* to MetricsAggFn*. Update the three call sites accordingly; --fn now also accepts MAXTOTAL and MINTOTAL. Two further changes land in schemas nothing here reads yet: - MetricLabelFilter gained an optional match_type, whose new MetricMatchType enum is EQUAL or NOT_EQUAL and defaults to EQUAL. Neither `service metrics series` nor its MCP tool sends it, so filters keep matching on equality exactly as before. - Service gained log_exporter_id and metric_exporter_id, PrometheusMetricsConfig a read-only endpoint, and MetricExporterConfigBase renamed enable_pg_metrics to include_pg_metrics. No CLI or MCP surface reads any of these, so the rename touches nothing outside the generated code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Relay feedback, a bug report, or a support request to the Tiger Data team through the gateway's /feedback endpoint, which posts it to Slack. The message comes from an argument or, when none is given, from stdin — piped or typed interactively, with the hint TTY-gated so piped input stays clean. The submitter's email is resolved from the caller's credentials and the version and OS from the User-Agent, so neither is sent in the body. The command is registered unconditionally and listed in the README: /feedback is not a preview operation, so nothing gates it. A feedback message is free text that may quote connection strings, queries, or anything else, and positional arguments were otherwise tracked verbatim. Route them through a new analytics.Args option, which clones a command's arguments and redacts the sensitive ones by command path — the message here, exactly as ghost does for `ghost feedback`. Redacting the value rather than dropping the property keeps the argument count, so a message passed as an argument stays distinguishable from one piped in. Flags are still tracked, subject to the analytics ignore list, which gains "message" so the feedback MCP tool's parameter is filtered the same way. Gateway side: timescale/savannah-gateway#1982 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Pair `tiger feedback` with an MCP tool, so an assistant can relay a user's feedback the same way. Ported from ghost's `ghost_feedback`, named `feedback` here since Tiger MCP doesn't prefix its tool names. The input schema carries the endpoint's own bounds (minLength 1, maxLength 3000), so an over-long message is rejected before the handler instead of round-tripping to a 400. The handler trims like the CLI, so both surfaces send the same message for the same text, and logs nothing — the only argument worth logging is the user's own free text. Registered through addTool but absent from readOnlyGatedTools: submitting feedback mutates no service, so the tool stays available in every read-only mode. Its `message` parameter is already filtered from analytics by the ignore list. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The `message` schema's maxLength made the SDK reject an over-long message with a validation error that quotes the whole value, and the analytics middleware records a tool's error text — so the message the ignore list exists to keep out shipped anyway. Check the length in the handler instead, reporting only the count, and state the cap in the field description so a client still knows it. Drop the thanks from the CLI's success line while here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

nathanjcochran

Left a couple very minor comments, but overall LGTM!

nathanjcochran · 2026-09-17T16:30:39Z

+This does not open a support case and returns no ticket to track. For anything
+that needs a tracked response, contact support directly.`,


Should we include a link to the support page in the console here, or something like that? So users know how to file a formal support ticket?

nathanjcochran · 2026-09-17T16:32:50Z

+		Title: "Submit Feedback",
+		Description: `Submit feedback, a bug report, or a support request to the Tiger Data team.
+
+The message reaches a person, so confirm the wording with the user before sending. This opens no support case and returns no ticket to track.`,


This says that it doesn't open a support case or return a ticket to track, but it doesn't give any indication that users can create real support tickets elsewhere, or how to do it. Should be include something to that effect, like we do in the tiger feedback help text (i.e. "For anything needs a tracked response, contact support directly.")? Maybe include a link to the support page in the console?

Review feedback: both the command and the MCP tool said this opens no support case, without saying where a tracked ticket is opened instead. The CLI now prints the console support link for the caller's project, and the tool returns it as support_url, which the description points at since the URL is project-specific. Also drops "support request" from the descriptions, so neither surface reads as a way to open one, and the exclamation point from the CLI's success line. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

aprimakina force-pushed the feedback-command branch from 48b0488 to f70d765 Compare September 10, 2026 11:57

aprimakina self-assigned this Sep 10, 2026

aprimakina force-pushed the feedback-command branch 2 times, most recently from c5fc488 to 07e1149 Compare September 17, 2026 12:42

aprimakina and others added 2 commits September 17, 2026 14:47

aprimakina force-pushed the feedback-command branch from 07e1149 to 3c4b59e Compare September 17, 2026 12:48

aprimakina marked this pull request as ready for review September 17, 2026 13:17

nathanjcochran self-requested a review September 17, 2026 15:42

nathanjcochran approved these changes Sep 17, 2026

View reviewed changes

nathanjcochran and others added 2 commits September 17, 2026 14:41

Merge branch 'main' into feedback-command

c7f290a

aprimakina force-pushed the feedback-command branch from 788d57e to e9c836b Compare September 18, 2026 12:08

aprimakina merged commit 860cb2e into main Sep 18, 2026
2 checks passed

aprimakina deleted the feedback-command branch September 18, 2026 12:51

ggodeke mentioned this pull request Sep 22, 2026

Document Tiger CLI 0.25: command renames, service rename/delete, tiger feedback timescale/Tiger-Data-Docs#565

Merged

6 of 8 tasks

Navigation Menu

Add a `tiger feedback` command - #226

Add a `tiger feedback` command#226
aprimakina merged 6 commits into
mainfrom
feedback-command

aprimakina commented Sep 10, 2026 •

edited

Loading

Uh oh!

nathanjcochran left a comment

Uh oh!

nathanjcochran Sep 17, 2026

Uh oh!

aprimakina Sep 18, 2026

Uh oh!

nathanjcochran Sep 17, 2026

Uh oh!

aprimakina Sep 18, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		This does not open a support case and returns no ticket to track. For anything
		that needs a tracked response, contact support directly.`,

Conversation

aprimakina commented Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nathanjcochran left a comment

Choose a reason for hiding this comment

Uh oh!

nathanjcochran Sep 17, 2026

Choose a reason for hiding this comment

Uh oh!

aprimakina Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

nathanjcochran Sep 17, 2026

Choose a reason for hiding this comment

Uh oh!

aprimakina Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

aprimakina commented Sep 10, 2026 •

edited

Loading