Skip to content

Return 400 for invalid instance registration payloads#5125

Open
amacharla15 wants to merge 2 commits intocodecentric:masterfrom
amacharla15:upstream-fix-instances-400
Open

Return 400 for invalid instance registration payloads#5125
amacharla15 wants to merge 2 commits intocodecentric:masterfrom
amacharla15:upstream-fix-instances-400

Conversation

@amacharla15
Copy link

Summary:

Map invalid /instances registration payloads to 400 BAD_REQUEST instead of surfacing as 500.

Add integration tests covering invalid JSON, missing name, and missing healthUrl.

How to run:

./mvnw -pl spring-boot-admin-server -Dtest=InstancesControllerIntegrationTest test

Evidence:

Before: invalid registration could surface as 500.

Now: tests fail if invalid payloads don’t return 400.

@amacharla15 amacharla15 requested a review from a team as a code owner March 1, 2026 12:37
@SteKoe
Copy link
Contributor

SteKoe commented Mar 3, 2026

Hi @amacharla15,

thanks for your PR! I very much like that you have provided backend tests. I have got some questions, though:

  • What is the purpose of test frontend test?
  • What is the purpose of mapping.json?
  • What is your reason for not using spring-boot-starter-validation alongside @Valid in Controller as well as @NotBlank on targeted fields in Registration.java and get rid of ControllerAdvice?

Copy link
Contributor

@SteKoe SteKoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above.

@amacharla15
Copy link
Author

Hi @SteKoe — Apologies and thanks for the review and the questions.

Purpose of the frontend test
There is no intended purpose for a frontend test in this PR. That file was an accidental artifact from my local exploration when I was reproducing the behavior and verifying UI impact. I agree it should not be part of this backend-focused change. I will remove it from the PR so the scope stays strictly server-side.

Purpose of mappings.json
Same situation: mappings.json was not meant to be included. It is related to local mock/test setup (WireMock/MSW-style mapping artifacts) and is not required for the server fix or the integration tests validating /instances. I will remove it from the PR.

Why I didn’t use spring-boot-starter-validation + @Valid/@notblank
My initial goal was to keep the production change minimal and explicitly map the observed failure mode (invalid registration surfacing as 500) to a 400 via a controller advice, while locking it in with integration tests.
That said, I agree your suggestion is cleaner and more idiomatic: using spring-boot-starter-validation with @Valid on the controller input + @notblank on the relevant fields should enforce request validation at the right layer and avoid the need for custom ControllerAdvice. I will update the PR to use standard bean validation and remove the advice if it becomes unnecessary, while keeping the same integration tests to guarantee the 400 contract.

Additionally, I will rebase the branch onto the current codecentric:master so the PR is no longer out-of-date and CI can run cleanly.

@ExceptionHandler(ServerWebInputException.class)
public ResponseEntity<Void> handleWebInput(ServerWebInputException ex) {
Throwable cause = Exceptions.unwrap(ex);
if (cause instanceof IllegalArgumentException) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally fail to understand the need of this if if, outside of it, you're returning exactly the same value.

I think it could be dropped.

if (cause instanceof IllegalArgumentException) {
return ResponseEntity.badRequest().build();
}
return ResponseEntity.badRequest().build();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just returning 400 with no details will leave users lost.

import org.springframework.web.server.ServerWebInputException;
import reactor.core.Exceptions;

@RestControllerAdvice(annotations = AdminController.class)
Copy link
Contributor

@cdprete cdprete Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this work also for the reactive-based part of SBA?

/cc @SteKoe

@cdprete
Copy link
Contributor

cdprete commented Mar 6, 2026

I'm not part of the team, therefore I shouldn't intervene in this, but as a consumer of SBA I'm afraid of potential side-effects and that's why I'm sticking my noise in this. :)

If I may ask, what's the use case/motivation that triggered this change?
To my knowledge, but I may be wrong, it should not really be possible to send invalid payloads unless the API is called from third-party clients and not through the standard/supported ones (SBA direct client or service discovery integration).

Of course, I totally agree with @SteKoe's suggestion to use the bean validation.
Not only for simplicity, but also to be able to provide meaningful details on what was wrong to the caller instead of just getting an anonymous 400.

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.

3 participants