Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Router DSL: a two-argument path("/x", handler) route is missing from the endpoint model

Closed
  • Is something wrong?
#607 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@imuromtsev is already working on this.

Since Oct 11, 2026.

  • #643 by @imuromtsev — open

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
kotlin, spring
Domain
api, backend

Research direction

Start in SpringWebCoRouterLoader.kt, where coRouter and router bodies are visited, and in the ROUTER_DSL_ROUTE_METHODS list in SpringWebClasses.kt. The two-argument path(pattern, handler) call needs to be collected with an empty requestMethods list, following the unrestricted case in SpringWebEndpointsLoader.kt, rather than labelled as a verb. Done when /x is discovered with unrestricted methods, GET /y and method(HttpMethod.GET, handler) are unchanged, and one-argument path(pattern) is not collected as a route. Add regression coverage for the coRouter, reactive router and servlet router DSLs.

Written by the indexing model from the issue text.

Description

in:spring-web

Problem

The two-argument Kotlin DSL path("/x", handler) declares a route matching any HTTP method, but is missing from the endpoint model. This is distinct from extracting a prefix from the one-argument path("/a") predicate in #576 / PR #605.

@Bean
fun routes(handler: CatalogHandler) = coRouter {
    path("/x", handler::handle)
    GET("/y", handler::handle)
}

Expected: /x with unrestricted methods, plus GET /y. Actual: /x is not collected; /y remains listed. Repeat with reactive and servlet router { } and matching handler types.

Verified main code

Verified with git show public/main:<path> at fe97df62a335c9545679e79ed7a71ae018f5627e:

  • modules/spring-web/src/main/kotlin/com/explyt/spring/web/loader/SpringWebCoRouterLoader.kt:48–59 visits coRouter / router bodies but collects only calls in ROUTER_DSL_ROUTE_METHODS.
  • modules/spring-web/src/main/kotlin/com/explyt/spring/web/SpringWebClasses.kt:102–114 defines those entry points and the route list: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and method. Two-argument path is absent.
  • SpringWebCoRouterLoader.kt:77–85 currently constructs a singleton method list using SpringWebUtil.getRequestMethod. modules/spring-web/src/main/kotlin/com/explyt/spring/web/util/SpringWebUtil.kt:637–641 reads the HTTP-method argument for method(...), and otherwise returns the call name. Simply adding path to the list would therefore incorrectly label the HTTP method as path.
  • The existing endpoint model already defines the unrestricted-method representation: modules/spring-web/src/main/kotlin/com/explyt/spring/web/loader/SpringWebEndpointsLoader.kt:68–81 documents an empty requestMethods list when the declaration restricts no verbs, such as bare @RequestMapping. Use that representation for this route, not a fabricated path verb. method(HttpMethod.GET, handler) is method-constrained; it is not the unrestricted case.

Spring API evidence

Verified directly in cached Spring 6.2.19 source archives:

  • spring-webflux-6.2.19-sources.jar, org/springframework/web/reactive/function/server/CoRouterFunctionDsl.kt:496–497: fun path(pattern: String, f: suspend (ServerRequest) -> ServerResponse) registers RouterFunctions.route(RequestPredicates.path(pattern), asHandlerFunction(f)).
  • Same archive, org/springframework/web/reactive/function/server/RouterFunctionDsl.kt:543–544: fun path(pattern: String, f: (ServerRequest) -> Mono<out ServerResponse>) registers a route using only the path predicate.
  • spring-webmvc-6.2.19-sources.jar, org/springframework/web/servlet/function/RouterFunctionDsl.kt:538–539: fun path(pattern: String, f: (ServerRequest) -> ServerResponse) does the same.

These route overloads impose no HTTP-method predicate. They are not the one-argument path(pattern): RequestPredicate overload, nor Java builder .path(prefix, callback).

Verification status and acceptance criteria

The prior #576 red-test investigation recorded this exact missing /x symptom in docs/finds/found-bugs.md (entry dated 2026-10-09, base fe97df62a335c9545679e79ed7a71ae018f5627e). That is prior test evidence, not a fresh test run for this issue. The route-filter exclusion and Spring semantics above were independently rechecked from source; no checkout, Gradle run, or implementation change was made while filing.

Add regression coverage for all three Kotlin DSL classes:

  1. Discover /x with empty requestMethods (unrestricted).
  2. Keep sibling GET /y and explicit method(HttpMethod.GET, handler) semantics unchanged.
  3. Compose an enclosing resolvable nest prefix with the two-argument route path.
  4. Do not collect one-argument path(pattern) predicates as standalone routes.

Related issues / duplicate check

#416 (closed) mentioned generic path routes, but the current route list still omits this overload: this report tracks the remaining gap. #576 / PR #605 concern nest-prefix extraction; #580 concerns Java builder callback traversal and must remain separate.

Searched all issue states using Router DSL path handler, two-argument path route, any method router path, and "path" "handler" "missing". No separate open issue for this remaining Kotlin route-overload gap was found.

Dominant language
Kotlin
Stars
163
Forks
16
Avg merge
5h 35m
Merged PRs (30d)
183

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from explyt/spring-plugin

All issues in explyt/spring-plugin

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.