Repository navigation
Execution output, empty rules on upsert, and --rule-transform-name don't do what they say #472
Description
I found these while documenting transformations for the CLI. In all three, the command succeeds but doesn't do what the user asked.
Line references are against main at 3.1.0 (db4958c). I haven't run these against the API; the behaviour below comes from the source and the OpenAPI spec (2026-09-01).
1. transformation executions get and list drop everything except id and created_at
TransformationExecution (pkg/hookdeck/transformations.go:138) only declares ID and CreatedAt, so decoding the API response discards every other field. --output json (pkg/cmd/transformation_executions.go:115 and :182) marshals that struct, so it prints only those two fields as well.
Expected: executions get shows the execution's original_event_data, transformed_event_data and logs, plus log_level, webhook_id and issue_id, at least with --output json. These are the fields you need to debug a failing transformation, and right now they're only available in the Dashboard or the API.
Possible fix: add the fields to the struct, or keep the raw response (json.RawMessage) for --output json.
2. connection upsert with an empty rules array leaves the rules unchanged
connection upsert --rules-file rules.json with [] in the file (or --rules '[]') doesn't clear the connection's rules. pkg/cmd/connection_upsert.go:555 only sets req.Rules when len(rules) > 0, and the dry run reports Rules: N rules (unchanged).
connection update already handles this (pkg/cmd/connection_update.go:124): when --rules or --rules-file is passed, it sends the array even if it's empty.
Expected: upsert behaves like update, so you can remove a connection's last rule with it. Related: #466, which is also an upsert change that's ignored without any error.
3. --rule-transform-name without --rule-transform-code sends a rule the spec doesn't allow
With only --rule-transform-name, buildConnectionRules (pkg/cmd/connection_common.go:138) sends:
{ "type": "transform", "transformation": { "name": "my-transform" } }The spec requires both name and code in TransformRule.transformation; to reference an existing transformation you send transformation_id. So this is either rejected or relies on API behaviour the spec doesn't describe.
The flag help (connection_common.go:85) says "Name or ID of the transformation to apply", but nothing looks up a transformation_id from a name or ID, so an ID passed to the flag ends up in transformation.name.
Expected: when --rule-transform-code isn't set, look up the transformation by name or ID and send transformation_id. Otherwise, require --rule-transform-code, and change the help text to say the flag names a new inline transformation.
Activity