Repository navigation
Conversation
Rules built from --rule-<type>-* flags were always ordered deduplicate -> transform -> filter -> delay -> retry. Filter, transform and deduplicate run in rules array order, so filter-before-transform could not be expressed with flags, and every create, update or upsert with both flags produced transform -> filter. Each rule flag now records its rule type when set, and rules are emitted in the order of each type's first flag, as AGENTS.md describes. Types with no recorded position fall back to the previous order. Also state in the MCP connections tool that rule order matters. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TestConnectionWithMultipleRules passes filter, retry and delay flags and asserted the old fixed order (filter, delay, retry). Rules now follow flag order, so assert filter, retry, delay. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… and upsert The only acceptance check for flag order used retry and delay, which don't affect execution. Add end-to-end checks for the filter/transform case: - create: filter-then-transform and transform-then-filter are stored as given - update: reorder transform-then-filter to filter-then-transform, then save again, and the order holds - upsert: create with filter-then-transform, upsert again, order holds Transformations get unique names and are deleted after the connection. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The change is covered by unit and acceptance tests; the remaining release-note request is a non-blocking documentation nit.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Fixes connection rule construction so --rule-* flags preserve the first-seen rule-type order across create, update, and upsert.
Changes:
- Tracks and applies flag-defined rule ordering.
- Adds unit and acceptance coverage.
- Documents ordering for CLI and MCP users.
| File | Summary |
|---|---|
test/acceptance/helpers.go |
Adds rule-order acceptance helpers. |
test/acceptance/connection_upsert_test.go |
Tests upsert ordering. |
test/acceptance/connection_update_test.go |
Tests update ordering. |
test/acceptance/connection_test.go |
Tests create ordering. |
README.md |
Documents CLI rule ordering. |
pkg/gateway/mcp/tool_connections.go |
Documents MCP rule ordering. |
pkg/cmd/connection_rule_order_test.go |
Adds ordering and command integration tests. |
pkg/cmd/connection_common.go |
Implements flag-order tracking and ordered rule assembly. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| --rule-retry-count 3 | ||
| ``` | ||
|
|
||
| Rules built from `--rule-*` flags follow the order in which each rule type's first flag appears. Filter, transform and deduplicate rules run in that order, so put `--rule-filter-*` before `--rule-transform-*` to filter on the original payload. To set the whole array explicitly, use `--rules` or `--rules-file`. |
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
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.
--rule-*flags always built rules as deduplicate → transform → filter → delay → retry. Filter, transform and deduplicate run inrules[]order, so--rule-filter-body … --rule-transform-name …silently produced transform → filter on create, update and upsert.AGENTS.md("Ordered Array Configurations") already specifies--rules/--rules-fileare unchanged and keep the array as givenrulesdescription now says order mattersBehaviour change: anyone passing
--rule-filter-*before--rule-transform-*and relying on transform running first will now get filter first. That's the order they wrote, but it is a change.Implementation
addConnectionRuleFlagswraps each rule flag'spflag.ValueinorderTrackingValue. OnSet, it records the flag's rule type inconnectionRuleFlags.ruleOrder(first occurrence wins).buildConnectionRulesbuilds rules into a map by type, then emits them usingruleOrderfollowed bydefaultRuleOrder. Types with no recorded position, such as when the struct is populated directly in tests, keep the old order.Tests
pkg/cmd/connection_rule_order_test.go:create,updateandupsertcommands each record orderconnection_common.gogo test ./...passesContext
A customer's agent saw filter → transform flipped to transform → filter on every connection save. Their trigger was the REST API's pre-
2025-07-01versions, where transformations always run before filters. This CLI bug produces the same symptom. Related: hookdeck/agent-skills#29.🤖 Generated with Claude Code