98 lines
4.2 KiB
Markdown
98 lines
4.2 KiB
Markdown
# Known Issues & Future Work
|
|
|
|
---
|
|
|
|
## Medium
|
|
|
|
### 1. Cascade Correlation Is Heuristic
|
|
|
|
**File:** `src/mitm/intercept.rs` — `extract_cascade_hint()`
|
|
|
|
The MITM proxy matches intercepted API traffic to cascade IDs by scanning for `metadata.user_id` or `workspace_id` in the request body. If neither is found, it stores under `_latest`. Since `take_usage()` no longer falls back to `_latest`, unidentified requests will have **no MITM usage data at all**.
|
|
|
|
**Fix:** Investigate the actual request body format the LS sends for better correlation keys. Alternatively, use timing-based correlation (match MITM capture timestamp to cascade polling window).
|
|
|
|
---
|
|
|
|
### 2. Request Modification Not Implemented
|
|
|
|
**File:** `src/mitm/proxy.rs` — `modify_requests: false`
|
|
|
|
The `MitmConfig.modify_requests` flag exists and is plumbed through, but no actual modification logic is implemented. The flag is hardcoded to `false`.
|
|
|
|
**Fix:** When needed, implement request body mutation in `handle_http_over_tls()` — parse JSON, modify, reserialize, update `Content-Length`.
|
|
|
|
---
|
|
|
|
### 3. Polling-Based Cascade Updates vs Streaming RPC
|
|
|
|
**File:** `src/api/polling.rs`
|
|
|
|
We poll `GetCascadeTrajectorySteps` on a timer to check for new cascade output. The LS has a `StreamCascadeReactiveUpdates` streaming gRPC method that pushes updates in real-time. Our polling approach works but adds latency and unnecessary requests.
|
|
|
|
**Impact:** Functional but suboptimal. The streaming approach would give lower latency and less LS load, but requires maintaining a long-lived gRPC stream and handling reconnection.
|
|
|
|
**See:** `docs/ls-binary-analysis.md` → gRPC Services → LanguageServerService
|
|
|
|
---
|
|
|
|
### 4. No BYOK Model Routing
|
|
|
|
**File:** `src/api/models.rs`
|
|
|
|
The LS supports BYOK (Bring Your Own Key) variants for Claude and OpenAI models (e.g., `MODEL_CLAUDE_4_SONNET_BYOK`, `MODEL_OPENAI_COMPATIBLE`). Our proxy only exposes the 5 built-in placeholder models. Users with BYOK keys can't use them through the proxy.
|
|
|
|
**Fix:** Add a mechanism to register BYOK models at runtime (e.g., via a config file or API endpoint). The BYOK model IDs and their proto enum numbers are documented in `docs/ls-binary-analysis.md`.
|
|
|
|
---
|
|
|
|
## 🟢 Low
|
|
|
|
### 5. No Integration Tests for MITM Module
|
|
|
|
The MITM module has unit tests for protobuf decoding and intercept parsing, but no integration tests that verify:
|
|
|
|
- TLS interception end-to-end with the generated CA
|
|
- Full HTTP/1.1 request/response cycle through the proxy
|
|
- gRPC (HTTP/2) request/response cycle through `h2_handler`
|
|
- Store recording and retrieval under concurrency
|
|
- Wrapper script install/uninstall lifecycle
|
|
|
|
---
|
|
|
|
## Blockers
|
|
|
|
### 6. LS Go LLM Client Ignores System TLS Trust Store
|
|
|
|
**File:** `docs/mitm-interception-status.md`
|
|
|
|
The LS binary is a Go program whose HTTP client for LLM API calls uses a custom `tls.Config` that does **not** trust system CAs or honor `SSL_CERT_FILE`. This means our MITM proxy's generated CA cert is rejected even when properly installed system-wide.
|
|
|
|
The extension patch (`detectAndUseProxy=1`) only makes the LS honor `HTTPS_PROXY` for routing — it doesn't fix CA trust. Without this, the MITM proxy can route but not decrypt LLM traffic.
|
|
|
|
**Potential fixes:**
|
|
|
|
- Binary patching the Go TLS verification (hard, breaks on updates)
|
|
- Full standalone LS control (in progress, see issue #7)
|
|
- Network namespace + iptables redirect (eliminates HTTPS_PROXY need but doesn't fix TLS trust)
|
|
- eBPF/ptrace to inject certs at runtime (complex)
|
|
|
|
**See:** `docs/mitm-interception-status.md` for full analysis
|
|
|
|
---
|
|
|
|
### 7. Standalone LS Cascades Silently Fail
|
|
|
|
**File:** `docs/standalone-ls-todo.md`
|
|
|
|
When running a standalone LS instance (outside of Antigravity), cascades start but produce no output. The LS accepts `StartCascade` RPCs without error, but the cascade never progresses.
|
|
|
|
**Suspected blockers:**
|
|
|
|
- Missing auth context (OAuth token not properly propagated)
|
|
- Unleash feature flags differ between main and standalone instances (`GetUnleashData` returns different flags)
|
|
- `LoadCodeAssist` / `OnboardUser` initialization steps may be required
|
|
- Extension server callbacks (`WriteCascadeEdit`, `ExecuteCommand`, etc.) have no handler
|
|
|
|
**See:** `docs/standalone-ls-todo.md` for investigation plan
|