[Feature/Bug] ASP.NET Core attribute routing ([HttpGet], [HttpPost], [Route]) not extracted — server-side Route nodes missing for controller-based .NET APIs

[omercakmakci]

Version

codebase-memory-mcp 0.9.0

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

Indexing an ASP.NET Core 8 solution that uses controller-based attribute routing produces zero server-side Route nodes. Every Route node in the graph comes from the client side (axios/fetch call sites and test mocks), so cross-service HTTP linking (HTTP_CALLS) never matches and trace_path across the HTTP boundary always returns empty. Minimal API style (MapGet/MapPost) works; attribute routing does not — and controller-based routing is the dominant style in real-world ASP.NET Core codebases.

Expected: a Route node per controller action (e.g. POST /api/v1/auth/login for the snippet below), matchable against client call sites.

Root cause (from reading main): the C# attribute AST traversal already works — internal/cbm/extract_defs.c handles the C# attribute_list wrapper (~line 1741) and the lang spec registers cs_decorator_types, so [HttpPost("login")] IS found and passed into the annotation-route path. The failure is in annotation_route_method() (extract_defs.c, ~line 1275): it only recognizes Spring names (GetMapping, PostMapping, RequestMapping, ...) and bare JAX-RS verbs, so HttpGet/HttpPost/HttpPut/HttpDelete/HttpPatch/Route all return NULL and no route is emitted. Server-side C# detection in service_patterns.c (~lines 365-367) covers only minimal APIs, which is why those work.

Suggested fix, step 1 (small): extend annotation_route_method() with HttpGet→GET, HttpPost→POST, HttpPut→PUT, HttpDelete→DELETE, HttpPatch→PATCH, HttpHead→HEAD, HttpOptions→OPTIONS, Route→ANY. Path extraction should already work via the existing extract_route_path_from_args() walk, since [HttpPost("login")] carries the path as the first string argument, same shape as @GetMapping("/orders").

Step 2 (slightly larger): compose the class-level [Route("api/v1/[controller]")] prefix with the method template — join_route_paths() looks reusable; the ASP.NET-specific part is substituting the [controller] token with the class name minus the "Controller" suffix. Even without token substitution, emitting method-level routes joined to a literal class prefix would enable partial matching against client call sites — much better than the current zero coverage.

Related but separate: ingest_traces currently returns "Runtime edge creation from traces not yet implemented", so there is no manual workaround to inject the missing edges either. Happy to file that separately if useful, and happy to test a build against a real-world ASP.NET Core 8 + React monorepo and report back.

Reproduction

1. Code — dummy snippet (any ASP.NET Core 8 Web API project):

   [ApiController]
   [Route("api/v1/[controller]")]
   public class AuthController : ControllerBase
   {
   [HttpPost("login")]
   public async Task Login(LoginRequest req) { ... }
   }

   Public OSS test beds with the same pattern: dotnet/eShop, jasontaylordev/CleanArchitecture (controller-based attribute routing throughout).

2. Command:
   codebase-memory-mcp cli index_repository '{"repo_path":"/absolute/path/to/repo"}'
   codebase-memory-mcp cli search_graph '{"label":"Route"}'

3. Result: only client-side routes (axios/fetch/MSW-derived) are returned; no Route node exists for POST /api/v1/auth/login. trace_path across the HTTP boundary returns 0 results.
   Expected: server-side Route nodes for each [HttpGet]/[HttpPost]/... action, linkable via HTTP_CALLS.

Logs

No errors in stderr — indexing completes normally; the routes are silently absent.

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.