| name | pixiu-filter-author |
| description | Creates and debugs dubbo-go-pixiu HTTP/Network filters. Use when adding, registering, or wiring Pixiu filters, or when a filter compiles but does not run. Do not use for adapter or protocol-listener SPI work. |
pixiu-filter-author
Purpose
Build Pixiu HTTP/Network filters that register and run.
When to use
-
Use when:
- Adding, fixing, or wiring Pixiu HTTP/Network filters.
- Porting Envoy/Kong/APISIX filters.
- Diagnosing filters that compile but do not run.
-
Do not use for:
- Registry adapter or protocol-listener SPI implementation.
Inputs
Do not generate YAML, write code, create files, or take any implementation action until the user has provided all required inputs. This is a first principle.
If any required input is missing, this turn must only ask for the missing fields in the current input group; do not generate examples, defaults, YAML, code, or final output.
Even if configuration information seems inferable, obvious, or implied by context, you must still ask the user to confirm it. Do not proceed until the user confirms it.
- Choose filter type (required):
- Required:
filter_type: http or network
- Common plugin information (required):
- Required:
Kind constant value, also used as YAML name
- HTTP filter (required when
filter_type: http):
- Required:
- Which stages to implement:
Decode, Encode, or both
- Processing logic for each stage, in natural language or pseudocode
- Optional:
Config fields and validation logic
- Network filter (required when
filter_type: network):
- Required:
- Which
NetworkFilter callbacks to implement, such as OnData, OnTripleData, or ServeHTTP
- Processing logic for each callback, in natural language or pseudocode
- Optional:
Config fields and validation logic
Workflow
- Check required Inputs first:
- Read existing code, config, and already provided user information first; do not ask again for information already present or stated.
- Ask one
Inputs group at a time. Each time, output only that group's required fields, with a short explanation after each field.
- If the current group's required fields are incomplete, ask only for the missing fields and do not move to the next group.
- After the current group's required fields are complete, ask whether to fill that group's optional fields; if yes, list those optional fields with short explanations.
- After optional fields are skipped or completed, apply that group's defaults to complete implementation or mounting snippets; defaults must not override existing code, config, or user input.
- Read current source before writing code:
pkg/common/extension/filter/filter.go for SPI interfaces and pkg/pluginregistry/registry.go for the current blank-import list.
- HTTP filter example:
pkg/filter/cors/cors.go.
- Network filter example:
pkg/filter/network/dubboproxy/.
- Choose package shape by
filter_type: HTTP filters go under pkg/filter/<name>/ or pkg/filter/http/<name>/; Network filters go under pkg/filter/network/<name>/.
- Implement the matching SPI: HTTP defines
Kind, Plugin, FilterFactory, Filter, and Config; Network defines Kind, Plugin, Filter, and Config.
- Finish registration and mounting: in the filter package's
init(), call the registration function — filter.RegisterHttpFilter(&Plugin{}) for an HTTP filter, filter.RegisterNetworkFilterPlugin(&Plugin{}) for a Network filter; add a blank import in pkg/pluginregistry/registry.go; then mount according to filter type under HCM or the listener filter-chain.
Output format
- Show the relevant YAML fragment.
Validation
- Verify the filter package's
init() actually calls filter.RegisterHttpFilter(&Plugin{}) (HTTP) or filter.RegisterNetworkFilterPlugin(&Plugin{}) (Network).
- Verify
pkg/pluginregistry/registry.go blank-imports the new package.
- Verify HTTP filters are nested under HCM
http_filters[], and Network filters are under listener filter_chains.filters[].
- Verify
PrepareFilterChain deep-copies factory.cfg fields into each per-request Filter instance and does not share pointers.