Close the in-game translation loop: pipe server, DLL client, drain loop

[rouges78]

The measurement in #84 settled the transport question: finish the pipe, not the shared memory. This closes the loop — a string the game shows is asked for over IPC, translated, learned, and served from the dictionary the next time it appears. Verified by injecting into a real process, not by reading code.

The three links

Rust server. translator_pipe.rs serves the wire format the shipped DLLs already embed (hook-dll/src/ipc.cpp): message-mode pipe, 12-byte header {type, requestId, dataLength}, UTF-16LE payload. It answers from the Translation Bridge's DictionaryEngine and pushes misses into the same mpsc queue translation_bridge_drain_misses drains — one dictionary, one AI-fallback queue, two transports. On a miss it stays silent by design: the DLL owns the timeout, and answering with the original would poison its local cache permanently.

C++ client. gs-hook's dllmain never called IPC::Initialize(), so the client compiled into the shipped DLLs was dormant. Waking it up exposed two real defects (below). The miss path is now fire-and-forget: the request goes out, the draw returns the original immediately, and the response lands in the cache via a receive-thread callback.

Drain loop. lib/translation-bridge-drain.ts drains the miss queue, translates with the app's AI stack, and feeds the dictionary back. Dependencies are injected so the interesting parts test without React or Tauri: a per-session translation cap (a game full of new strings is an open tap on the provider), periodic persistence, and the rule that an empty translation — or one identical to the original — is never stored, since that turns a miss into a permanently wrong hit that is never retried. save_to_dir/load_from_dir, dead since Injekt was archived, are now Tauri commands, so what the loop learns survives a restart. The overlay page also feeds its own translations back; it never did, and was re-translating the same line on every appearance.

Three bugs found by running it

Translate() blocked up to 2 s per cache miss, on the thread that draws.

The pipe handle was opened without FILE_FLAG_OVERLAPPED. On a synchronous handle the kernel serializes I/O per file object, so with the receive thread parked in ReadFile, the render thread's WriteFile queued behind it forever — and that read could only complete once the request it was blocking had arrived. Circular wait: the game froze on the first miss and the server logged a connection and zero requests. The handle is now overlapped and a dedicated sender thread owns all writes.

The DLL's dedup set had no expiry. It was only cleared by the response callback, but on a miss the server stays silent by design, so a string stayed "pending" forever and was never asked about again — the chain learned and could not tell. The pending map now carries a timestamp and a 10 s TTL, above the drain loop's ~3 s round.

Measured, injected for real

	UI responsive	DLL log	server side
before	False	3 lines, activation only	connected, 0 requests
after	True	capture intact	hits translated, misses queued

And the loop closing, with a stub provider that prefixes [IT]:

[DEBUG] translator IPC miss: "The dragon roars from the mountain."
IMPARATA → "The dragon roars from the mountain." = "[IT] The dragon roars..."
[DEBUG] translator IPC hit:  "The dragon roars from the mountain." -> "[IT] The dragon roars..."

That third line is the one that proves anything, and without the TTL it never appears. Reproduce with cargo run --example translator_pipe_server, then inject into gs-hook/testapp. SendMessageTimeout(WM_NULL, 2000ms) on the game window is what separates "slow" from "deadlocked".

Verification

cargo test --lib translator_pipe 5/5, cargo test --lib translation_bridge 22/22, vitest translation-bridge-drain 14/14, tsc --noEmit, eslint, i18n:check (802 = baseline), tauri:check-cmds, dead:check, clippy (one pre-existing warning, unrelated). Both DLL architectures rebuilt.

Traps recorded in docs/METODI-DI-TRADUZIONE.md: the overlapped-pipe deadlock (with the bisect-by-experiment method that found it in minutes after reading the code sent me the wrong way), and the dedup-without-expiry one — a dedup and a cache look alike, but a cache key eventually gets filled and a dedup entry may never be, so if the condition that clears it can fail to happen, it needs a deadline.

What is left for the one-button chain

The orchestrator: try the static path, fall back to runtime, write a per-game report. The plumbing under it now runs.

🤖 Generated with Claude Code