Cross-repo HTTP linking: `method:` in fetch options is not extracted, and anonymous route handlers yield no `HANDLES` edge — both silently produce zero cross edges

[vitaliy-shatskiy]

What problem does this solve?

Cross-repo HTTP linking can silently produce zero CROSS_HTTP_CALLS edges for a healthy client/server pair, with no hint of why. Bisecting a fixture pair (JS client + Express server) surfaced two sharp edges, each of which alone zeroes the result:

1. method: inside fetch's options object is not extracted. fetch(url, {method: 'POST'}) yields __route__ANY__…, and the matcher's ANY-tolerance is one-directional — a route may be ANY but a caller may not (src/pipeline/pass_cross_repo.c:476-480,627). So the most common vanilla fetch pattern can never match a method-specific route. (axios.post(...) extracts perfectly — the client side produced byte-identical canonical Route QNs on both sides.)

2. Express inline arrow handlers produce no HANDLES edge. app.post('/api/orders', (req, res) => {...}) yields only module -CALLS-> Route; the cross-repo matcher requires HANDLES, so cross edges appear only when the handler is a named function.

Rewriting the same fixture with axios.post AND named handlers immediately produced 2 verified CROSS_HTTP_CALLS edges — the machinery works; the requirements are just undiscoverable. The three simultaneous requirements (extractable method+path at the call site, identical canonical Route QN, named server handler yielding HANDLES) are documented nowhere, and discovering them cost a full one-variable-at-a-time bisection.

Proposed solution

In order of value:

1. Document the three requirements for cross-repo HTTP edges (README or the cross-repo section) — this alone saves users the bisection.
2. Extract method: from fetch options objects, so fetch(url, {method: 'POST'}) produces __route__POST__… like axios.post does.
3. Emit HANDLES for inline arrow handlers (anonymous handler → synthesize a handler node or attach HANDLES from the registering module), so the idiomatic Express style works as-is.

Alternatives considered

• Making the matcher's ANY-tolerance bidirectional (ANY caller matches specific routes) would create the edges, but at the cost of spurious method-crossed matches — extraction of the real method (proposal 2) is strictly better.
• Status quo with documentation only (proposal 1 alone) is acceptable — the current behavior is at least explainable once the rules are written down.

Confirmations

• I searched existing issues and this is not a duplicate.

[DeusData]

Thank you — reproduced, both halves, exactly as you described.

method: in fetch options is not extracted. fetch(url, {method:'POST'}) produces __route__ANY__http://… while the server route is __route__POST__/api/orders. The matcher (src/pipeline/pass_cross_repo.c) tolerates an ANY route but not an ANY caller, so that pairing can never match — which means the single most common vanilla client pattern silently yields zero cross edges.

Anonymous route handlers yield no HANDLES edge. app.post('/api/orders', (req,res)=>{}) emits only CALLS server.js → __route__POST__/api/orders, with no HANDLES, while the same route with a named handler gets one. Cross-repo linking bridges through HANDLES (src/pipeline/pass_route_nodes.c), so the idiomatic Express inline arrow handler cannot produce a cross edge either.

Both are real, and the "silently produce zero cross edges" framing in your title is the right one: there is no error, just an empty result, which is the hardest kind of wrong answer to notice.

Not fixed in v0.10.5 — that release is being cut now and I am not going to bundle a change of this size into it at the last moment. On sequencing, item 1 of your proposal (documenting the three requirements a cross edge needs) is documentation-only and can land first; extracting method: from the options object is the next piece; synthesising a HANDLES edge for inline handlers is the larger one, since it means giving an anonymous function a stable identity.

Your #1609 is fixed on main and ships in v0.10.5 — that one was a genuine blocker for the whole feature. #1610 I could not reproduce and have asked there for the real file.

(Editing this comment: two code spans were mangled when I posted it — method: and HANDLES came out blank.)