Problem: Direct GitHub slow/fails (scenarios depending on GitHub) —— Trove problem library

What you will run into

Within code-review-graph's build/update flows, anything touching GitHub (repo metadata, upstream resources) hangs or fails. You'd think the tool is broken, but most scenarios don't depend on GitHub at all.

Why this happens

• This marketplace's connectivity baseline (connectivity-20260828b): direct GitHub slow, raw timeouts, CN egress unstable.
• The tool's core usage is parsing local code (tree-sitter) with data in SQLite (workspace .code-review-graph/); build/update don't depend on the network.
• Only a few scenarios (repo metadata, upstream resource downloads) need GitHub.

Judging what a tool depends on can't go by appearances (the error shows up at a GitHub-related step) — follow the data flow:

code-review-graph's core input is local code (parsed with tree-sitter), intermediate artifacts live in a local SQLite database, and the output is local graph data — no step in that chain must touch GitHub, so it is essentially an offline tool.

GitHub is only involved in optional supplementary steps like "fetch metadata / download upstream resources".

That's the methodology behind "first figure out which step hangs": the stuck position decides the root cause — local parsing stuck (build stage) has nothing to do with the network (check the path and parser); download/metadata stuck is a connectivity problem.

It also yields a layered acceleration strategy: core flows don't touch the network (run offline directly), pip-type installs use a CN mirror (distribution layer), GitHub downloads use gh-proxy (content layer) — each layer has its own acceleration channel;

don't use the wrong one.

Verifying offline capability also has a fixed method: disconnect the network and rerun build; if it completes, the core flow doesn't depend on GitHub.

Step by step

1. First figure out which step hangs — Required

build/update local analysis stuck = not a GitHub problem; check the code repo path and tree-sitter parsing. Download/metadata operations stuck = GitHub connectivity.

2. Run the core usage offline — Required

code-review-graph build --repo .

Data lands in the workspace .code-review-graph/ (SQLite); no GitHub access at any point.

3. Use acceleration when network is really needed — Required

GitHub downloads via gh-proxy or another acceleration channel, or retry off-peak; pip-type installs always use the Tsinghua mirror:

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple code-review-graph

4. Verify offline capability — Required

Disconnect from the network and repeat build; if it completes, the core flow doesn't depend on GitHub.

How to confirm it works

The build flow completes and artifacts land (expected shape):

code-review-graph build --repo .
-> build completion log + graph data files generated under workspace .code-review-graph/

Install succeeded entirely via the Tsinghua mirror (measured:）.

Other environments

Symptom

Within code-review-graph's build/update flows, GitHub access (e.g. repo metadata, upstream resources) hangs or fails.

Cause

This marketplace's connectivity baseline: direct GitHub slow, raw timeouts (connectivity-20260828b); the tool's main data source is the local repo and GitHub-dependent scenarios are few, but unstable CN egress still affects them.

Solution

1. Core usage doesn't depend on GitHub: build/update parses local code (tree-sitter, SQLite in workspace .code-review-graph/), works offline.
2. When GitHub access is really needed, use an acceleration channel (gh-proxy etc.) or retry off-peak; for download operations see this marketplace's connectivity intelligence per entry.

Not measured (honest note)

• Real codex platform integration (needs a platform account); the install/init subcommand config write surfaces (not executed here to avoid polluting real config); the full build/graph-construction flow (needs a target repo and longer runtime); Windows/macOS environments; the pipx install path (officially recommended, not measured on this machine).