117 lines
3.9 KiB
Markdown
117 lines
3.9 KiB
Markdown
# Known Issues & Future Work
|
|
|
|
All fixable issues from the original report have been resolved. The remaining
|
|
items require either architectural changes, new features, or deep investigation
|
|
of the Go language server binary.
|
|
|
|
---
|
|
|
|
## 🔴 Blockers (Require Deep Investigation)
|
|
|
|
### 1. LS Go LLM Client Ignores System TLS Trust Store
|
|
|
|
**File:** `docs/mitm-interception-status.md`
|
|
|
|
The LS binary's Go HTTP client for LLM API calls uses a custom `tls.Config` that
|
|
does **not** trust system CAs or honor `SSL_CERT_FILE`. Our MITM proxy can route
|
|
traffic but not decrypt it.
|
|
|
|
**Investigation status:** All practical approaches have been tried and failed:
|
|
|
|
- iptables REDIRECT → redirect loop + broke all HTTPS traffic
|
|
- DNS redirect → same TLS trust failure
|
|
- LD_PRELOAD → Go doesn't use libc for syscalls
|
|
- SSLKEYLOGFILE → Go doesn't support it
|
|
|
|
**Remaining options (untried):**
|
|
|
|
- Binary patching Go TLS verification (fragile, breaks on updates)
|
|
- Full standalone LS control (see issue #2)
|
|
- eBPF/ptrace syscall interception (complex)
|
|
- Network namespace isolation (complex setup)
|
|
|
|
**Confidence: <30%** — all easy paths exhausted. Requires reverse engineering the Go binary's TLS setup.
|
|
|
|
**See:** `docs/mitm-interception-status.md` for full analysis
|
|
|
|
---
|
|
|
|
### 2. Standalone LS Cascades Silently Fail
|
|
|
|
**File:** `docs/standalone-ls-todo.md`
|
|
|
|
Standalone LS (outside Antigravity) accepts `StartCascade` RPCs without error
|
|
but cascade never progresses. No output.
|
|
|
|
**Suspected blockers:**
|
|
|
|
- Missing auth context (OAuth token propagation)
|
|
- Different Unleash feature flags between main and standalone instances
|
|
- Missing initialization steps (`LoadCodeAssist`, `OnboardUser`)
|
|
- Missing extension server callbacks (`WriteCascadeEdit`, `ExecuteCommand`)
|
|
|
|
**Confidence: <30%** — too many unknowns. Needs systematic debugging with the standalone LS.
|
|
|
|
**See:** `docs/standalone-ls-todo.md` for investigation plan
|
|
|
|
---
|
|
|
|
## Medium (Architecture / Future Work)
|
|
|
|
### 3. Cascade Correlation Is Heuristic
|
|
|
|
**File:** `src/mitm/intercept.rs` — `extract_cascade_hint()`
|
|
|
|
The MITM proxy matches intercepted API traffic to cascade IDs heuristically:
|
|
|
|
- HTTP/1.1 path: scans JSON body for `metadata.user_id` or `workspace_id`
|
|
- gRPC/H2 path: recursively searches proto fields for UUID strings
|
|
|
|
If neither method finds a match, usage is stored under `_latest` but never
|
|
consumed (since `take_usage()` requires exact cascade ID match).
|
|
|
|
**Confidence: <50%** — can't test without working MITM interception (blocked by issue #1). The heuristic is reasonable but unverified against real traffic.
|
|
|
|
---
|
|
|
|
### 4. Request Modification Not Implemented
|
|
|
|
**File:** `src/mitm/proxy.rs` — `modify_requests: bool`
|
|
|
|
The `MitmConfig.modify_requests` flag is plumbed through the entire call chain
|
|
but hardcoded to `false`. No modification logic exists. This is intentional
|
|
scaffolding for future use.
|
|
|
|
**Status:** Not a bug — reserved for potential request mutation features.
|
|
|
|
---
|
|
|
|
### 5. Polling-Based Cascade Updates vs Streaming RPC
|
|
|
|
**File:** `src/api/polling.rs`
|
|
|
|
We poll `GetCascadeTrajectorySteps` on a timer. The LS has a
|
|
`StreamCascadeReactiveUpdates` streaming gRPC method that pushes updates
|
|
in real-time. Polling works but adds latency.
|
|
|
|
**Status:** Functional but suboptimal. Switching to streaming requires
|
|
implementing a gRPC streaming client with reconnection handling. Not blocking.
|
|
|
|
---
|
|
|
|
## 🟢 Low
|
|
|
|
### 6. No Integration Tests for MITM Module
|
|
|
|
Unit tests cover protobuf decoding and intercept parsing (17 tests pass), but
|
|
no integration tests for:
|
|
|
|
- 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
|
|
|
|
**Status:** The MITM can't intercept real traffic anyway (blocked by issue #1),
|
|
so integration tests would be somewhat hypothetical. Worth adding when the TLS
|
|
blocker is resolved.
|