feat(#849): Bridge D - 4-language HTTP trinity payload#865
Conversation
Extends the trinity round-trip from 3 legs (Rust -> Java -> Python -> Rust) to 4 legs (Rust -> Java -> Python -> C -> Rust) and adds an HTTP-using fixture function that exercises the concept hub at the API tier. Body templates added to all four canonical-bodies.json files (rust/java/python/c) for concept:http-request and concept:http-response, citing Bridge B's hub CIDs exactly. Canonical libraries per language: reqwest (Rust), java.net.http.HttpClient (Java stdlib), urllib.request (Python stdlib), libcurl (C). CID pins in substrate_default_cids.rs updated for the four new body-template files. Trinity fixture gains fetch_url_status(url) -> u16; leg 1 (Rust source -> Java realize) recognizes it as concept:http-request and emits a java.net.http.HttpClient call in the realized Java output. The C leg is wired (Java/C build helpers + manifest plumbing + dispatch) but not executed because Java lift is unavailable in this environment. Acceptance gate (fresh CARGO_TARGET_DIR): trinity_round_trip passes as v0 loudly-bounded-lossy with three loss entries - kit-plugin-unavailable (java lift), leg-3-not-reached, leg-4-not-reached. HTTP recognition asserted explicitly. Refs #849. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
WalkthroughThis PR adds HTTP request and response support across the provekit system by implementing canonical body templates for C, Java, Python, and Rust, updating the trinity round-trip integration test from a 3-leg to a 4-leg transport chain, and adding a Rust HTTP fetch function to the test fixture. ChangesHTTP request/response concepts across language implementations
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0aae9fdb05
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "concept_name": "http-request", | ||
| "emission_template": { | ||
| "kind": "verbatim", | ||
| "template": "let response = reqwest::get(${param0}).await.unwrap();\nresponse.status().as_u16() as i64" |
There was a problem hiding this comment.
await in Rust body templates
The new http-request Rust template injects reqwest::get(...).await, but Rust realization currently always wraps emitted bodies in a synchronous pub fn (function_source in implementations/rust/provekit-realize-rust-core/src/lib.rs does not emit async fn). As soon as this concept is selected, the generated Rust source is syntactically invalid (await outside async), so Rust-target realizations for http-request cannot compile.
Useful? React with 👍 / 👎.
| let java_realize_jar = ensure_java_realize_rpc_built(); | ||
| let c_realize_rpc = ensure_c_realize_rpc_built(); | ||
| let c_lift_rpc = ensure_c_lift_rpc_built(); |
There was a problem hiding this comment.
The test now unconditionally builds Java/C realize and C lift binaries before leg execution. In environments where Maven or C toolchains are absent, trinity_round_trip fails during setup even though the documented v0 path is allowed to stop early with bounded-loss gaps when later legs are unavailable. This turns an expected lossy outcome into an immediate hard failure unrelated to bind-gap behavior.
Useful? React with 👍 / 👎.
2 participants
Extends the trinity round-trip from 3 legs (Rust -> Java -> Python -> Rust) to 4 legs (Rust -> Java -> Python -> C -> Rust) and adds an HTTP-using fixture function that exercises the concept hub at the API tier. Empirical receipt for paper 21 §3 (cross-language at API tier).
What
Acceptance gate
Fresh `CARGO_TARGET_DIR` run passes:
```
trinity_round_trip: HTTP fixture recognized as concept:http-request in leg 1 Java output
trinity_round_trip: v0 loudly-bounded-lossy outcome (3 loss entries; Branch 2 per-line characterization gated until real lifters land):
[kit-plugin-unavailable] no `kind = "lift"` plugin available for source language `java`
[leg-3-not-reached] leg 3 (python->c) was not executed because leg 2 produced no translated/python/ output
[leg-4-not-reached] leg 4 (c->rust) was not executed because leg 3 was not reached
test trinity_round_trip ... ok
```
Honest claim shape
The HTTP fixture lifts and is tagged `concept:http-request` at the concept hub. The 4-leg cycle is wired for all four languages. Reaching legs 3 and 4 requires a Java lift kit, which is the structural blocker (`implementations/java/provekit-walk-java` exists but does not yet expose the bind lift RPC protocol). v0 loudly-bounded-lossy with those losses named.
Files
Refs #849.
Summary by CodeRabbit
New Features
Tests