C#: log calls inside Kafka-consumer classes misclassified as Route nodes; ASP.NET Core [Route]/[HttpGet] attribute routes not extracted (cross-repo-intelligence returns 0 edges)

[shatulsky]

Summary

On a large C# monorepo (~14.5k files, ASP.NET Core + Confluent.Kafka), index_repository (mode full, v0.10.5) produces two related but distinct Route-extraction defects that together make cross-repo-intelligence unusable: it returns 0 cross-repo edges even where real HTTP call chains between two indexed projects exist.

1. Ordinary log calls inside Kafka-consumer classes get misclassified as __route__kafka__ Route nodes.
2. Real ASP.NET Core [Route]/[HttpGet] controller-attribute routes are not extracted at all, despite the underlying attribute/decorator parsing clearly working (the method has DECORATES edges for other things in the same graph).

Repro 1 — false-positive Kafka routes from ordinary log calls

File: Servers/ActivitiesService/Logic/MessageFilters/MessageFilterHelper.cs:306

catch (Exception ex)
{
    m_Logger.LogError("Can't get Account for account ID {0}: {1}", accountId, ex.Message);
}

This is a plain ILogger.LogError call — nothing Kafka- or route-related. After indexing, search_graph(label="Route", name_pattern=".*(GET|POST|PUT|DELETE|api/).*") returns dozens of nodes like:

__route__kafka__Can't get Account for account ID {0}: {1} Route  0 0
__route__kafka__Can't get Asset for asset ID {0}: {1} Route  0 0
__route__kafka__Failed to send EndOfDayQuotesSaved, exception: {0} Route  0 0

680 total Route nodes in this repo, the overwhelming majority of which are log-message strings misclassified this way (also affects __route__hangfire__).

Root cause hypothesis (traced in source)

cbm_service_pattern_match(resolved_qn) (internal/cbm/service_patterns.c:789) correctly recognizes Confluent.Kafka as an async library (service_patterns.c:191), and only fires based on the resolved qualified name of the callee, not textual/file proximity — this part looks correct by design.

The actual defect appears to be upstream of that: the call-target resolver for m_Logger.LogError(...) inside a class that also handles Kafka messages is producing a resolved_qn that matches the async/Kafka pattern table, instead of resolving to Microsoft.Extensions.Logging.ILogger.LogError. That points to a call-resolution bug in the C#/Hybrid-LSP layer (wrong overload/symbol picked, possibly a fallback that matches by method name across unrelated types) rather than an intentionally-broad heuristic in extract_channels.c/pass_calls.c.

Repro 2 — real ASP.NET Core [Route]/[HttpGet] routes never extracted

File: Servers/AutochartistsDataFeeder/API/Controllers/QuotesController.cs

[ServiceFilter(typeof(ClientIpCheckFilter))]
[Route("api/[controller]")]
[ApiController]
public class QuotesController : ControllerBase
{
    [HttpGet("{symbol}")]
    public async Task<IActionResult> Get(string symbol, [FromQuery] QuotesInputDto queryStringData) { ... }
}

After indexing, search_graph(qn_pattern=".*QuotesController\\.QuotesController\\..*", include_connected=true) shows the Get method exists correctly with its call graph (Error, Ok, RetreivePeriodData), but zero edges connect it to any Route or Decorator node representing [HttpGet("{symbol}")]. This is despite DECORATES edges existing 13,964 times elsewhere in the same graph, so attribute/decorator extraction is clearly functional in general — it's specifically not wired up for this ASP.NET Core attribute-routing shape.

Confirmed this isn't a stale-index artifact: re-ran index_repository (same full mode) from scratch and got byte-identical results both times.

I found #292 (protocol-aware cross-repo intelligence design) states ASP.NET Core [HttpGet("/x")] controller-side attribute routing is already supported (only Refit/typed-client producer-side routing is listed as a future Tier 3 gap). This repro suggests that support has a gap — or a regression — for this particular attribute stack ([ServiceFilter(...)] + [Route("api/[controller]")] + [ApiController], with the [controller] token placeholder).

Impact

Both bugs compound: index_repository(mode="cross-repo-intelligence", target_projects=["*"]) across 8 indexed projects (one of which is this backend) returns total_cross_edges: 0 — not because no real HTTP links exist between the indexed client and server projects, but because the Route index has no valid signal to match against (real routes missing, fake routes are log-message noise).

Environment

• codebase-memory-mcp 0.10.5, Windows amd64, installed via install.ps1
• Repo: large multi-service C#/.NET monorepo (~14.5k files across ~40 deployable services), mixed net48/net8.0 TFMs, ASP.NET Core Microsoft.NET.Sdk.Web hosts + Confluent.Kafka for messaging
• Indexed with index_repository(mode="full"), confirmed reproducible across two independent full re-indexes

What I checked before filing

• .codebase-memory.json (only supports extra_extensions), docs/CONFIGURATION.md, and env vars — no config surface exists to tune Route/Channel/Decorator heuristics
• Confirmed the file/class/method themselves ARE indexed (ruling out a gitignore/skip-list exclusion) — only the Route/Decorator edge is missing

[DeusData]

Thank you for separating measured behavior from the root-cause hypotheses. The source supports treating this as two real defects under one cross-repository symptom:

1. Service classification consumes the resolved callee qualified name. A normal ILogger.LogError becoming a Kafka route therefore means the resolver supplied a wrong service-shaped target upstream.
2. The current regression suite explicitly records C# attribute-to-DECORATES extraction as unimplemented, so the missing ASP.NET attribute route is a real coverage gap rather than stale index state.

We will keep this issue as the umbrella because the two failures compound into zero cross-repository edges, but implementation should arrive as two atomic fixes with separate failing cases. This is routed as a high-priority graph-quality bug. Thank you for the public-shape reproduction and for not overclaiming access to the private repository.

[DeusData]

Fixed on main by 5b8217d (PR #1759, thank you @Jumaga2015): every attribute_list sibling is scanned now, so stacked C# attributes such as [HttpPost] + [Route(...)] are all seen and the ASP.NET Core attribute routes are extracted. Ships in v0.10.9.

That covers the attribute-route half of this report. The other half — log calls inside Kafka-consumer classes being classified as Route nodes — is not addressed by that change; if you can still reproduce it on main (or on v0.10.9 once it is out), a small snippet showing one misclassified call would let us pin it separately. Leaving this open until that is settled.