/**
 * How long the client waits for a bridge call to answer (#989).
 *
 * The client waited a flat 30 seconds for every method. Two things were wrong
 * with that, and both produce the same bad outcome: the editor completes the
 * operation, the client reports a failure, and a naive retry applies the
 * mutation a second time.
 *
 *  1. Some calls are simply long. A 190-item batch on a machine that is also
 *     compiling shaders does not finish inside 30 seconds. Callers can now pass
 *     a `timeoutMs` and be believed.
 *
 *  2. The two ends disagreed. The C++ side registers a per-handler timeout via
 *     FMCPHandlerRegistry::RegisterHandlerWithTimeout, and the game-thread
 *     executor waits that long before giving up. delete_exact_labeled_actors_in_levels
 *     is allowed 300 seconds there and was cut off by the client at 30, so the
 *     server's own limit could never be reached and its error could never be
 *     read. The client now waits at least as long as the server said it would.
 *
 * The registered timeouts are NOT advertised. get_bridge_capabilities publishes
 * the protocol version, the feature list and the registered action names, but
 * not their timeouts, so there is no way to read this off the wire from a
 * plugin that is already built. Inventing a field would mean a protocol change
 * on the C++ side. The table below therefore mirrors the registrations by hand,
 * and tests/unit/bridge-timeout-parity.test.ts parses the plugin sources and
 * fails when the two drift apart. A mirror nobody checks is worse than none.
 */
/** What a method with no registered timeout gets. Unchanged from before. */
export declare const DEFAULT_BRIDGE_TIMEOUT_MS = 30000;
/**
 * Slack added on top of a server-registered timeout, so the client outlives the
 * server's own deadline and can report the server's error instead of its own
 * guess. Without it the two expire together and the race decides which message
 * the user sees.
 */
export declare const SERVER_TIMEOUT_MARGIN_MS = 5000;
/** Upper bound on any single call, caller-supplied included. */
export declare const MAX_BRIDGE_TIMEOUT_MS = 3600000;
/** Environment override for the floor under every call, in milliseconds. */
export declare const TIMEOUT_ENV_VAR = "UE_MCP_BRIDGE_TIMEOUT_MS";
/**
 * Mirror of every FMCPHandlerRegistry::RegisterHandlerWithTimeout call in
 * plugin/, in seconds, keyed by bridge method name.
 *
 * Keep it in the order the parity test reads it: alphabetical by method.
 * External handlers registered at runtime through
 * RegisterExternalHandlerWithTimeout are not here and cannot be, since they
 * come from plugins this repo does not build.
 */
export declare const REGISTERED_HANDLER_TIMEOUT_SECONDS: Readonly<Record<string, number>>;
/** What the editor will wait for this method, in ms, or undefined for the default. */
export declare function registeredTimeoutMs(method: string): number | undefined;
/** The floor under every call: the env override when it is a usable number. */
export declare function environmentTimeoutMs(env?: NodeJS.ProcessEnv): number | undefined;
/**
 * How long to wait for `method`.
 *
 * An explicit per-call value wins outright, including a shorter one: a caller
 * that asks for less has said so on purpose. Otherwise the answer is the
 * longest of the default, the environment floor, and the server's own
 * registered limit plus its margin, so the client never gives up on a call the
 * editor is still allowed to be working on.
 */
export declare function resolveBridgeTimeout(method: string, explicitMs?: number, env?: NodeJS.ProcessEnv): number;