Skip to content

fix(studio): make client provider fail explicitly instead of returning fake online clients - #752

Closed
123123213weqw wants to merge 1 commit into
apache:rocketmq-studiofrom
123123213weqw:fix/696-client-provider-not-implemented
Closed

fix(studio): make client provider fail explicitly instead of returning fake online clients#752
123123213weqw wants to merge 1 commit into
apache:rocketmq-studiofrom
123123213weqw:fix/696-client-provider-not-implemented

Conversation

@123123213weqw

Copy link
Copy Markdown

Fixes #696

Problem

ClientProviderStub is wired as the production ClientProvider but returns hard-coded sample connections (producer-001, consumer-001, consumer-002). The client connection page should not show production-looking fake clients when no real client provider is configured — it can mislead operators during validation.

Fix

Until a real Remoting/gRPC client provider is connected, findConnections now fails explicitly with a structured 501 Not Implemented BusinessException (mapped by GlobalExceptionHandler to Result.error(501, ...)), matching the issue's expected behavior. Added ClientProviderStubTest.

Verification

mvn test -Dtest=ClientProviderStubTest on JDK 21: Tests run: 2, Failures: 0, Errors: 0, Skipped: 0.

Diff

2 files changed.

…g fake online clients

ClientProviderStub was wired as the production ClientProvider but returned
hard-coded sample connections (producer-001, consumer-001, consumer-002),
which could mislead operators into believing real Remoting/gRPC clients are
online.

Until a real client provider is connected, findConnections now fails
explicitly with a structured 501 Not Implemented BusinessException.
Added ClientProviderStubTest for the new behavior.

Fixes apache#696
@lizhimins

Copy link
Copy Markdown
Member

Thanks for the contribution. This is already covered by #697, merged into rocketmq-studio as 49fef30: ClientProviderStub.findConnections no longer returns fabricated online clients and now fails explicitly with BusinessException(501, ...), with ClientProviderStubTest asserting that behaviour. #697 was opened first, so it was merged under first-come-first-served review order — same as #750/#751 vs #685/#687.

@lizhimins lizhimins closed this Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants