Files
zerogravity/docs/standalone-ls-todo.md

88 lines
3.5 KiB
Markdown

# Standalone LS for Proxy Isolation
## Goal
Route ALL proxy traffic through a standalone LS instance instead of the real one,
so development/testing/proxying never interferes with active coding sessions.
## Current State
The proxy currently talks to the **real** LS spawned by Antigravity.
This is risky — a bad cascade or proxy bug can disrupt the coding conversation.
## What Works
- Standalone LS starts fine with custom init metadata via stdin protobuf
- Connects to the main extension server (`-extension_server_port`)
- Accepts cascade requests (returns cascadeId)
- With `detect_and_use_proxy = ENABLED` (field 34 = 2), honors `HTTPS_PROXY`
## What Doesn't Work
- **Cascades silently fail** — the LS accepts the request but never processes it
- No planner invocation, no upstream API call, no logs beyond startup
- 9 lines of log after 40s wait
- Main LS logs show zero trace of the standalone's cascade
## Suspected Blockers (investigate in order)
1. **Auth context** — standalone may not receive OAuth token from extension server
- Check: does the standalone's `GetUserStatus` return valid auth?
- The extension server might only share tokens with the "primary" LS
2. **Unleash feature flags** — cascade processing gated by flags the standalone doesn't fetch
- The standalone connects to Unleash via the proxy, but might not get the right flags
- Check: compare Unleash responses between main and standalone
3. **Workspace indexing** — planner might require indexed workspace state
- The standalone's workspace (`/tmp/antigravity-standalone`) is empty
- Try: point it at a real workspace with actual files
4. **Extension server coupling** — cascade might need the extension to "drive" it
- The chat panel in the extension might send additional RPCs to progress the cascade
- Check: trace what RPCs the extension sends after StartCascade
## Investigation Plan
```bash
# 1. Launch with max verbosity
echo "$METADATA" | base64 -d | \
timeout 90 "$LS_BIN" \
-v 5 \
-server_port 42200 \
... > /tmp/standalone-verbose.log 2>&1 &
# 2. Check auth status
curl -sk "https://127.0.0.1:42200/exa.language_server_pb.LanguageServerService/GetUserStatus" \
-H "Content-Type: application/json" \
-H "x-codeium-csrf-token: $CSRF" \
-d '{}'
# 3. Send cascade and watch logs in real-time
tail -f /tmp/standalone-verbose.log &
curl -sk "https://127.0.0.1:42200/.../StartCascade" ...
# 4. Compare Unleash flags
# Main LS unleash vs standalone unleash
```
## Key Technical Details
- Init metadata protobuf field 34 = `detect_and_use_proxy` (enum: 0=UNSPECIFIED, 1=ENABLED, 2=DISABLED)
- Model IDs: M18=Flash, M8=Pro-High, M7=Pro-Low, M26=Opus4.6, M12=Opus4.5
- LS binary: `/usr/share/antigravity/resources/app/extensions/antigravity/bin/language_server_linux_x64`
- API endpoint: `daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent?alt=sse`
## New Leads (from binary analysis)
- **`GetUnleashData`** — LS method to fetch Unleash flags directly. Could compare
main vs standalone to check if flags differ.
- **`GetStaticExperimentStatus`** / `SetBaseExperiments` / `UpdateDevExperiments`
experiment management. Standalone might be missing experiment overrides.
- **`FetchAdminControls`** — admin-level controls that might gate cascade execution.
- **`LoadCodeAssist`** — initialization step that might be required before cascades work.
- **`GetUserStatus` vs `GetUserMemories`** — check if standalone has auth context
by calling both.
→ See `docs/ls-binary-analysis.md` for full RPC method catalog.