cross-repo-intelligence returns 0 edges for a byte-identical call/route

[azuttre]

I may be missing a required input here, so this is partly a question.

Running index_repository with mode=cross-repo-intelligence and an explicit target_projects, where the consumer has an HTTP_CALLS edge whose url_path is byte-identical to a provider's served Route name (/v2/orders/{id} on both sides), returns projects_scanned: 1, total_cross_edges: 0. I could not get the pass to emit a single cross edge under any input I tried, including this identical-string case. On a larger multi-service codebase it also returned 0 across all categories (http/grpc/async/channel).

My actual question: what is the minimum a call and a route need to share to be linked? If the matcher needs more than a matching path (a method, a confidence value, a node property the extractor sets), I could not find it in the docs.

Repro (self-contained): https://gist.github.com/azuttre/21e5e85f7590261721e3af7aa079dbfb → issue-3-cross-repo-zero-edges.sh

Related note, possibly the cause: the route/call extractor did not produce Route or HTTP_CALLS nodes from the minimal gin, FastAPI, and Express services I tried. A @app.get(...) decorator was captured but no route. That is why the repro inserts the nodes directly, to give the matcher unambiguous input. If that minimal-extraction gap is expected (for example it needs resolvable dependencies), I would value a pointer.

Env: v0.8.1, macOS (arm64).

[RithvikReddy0-0]

Spent a while reproducing this from a source build. Short version: the matcher is doing what it's supposed to : the zero edges come from two separate things upstream of it, and the one that actually bites you ("0 across all categories on a real codebase") isn't the matcher at all.

1. Why the repro returns 0

The matcher never looks at a Route's name. For each HTTP_CALLS edge it pulls url_path + method from the edge props, rebuilds the Route QN as __route__<METHOD>__<url_path>, and looks that up:

qualified_name = ? AND label = 'Route'   -- with a __route__ANY__… fallback

Your inserted Route has qualified_name = 'route:/v2/orders/{id}', so the lookup misses even though the name strings are byte-identical. To match by hand the Route would need to be QN'd __route__GET__/v2/orders/{id}.

2. The extractor is fine for providers

A real decorator service does produce routes. I indexed:

@app.get("/v2/orders/{id}")
def get_order(id): ...

and got a Route node __route__GET__/v2/orders/{id} plus a HANDLES edge from get_order. The def handler(): pass files in issue-3 have no decorator and no call, so they produce nothing — which is correct, not a bug.

3. The real cause: consumer HTTP calls get dropped unless the client lib is indexed

This is the one that matters. On a normal repo, requests.get("http://order-service:8080/v2/orders/123") produces no edge at all not HTTP_CALLS, not even a plain CALLS.

In pass_calls.c::resolve_single_call, a call only becomes an edge if its callee resolves to a node that already exists in the graph (cbm_gbuf_find_by_qn returns non-NULL). requests is an external dep whose source isn't indexed, so the call is thrown out before it ever reaches HTTP classification.

Confirmed it by dropping a local requests/__init__.py stub into the repo the HTTP_CALLS edge shows up immediately. That's why a real multi-service codebase, where every HTTP client is a pip/npm dependency, returns 0 across http/grpc/async/channel.

4. And even once the edge exists, a second mismatch

When an HTTP_CALLS edge is created, its url_path is the full URL (http://order-service:8080/v2/orders/123), but the provider Route is the bare templated path (/v2/orders/{id}). The matcher does an exact-string QN lookup — no host stripping, no path-param normalization so 123 vs {id} and the scheme/host/port both block the match.

---

So the minimum to link two services today is pretty narrow: a consumer HTTP_CALLS edge whose url_path is byte-identical to the provider Route path, plus a provider Route QN'd __route__METHOD__path with a HANDLES edge. In practice that only lines up if the HTTP client is vendored into the consumer and both sides use identical literal paths.

Happy to split (3) into its own issue it's the actual blocker for the real-world case and it's independent of the matcher. I can also take a crack at a fix if that's welcome.

[azuttre]

Thanks, this is a thorough write-up. You're right on the QN: my inserted Route used route:/v2/orders/{id}, not __route__GET__/v2/orders/{id}, so the lookup was never going to hit. That one's on me.

3 and 4 are the useful part. On the real multi-service codebase I was testing the consumer side did produce HTTP_CALLS edges, so what bit me was 4: the call's url_path carried a different version prefix and param style than the provider route, and the exact QN lookup never matched. Both causes are real, just showing up on different repos.

Yes, splitting 3 into its own issue makes sense, it's independent of the matcher and it's the one that silently returns 0 on a normal repo. A fix for either would be very welcome, and I'm happy to test whatever you land.

[RithvikReddy0-0]

Hey @azuttre , so I worked on it, I opened the 536 which is covering the 3 root causes : 1, the Unindexed Client Lib Drops
2, URL normalization
3, reverse-direction matching

[DeusData]

Thanks guys for the analysis. Will review ASAP