Skip to content

[Task][Plugin] Track shared plugin contracts and the first plugin adoption tasks #8199

Open
2 of 8 issues completed

Description

@Aias00

Goal

Improve the shared contracts that let ShenYu plugins be configured, observed, tested and independently delivered. Start with the current legacy execution path and small adoption tasks in Rewrite, Divide and the existing HTTP-to-gRPC bridge.

This is a coordination issue for bounded deliverables and existing work, not a proposal to replace ShenyuPlugin, introduce an API entity, or make DAG orchestration a prerequisite. Configuration remains plugin / selector / rule; Admin-to-gateway communication continues through existing data-sync channels.

Verified baseline

Reviewed apache/shenyu@750673e3f619e335333150ff1b2d14070d5d5c31 (2.7.3-SNAPSHOT). The repository already has the reactive plugin API, selector/rule matching, SPI, starter and external-JAR paths, UI field metadata, several concrete validators, request-level tracing and lifecycle regression tests. The gaps concern reusable contracts and their consistent adoption, not absence of those capabilities.

Delivery order

  1. Define optional configuration contracts, role/capability descriptions, and reusable tests for current execution semantics. Keep configuration contracts and capability descriptions independently deliverable, even if they share a static metadata envelope.
  2. Deliver compatible per-plugin adoption: Rewrite and Divide configuration contracts, plus selector-owned gRPC client leases and bounded retirement.
  3. Use these contracts in independent plugin builds and diagnostics. Future graph validation may consume audited metadata; it must retain its separate executor and readiness boundaries.

Each implementation task must state its compatibility policy, source evidence, narrow scope, meaningful tests and migration documentation. This tracker is completed by the listed deliverables, not by requiring every plugin to migrate at once.

Reuse existing owners

Concern Existing owner / boundary
Multi-object configuration revision consistency #8060; schema validation alone does not make a publication atomic
Configuration-instance preparation, resource leases and close #8061
Stream retirement and security revocation #8062
Typed supporting transport/credential/resource providers #8063; distinct from request-plugin capabilities
Same-path JAR replacement and SPI discovery #6725 and #6729; coordinate actual loading/resource-enumeration tests
Maven metadata parsing and artifact identity #6631; parsing budgets are a separate deliverable
External build, compatibility, E2E and release #7294 and #7306; do not create another plugin-store migration tracker
Installed catalog versus active execution diagnostics #8017; extend existing bounded diagnostics
Optional graph execution #7993 and its children; preserve legacy behavior and share lifecycle infrastructure

Compatibility and completion criteria

  • Existing external names, starter-based plugins, selector/rule matching, ordering and legacy plugins without new metadata continue to work.
  • No new mandatory abstract methods, global dependency stack or eager arbitrary plugin-code execution in Admin is introduced.
  • before/after construction-time behavior remains unchanged. New terminal observations and tests are additive; fork() does not promise parallel use of one exchange.
  • Rewrite/Divide demonstrate common configuration fixtures across Admin and gateway without adding more plugin-name branches.
  • The resource-bearing pilot proves candidate ownership, replacement failure, active-call retention, cancellation and bounded cleanup with real plugin/client paths.
  • A repository-external plugin can consume the published test support against a declared supported core version; release infrastructure remains under [Task] Establish the shenyu-plugin-store build, test, E2E, and release baseline #7294.
  • New metadata/diagnostics have bounded output and disclose no secret values; streaming claims are backed by the relevant protocol tests.

Implementation tracking

Focused system-level and plugin-level tasks are linked below as they are created. Existing owners above remain authoritative; this issue does not reparent their work or imply community acceptance of every proposal.

System contracts

First plugin adoption tasks

The Rewrite and Divide issues are sub-issues of #8200; the actual-matching adapter is a sub-issue of #8203. The other newly created system/adoption tasks are sub-issues of this tracker. Existing owners in the table remain linked coordination dependencies and have not been moved.

Chain extension follow-ups

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions