Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

BYOK connectivity and model discovery append endpoint paths after URL query parameters

Open
  • Is something wrong?
#182 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api, backend

Research direction

Start with packages/local-runtime-v2/src/service/model-system/connectivity/provider-request.ts, lines 49–91, and trace its use from connectivity testing and model discovery. Review the proposed configuration validation and the related five-file test suite, then ensure regression coverage distinguishes plain URLs, query strings, fragments, and endpoint-suffix normalization. Done means the chosen URL policy is explicit and all relevant tests pass.

Written by the indexing model from the issue text.

Description

bug needs-triage

I noticed a URL construction edge case while looking at BYOK gateway support. A base URL with a query string is accepted by the provider configuration code, but the connectivity helpers append the endpoint after the query string.

For example:

providerCompletionUrl('openai-completions', 'https://gw.example/v1?tenant=a')
// actual: https://gw.example/v1?tenant=a/chat/completions

The resulting request still has /v1 as its pathname; /chat/completions becomes part of the tenant parameter. providerModelsUrls() has the same issue with /models. A fragment has a similar effect: the appended endpoint becomes part of the fragment instead of the request path.

I checked this against source commit 33b259bbbeb1c16433390869938191d09bdb0680 on Windows, executing the URL-building functions extracted from the source after stripping TypeScript types. This is a helper-level reproduction, not a live provider or full CLI test.

Relevant code: provider-request.ts, lines 49–91. These helpers are used by the connectivity test and model discovery paths.

Would you prefer to support query parameters on gateway base URLs, or reject them when saving the configuration? Either seems reasonable, but silently turning the endpoint into query text is confusing. If query parameters are supported, the endpoint should be added to the URL pathname while preserving the query. Fragments could be rejected explicitly.

A small regression test covering plain URLs, query strings, fragments, and the existing endpoint-suffix normalization should cover this. I searched the existing issues and did not find this particular case.

Patch prepared

I've pushed a proposed fix to my fork (8b7915e). It rejects query strings/fragments before saving or using the URL, while keeping older entries readable and editable. I chose rejection because the inference SDKs have the same direct-append behavior; fixing just the probe would be misleading.

The related five-file suite passes all 266 tests, and typecheck passes. Full verification still stops at two release-tool assertions that also fail on the unchanged baseline here; the Windows build hits an existing resource-copy EIO error. I haven't run live-provider acceptance.

I tried opening a draft PR, but GitHub rejected CreatePullRequest for this account. Leaving the patch here for review under the collaborator-only contribution policy; no upstream PR has been created.

Dominant language
TypeScript
Stars
1.9k
Forks
226
Avg merge
5h 37m
Merged PRs (30d)
128

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MiniMax-AI/minimax-code

All issues in MiniMax-AI/minimax-code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.