feat(api/proxy/dashboard): device tracking + Webshare pool + basePath + HF Hub media - #236
Conversation
…gosouzapw#5992) Ports diegosouzapw#5992. Co-authored-by: SillyHippy <SillyHippy@users.noreply.github.com>
…osouzapw#5998) Ports diegosouzapw#5998. Co-authored-by: mugnimaestra <mugnimaestra@users.noreply.github.com>
…ouzapw#5993) Ports diegosouzapw#5993. Co-authored-by: ricatix <ricatix@users.noreply.github.com>
…souzapw#5990) Ports diegosouzapw#5990. Co-authored-by: yicone <yicone@users.noreply.github.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Warning Review limit reached
Next review available in: 23 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (29)
Note
|
L17 Latency Budget ReportChecked against: budgets/rest-endpoints.yaml. |
L17 Latency Regression ReportThreshold: 10% p99 regression. |
![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: 79ef889e8b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const staticModelOptions = models.length > 0 ? models : [{ id: "dall-e-3" }]; | ||
| const knownModelIds = new Set(staticModelOptions.map((m) => m.id)); | ||
| const suggestedOnly = suggestedModels.filter((m) => !knownModelIds.has(m.id)); | ||
| const modelOptions = [...staticModelOptions, ...suggestedOnly.map((m) => ({ id: m.id }))]; |
There was a problem hiding this comment.
When the HuggingFace image page adds suggestions as bare Hub repo IDs (for example black-forest-labs/FLUX.1-dev), the generated request body contains that bare value. The image route's parseImageModel checks provider prefixes first, so black-forest-labs/... is routed to the Black Forest Labs provider/credentials instead of the HuggingFace provider; selecting these suggestions will fail or hit the wrong upstream. Keep the displayed label bare if desired, but submit huggingface/${m.id} or otherwise preserve the provider context.
Useful? React with 👍 / 👎.
| const item: FreeProxyItem = { | ||
| source: "webshare", | ||
| host: p.proxy_address, | ||
| port: p.port, | ||
| type: "http", |
There was a problem hiding this comment.
For Webshare accounts using username/password direct authentication, the proxy-list API returns credentials alongside proxy_address and port, but this import only persists host/port/type. Later promotion into proxy_registry writes empty username/password for free-proxy rows, so these Webshare proxies will be unusable unless the operator has separately configured source-IP authorization. Capture and store the returned credentials, or gate this provider to IP-authorized accounts.
Useful? React with 👍 / 👎.
| if (errors.length === 0 && fetched > 0) { | ||
| await pruneStaleFreeProxies("webshare", activeKeys); |
There was a problem hiding this comment.
When Webshare returns a successful empty first page, such as after all proxies were removed or the plan is empty, this guard skips pruning because fetched is zero. That leaves previously imported, not-in-pool Webshare rows visible as candidates even though the latest account list contains none. Since this branch is not a fetch failure, treat an error-free empty sync as authoritative and prune against the empty activeKeys set.
Useful? React with 👍 / 👎.
|
1 participant
Consolidated port of four upstream diegosouzapw/OmniRoute PRs into the KooshaPari fork. Each is a self-contained commit; all applied cleanly (only CHANGELOG required manual reconciliation).
Ported PRs
OMNIROUTE_BASE_PATH, with basePath-aware auth redirects. (thanks @SillyHippy)GET /api/keys/[id]/devices+ a dashboard device-count chip. (thanks @mugnimaestra)WebshareProviderpaginatingproxy.webshare.io/api/v2/proxy/list/, gated onFREE_PROXY_WEBSHARE_API_KEY, SSRF-guarded host import, stale-ID tombstoning viapruneStaleFreeProxies(). (thanks @ricatix)Verification
npm run typecheck:core— clean./api/keys/[id]/devices,/api/v1/providers/suggested-models) are read-only GETs — no child-process spawn, noisLocalOnlyPath()classification required.src/lib/localDb.tschange is re-export only (pruneStaleFreeProxies) — Hard Rule chore: bootstrap .trufflehog.yml secrets scanning #2 compliant.