fix(extract): emit HTTP_CALLS for Retrofit interface methods (#2723) - #2905

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Thank you so much for this, @divakantpandey! This is a precise fix for a real graph-quality problem: a Retrofit interface describes calls the client makes, and the graph was turning each one into a served endpoint. Several things here are exactly right:

• The discriminator is well chosen. JAX-RS verbs are marker annotations with the path in a sibling @Path, so a bare verb that carries an argument is a Retrofit request. Your JAX-RS interface control test pins that the server side keeps its HANDLES.
• Reusing HTTP_CALLS with the same url_path / method properties that call-site edges carry means cross-repo matching treats these methods like any other outbound call, with no new edge type. Keeping a separate field, so every route_path consumer still means "served endpoint", is a careful choice.
• No / collapse any more: a relative path is rooted the way Retrofit resolves it against the base URL, a full URL is kept, and a constant or template with no static value yields no edge instead of a wrong one.
• The tests cover Kotlin and Java, both the sequential and the parallel path, and both incremental routes, and the Retrofit cases fail without the fix.

One request before we merge:

1. Could the Retrofit reading apply only to methods declared in an interface (a Java interface, or a Kotlin interface)? Retrofit requires service declarations to be interfaces, while some server frameworks, for example Pippo and Rapidoid, put the path inside @GET("/x") on a controller class. Today those endpoints get a Route and a HANDLES edge, and with this change they would turn into outbound calls. A test that indexes such a controller class and asserts it keeps HANDLES and gets no HTTP_CALLS would pin it. Nothing changes for any Retrofit interface.

Also, a production file this PR touches (src/pipeline/pipeline.c) changed on main after your CI run, so please merge the current main in with that change, so CI runs on the merged tree. There are no conflicts.

Thanks again for the careful work, and for leaving the same-file constant resolution for a separate change. Keeping this one focused on the direction fix made it easy to review.

Limited the Retrofit reading to methods declared in a Java or Kotlin interface, and added a control test with a Pippo-style Java controller and a Rapidoid-style Kotlin class that keep HANDLES and get no HTTP_CALLS (it fails without the gate). Also merged current main; CI is green on the merged tree.

Thank you again, @divakantpandey. Two other changes merged into main tonight and touch files this PR also changes (tests/test_pipeline.c and src/pipeline/pass_parallel.c), so we merged current main into your branch - a plain signed-off merge commit, your change is untouched - to get a fresh CI run on the exact tree that will merge. Nothing is needed from you: it merges as soon as that run is green. If you push again, please pull first so the merge commit is kept.

Thanks for merging main in and for the quick review. I've pulled the merge commit locally, so anything I push later will build on it.

Merged - thank you very much, @divakantpandey! This round was exactly what we hoped for.

• The interface-only gate is right for both languages: a Java interface, and a Kotlin declaration spelled with the interface keyword. We also tried it on nested interfaces, a Kotlin interface inside an object, fun interface, and internal and sealed interfaces (all read as Retrofit requests), and on an abstract class and a class implementing a Retrofit interface (both keep their served routes). It held in every case.
• The new control test is a good one: a Pippo-style Java controller and a Rapidoid-style Kotlin class, on both the sequential and the parallel path, asserting the exact HANDLES set and no HTTP_CALLS. We checked that it fails when the gate is taken out, so it really pins the behaviour.
• Merging main in cleanly and turning the review around within a day made this easy to land. Thank you also for updating the JAX-RS control's comment to match.

Retrofit clients now show up in the graph as the outbound calls they are, and they match their servers across repositories like any other HTTP call. Thanks again for the careful work on #2723!

Thanks for the thorough review and for testing the gate on all those interface variants, that was reassuring to see. Glad it landed. I may pick up the same-file constant resolution as a follow-up.

Thank you @DeusData for sharing your feedback and merging this :)