Add tests for validation and error handling across controllers

[devin-ai-integration]

Summary

Merges all 4 validation/error-handling feature branches (size-constraints, validated-controllers, exception-handler, safe-auth-header) into a single branch and adds 7 new tests verifying the introduced validation behavior:

Test File	Test	Validates
ArticlesApiTest	should_get_422_with_negative_offset	@Min(0) on offset param
ArticlesApiTest	should_get_422_with_excessive_limit	@Max(100) on limit param
ArticlesApiTest	should_get_422_with_zero_limit	@Min(1) on limit param
CommentsApiTest	should_get_422_with_overly_long_comment_body	@Size(max=65535) on NewCommentParam.body
UsersApiTest	should_get_422_with_short_password	@Size(min=8) on RegisterParam.password
UsersApiTest	should_get_422_with_malformed_json_body	HttpMessageNotReadableException → 422 handler
CurrentUserApiTest	should_get_422_with_malformed_authorization_header	extractToken rejects non-"Token " prefix

Also adds gradle.properties with JDK 17 JVM args for Spotless compatibility, and includes a minor Spotless formatting fix to DefaultJwtServiceTest.

Updates since last revision

• Added SLF4J logging to catch-all exception handler (CustomizeExceptionHandler.handleGenericException): The method was silently swallowing all unexpected exceptions. Now logs at ERROR level before returning the generic 500 response. Addresses Devin Review feedback.

Review & Testing Checklist for Human

• CurrentUserApi auth header test approach: The test sends "Bearer <value>" to get past the JwtTokenFilter (which splits on space and extracts index 1) while failing at CurrentUserApi.extractToken (which requires "Token " prefix). Verify this correctly exercises the intended validation path and not just a mock artifact.
• Known issue — misleading error message: extractToken throws InvalidAuthenticationException which has a hardcoded "invalid email or password" message. This is incorrect for a malformed Authorization header. Intentionally left as a follow-up since it's in the feature branch code, not the test code. Consider adding a custom message constructor in a separate PR.
• Boundary values match annotations: Confirm 65536 chars exceeds @Size(max=65535), "short" (5 chars) is below @Size(min=8), limit=101 exceeds @Max(100), and limit=0 violates @Min(1).
• Run ./gradlew test locally: During development, should_show_error_message_for_blank_username (a pre-existing test) flaked once in the full suite but passed on rerun. Worth confirming the full suite is stable.
• Merge completeness: Verify all 4 feature branches are fully represented — check that CommentsApi.java has both @Size on NewCommentParam.body AND @Validated/@NotBlank on controller methods.

Notes

• CI workflow was intentionally removed from this repo; Snyk checks can be ignored.
• gradle.properties is new and required for JDK 17 + Google Java Format (Spotless) compatibility.

Link to Devin session: https://app.devin.ai/sessions/70282513914a44af917558fad91a47bd
Requested by: @tobydrinkall

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Devin Review found 2 potential issues.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🟡 extractToken throws InvalidAuthenticationException with misleading "invalid email or password" message

When the Authorization header doesn't start with "Token " (e.g., using "Bearer " prefix), CurrentUserApi.extractToken (CurrentUserApi.java:55-56) throws InvalidAuthenticationException, which has a hardcoded message "invalid email or password" (InvalidAuthenticationException.java:6). The handleInvalidAuthentication handler returns this message in the 422 response body. This is factually wrong — the user authenticated successfully but used the wrong header prefix. The client receives {"message": "invalid email or password"} when the actual problem is a malformed Authorization header format.

Prompt for agents

The extractToken method in CurrentUserApi throws InvalidAuthenticationException when the Authorization header does not start with "Token ". However, InvalidAuthenticationException has a hardcoded message "invalid email or password" (in InvalidAuthenticationException.java), which is incorrect for this error case. The actual issue is a malformed Authorization header.

Two possible approaches to fix:
1. Add a constructor to InvalidAuthenticationException that accepts a custom message string, and call it with something like "Authorization header must start with 'Token '" from extractToken.
2. Create a separate exception class (e.g., InvalidAuthorizationHeaderException) for this specific case, with its own handler in CustomizeExceptionHandler returning an appropriate error message and status code (401 might be more appropriate than 422 here).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Valid observation — InvalidAuthenticationException has a hardcoded "invalid email or password" message which is misleading when the actual issue is a malformed Authorization header prefix. This is pre-existing behavior from the safe-auth-header feature branch. Since this PR's scope is adding tests for the new validation, I'll leave this as a follow-up item rather than changing the exception hierarchy here. A clean fix would be to add a constructor accepting a custom message, e.g. "Authorization header must start with 'Token '" when called from extractToken.