Aias00 opened a new issue, #8015: URL: https://github.com/apache/shenyu/issues/8015
## Description Follow-up to the plugin orchestration review against master `34f2ed036` and design PR #8007 (`f2839049c`). Parent proposal: #7993. Owning implementation/design task: #7994. Related tasks: #7996, #8001. This issue refines the existing work breakdown; it does not assert that GRAPH execution is already implemented or that the proposed design has been accepted. HTTP/RPC API aggregation and parallel plugin execution remain out of scope. ## Problem The audit conflates HTTP transport retry with repeated subscription of an entire successor graph. AbstractHttpClientPlugin retries its own response publisher and then invokes chain.execute(exchange) after a response. Current legacy continuations hold a mutable cursor, whereas a graph continuation bound to a successor can restart that successor on every subscription. Reusing the same method signature does not by itself preserve semantics. ## Code and design evidence - [contract](https://github.com/apache/shenyu/blob/f2839049ca3873cde0b0c8fe6ff519c040dc905a/docs/plugin-graph-orchestration.md) §11; [compatibility audit](https://github.com/apache/shenyu/blob/f2839049ca3873cde0b0c8fe6ff519c040dc905a/docs/plugin-graph-compatibility-audit.md) §4.4 and continuation matrix - [transport retry followed by downstream continuation](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-plugin/shenyu-plugin-httpclient/src/main/java/org/apache/shenyu/plugin/httpclient/AbstractHttpClientPlugin.java) - [deferred request execution and mutable chain cursor](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-web/src/main/java/org/apache/shenyu/web/handler/ShenyuWebHandler.java) - [chain/fork contract](https://github.com/apache/shenyu/blob/34f2ed036/shenyu-plugin/shenyu-plugin-api/src/main/java/org/apache/shenyu/plugin/api/ShenyuPluginChain.java) ## Task List - Specify separately repeated calls to continuation.execute, repeated subscription to a returned successor publisher, transport-internal retry, repeated entry subscription and forked dispatch. - Audit actual supported plugins before choosing one-shot rejection, fresh execution or a documented compatibility restriction. - State whether CHOICE is re-evaluated on a supported new attempt and which state belongs to that attempt. - Do not insert blanket cache() or replay side-effecting successors implicitly. - Explain intentional differences from LEGACY and restrict incompatible plugins explicitly. ## Acceptance criteria - Tests cover each of the five execution cases independently. - Transport retry counts and downstream plugin execution counts match the chosen contract. - No accidental duplicate upstream side effects, stale response reuse or lost cancellation. - Retry/fallback compatibility claims are backed by concrete plugin tests rather than a category label. ## Dependencies and sequencing Resolve the contract portion in #7994 / PR #8007 before depending implementation hardens this assumption. Deliver code and integration coverage under #7994 and the related tasks above. Existing issue dependencies remain in effect; this issue adds a focused review requirement rather than a duplicate full implementation task. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
