tsouth89/toolport

What problem does this solve? Toolport's downstream HTTP MCP client (ureq) uses a hardcoded 30-second request timeout with no way to configure it. Long-running MCP tool calls (e.g. image or video generation taking 60s+) are dropped at ~30s even when both the upstream client and the downstream MCP server have longer timeouts configured. Proposed solution Expose the downstream request timeout as a configurable setting — ideally per-server in the registry (e.g. a requestTimeoutMs field on the server entry) or a global TOOLPORT_* env var — so slow billable tools can opt into a longer deadline. Alternatives considered Create async tools with polling to overcome timeouts. This is achievable with custom MCP servers, but not remote hosted servers. Which clients or servers does this involve? Any MCP server with long-running tool calls

Problem Code mode (toolport_run_script) runs an untrusted script in an embedded JS interpreter. Limits (src-tauri/src/codemode.rs:113-124) bounds everything except allocation: Limits { max_calls: 64, wall_clock: Duration::from_secs(60), max_parallel: 8, max_promise_jobs: 100_000, loop_iteration_limit: 10_000_000, recursion_limit: 400, } Those bound time and iteration count, not bytes. A script can allocate arbitrarily in very few iterations: let a = [1]; for (let i = 0; i < 30; i++) a = a.concat(a); // ~1G elements, 30 iterations That is far under loop_iteration_limit, never yields to the promise-job executor, and never reaches a host-call reserve, so no existing limit fires. The wall clock is only checked at host-call reserve and between jobs (codemode.rs:962-971, :160), so it never gets a chance either. Rust OOM is an abort, not a catchable error, so the process dies. There is also no size cap on the submitted script. src-tauri/src/bin/toolport-gateway.rs:60

Problem The Test button is disabled while test.status === "testing". But every keystroke calls clearTest(), which resets any non-idle status back to "idle" — including "testing". It does not distinguish "a stale result exists" from "a test is in flight", and nothing cancels or tags the pending testServer call. So editing a field during a test re-enables the Test button while the first request is still outstanding, and there is no request-generation guard to discard a late response. Where: src/components/ServerDialog.tsx:101-103 (clearTest) src/components/ServerDialog.tsx:501 (the disabled gate) Callers: set() and setEnvRow() Failure scenario A user clicks Test on a working config. While it is in flight they edit the command to something broken, which flips the status back to idle and re-enables the button. They click Test again. The first call, made against the working config, resolves after the second and writes { status: "ok", message: "Connected. Found N tools." }. The dialog no

Problem handleSave calls addServer/updateServer first, then loops over declared secrets calling setSecret for each. If a setSecret throws after the server was already created, control lands in the single catch, which shows Couldn't save <name> and nothing else. onSaved(result) is never called, so the parent's registry state never learns the server exists, and the dialog stays open with entry.id still "". Where: src/components/ServerDialog.tsx:260-278 Failure scenario A user adds a server with two env secrets. The server is created, the first setSecret succeeds, the second throws because the keychain is locked. The user sees "Couldn't save X" and believes nothing happened. In fact the server exists and one secret is vaulted. They click Save again; because this is not edit mode, addServer runs a second time and creates a duplicate server entry. Acceptance criteria A failure after the server was created is reported as a partial success, naming what did and did not happen. The parent is

Problem bump_secrets_generation discards the result of write_registry. Per its own doc comment, that write is the sole mechanism that makes a running gateway reload after a keychain-only change. All three callers return Ok immediately afterwards, so a failed bump is invisible to the caller and to the user. Where: src-tauri/src/desktop.rs:2961-2966 (bump_secrets_generation) Callers: set_auth_token, clear_auth_token, authenticate_oauth Failure scenario A user clicks "Clear token" to revoke a leaked bearer. The keychain delete succeeds. registry::update then fails, because the cross-process registry lock is held by a running gateway or the disk is full. The command returns Ok, the UI shows the token as removed, and the already-running gateway never reloads. It keeps serving requests with the credential the user believes they just revoked. The same path makes a fresh OAuth sign-in silently not take effect, leaving the user looking at 401s from a server they just authenticated against. Ac