sunnysabor opened a new issue, #7283: URL: https://github.com/apache/shenyu/issues/7283
### Feature Request Add an initial WebSocket configuration synchronization readiness gate for new gateway instances. Keep the scope limited to the first successful full synchronization: do not change liveness or the existing traffic behavior after a previously synchronized gateway disconnects from Admin. ### Is your feature request related to a problem? Please describe In the official Apache ShenYu implementation, completing the WebSocket handshake does not mean that the initial configuration has been applied. A deployment using the standard health endpoint as its readiness probe may therefore route requests to a new instance before the required routing configuration is available. Source review baseline: apache/shenyu master at c8b8ccb801e0a47eb34dd52f30d33c0f7611d20c. - [ShenyuWebsocketClient](https://github.com/apache/shenyu/blob/c8b8ccb801e0a47eb34dd52f30d33c0f7611d20c/shenyu-sync-data-center/shenyu-sync-data-websocket/src/main/java/org/apache/shenyu/plugin/sync/data/websocket/client/ShenyuWebsocketClient.java#L190-L248) waits for the connection, sends MYSELF in onOpen(), and handles configuration in subsequent onMessage() calls. alreadySync is set immediately after sending MYSELF; it is not an application-completion flag. A false initial connection result does not itself fail bean initialization. - [WebsocketCollector](https://github.com/apache/shenyu/blob/c8b8ccb801e0a47eb34dd52f30d33c0f7611d20c/shenyu-admin/src/main/java/org/apache/shenyu/admin/listener/websocket/WebsocketCollector.java#L202-L210) invokes namespace synchronization. [SyncDataServiceImpl](https://github.com/apache/shenyu/blob/c8b8ccb801e0a47eb34dd52f30d33c0f7611d20c/shenyu-admin/src/main/java/org/apache/shenyu/admin/service/impl/SyncDataServiceImpl.java) publishes configuration groups separately, without an overall initial-sync completion acknowledgement. - [WebsocketDataChangedListener](https://github.com/apache/shenyu/blob/c8b8ccb801e0a47eb34dd52f30d33c0f7611d20c/shenyu-admin/src/main/java/org/apache/shenyu/admin/listener/websocket/WebsocketDataChangedListener.java) skips empty groups. Counting a fixed number of messages cannot establish completion. - The [official Kubernetes WebSocket example](https://github.com/apache/shenyu/blob/c8b8ccb801e0a47eb34dd52f30d33c0f7611d20c/shenyu-e2e/shenyu-e2e-case/k8s/sync/shenyu-bootstrap-websocket.yml#L38-L55) uses /actuator/health for both probes, with a 30-second initial delay. Initial WebSocket synchronization is not connected to readiness. This is a source-based finding, not a runtime reproduction report. Premature traffic is a possible timing-dependent outcome, not a claim that every startup fails or returns a particular HTTP status. ### Describe the solution you'd like Proposed bounded implementation, subject to maintainer feedback: 1. Allow the application and management endpoint to start, but keep synchronization readiness false until the first successful full synchronization for the configured namespace. 2. Define an identifiable synchronization attempt and completion protocol. Account for empty groups and prevent a completion signal from a failed, abandoned, or previous connection attempt from opening readiness. A valid empty configuration must be able to complete synchronization. 3. Mark synchronization ready only after all required configuration groups have been successfully applied locally. Receiving an end message alone is insufficient if subscriber work is still pending or has failed. Define the boundary explicitly for subscribers that initialize resources asynchronously. 4. Keep readiness false on initial connection failure, incomplete synchronization, timeout, or application failure. Permit a fresh attempt to recover. Do not use this condition to fail liveness or force restarts. 5. Once initial synchronization succeeds, do not revoke this gate solely because of later WebSocket disconnection. Preserve existing cached-configuration and incremental-update behavior. This gate does not guarantee upstream service health or indefinitely fresh configuration. 6. Expose the condition through the readiness health group and configure the example to probe that group. Keep it out of the liveness probe, including when liveness currently uses the aggregate health endpoint. Other readiness conditions must remain effective. Traffic gating depends on the deployment honoring readiness; blocking direct HTTP requests is outside this proposal. Compatibility needs an explicit decision before implementation: use a capability-negotiated/opt-in protocol so existing clients remain compatible. When strict initial-sync readiness is enabled against an unsupported Admin, report a clear not-ready reason rather than silently falling back to connection-based readiness. Confirm default enablement and upgrade order with maintainers. For multiple Admin URLs, define which authoritative synchronization attempt can satisfy the gate without combining unrelated attempts. Acceptance tests should cover delayed initial groups, empty configuration, unavailable Admin, send/application failures, abandoned attempts and reconnects before completion, successful retry, readiness transition after successful application, unchanged liveness, disconnection after initial success, and old/new peer compatibility. Include a test with application processing still pending when the completion message arrives. Strict transactional snapshots across configuration groups, atomic cache replacement during later updates, and new post-start disconnection policies are outside scope. The protocol must nevertheless define how concurrent incremental messages interact with initial-sync completion so it cannot report success for incomplete initial application. ### Describe alternatives you've considered - A fixed probe delay only reduces the likelihood of the race; it does not prove completion. - Checking WebSocket connectivity or alreadySync does not prove configuration application. - Checking for non-empty caches incorrectly rejects legitimate empty configurations and may accept partially loaded configurations. - A documentation-only change can clarify the limitation but cannot provide the readiness guarantee. ### Additional context The [official WebSocket synchronization documentation](https://shenyu.apache.org/docs/user-guide/property-config/use-data-sync/) describes initial full synchronization after connecting but does not explain this readiness limitation. A focused implementation PR could follow this issue, covering the Admin protocol, gateway synchronization state, readiness integration, example probe configuration, and regression tests. A separate website documentation PR could clarify current behavior and later document the agreed feature. Feedback on the scope, compatibility strategy, and configuration-application completion boundary would help keep that implementation focused. -- 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]
