aglinxinyuan opened a new pull request, #7487: URL: https://github.com/apache/texera/pull/7487
### What changes were proposed in this PR? `sendMessage` held 238 of the 292 uncovered lines in `texera-agent.ts`, and the existing spec stops at the model boundary. Nothing in there actually needs the network: `ai/test` ships a `MockLanguageModelV4` satisfying the same `LanguageModel` type the constructor already takes, so the loop runs in-process. `fetch` is spied on as a tripwire, and the no-delegate tests assert that not a single call escapes. Adds 25 tests in two blocks: | Block | Covers | |---|---| | `sendMessage` | branch bookkeeping and ancestor path, per-step and summed usage, the assembled context replacing the raw message, tool projection and rolling before/after snapshots, the `maxSteps` cap, turn chaining, an abandoned branch staying invisible to the model, DAG compilation feeding schemas and cached results into the prompt | | `sendMessage` failures | a thrown model recorded as an error step, a non-`Error` throw stringified, a failed turn staying on the branch, cancellation reported as stopped, an `AbortError`-named provider error read as a user stop, `stop()` mid-run preventing the next call, `GENERATING` for the duration | | `delegate mode` | the one-time backend refresh and a failed refresh being swallowed, auto-execution after `modifyOperator` and where its result is keyed, the two guards that suppress it, `buildExecutionConfig`, and the debounced auto-persist plus its failure path | `texera-agent.ts` goes from **51.01% to 99.82% lines** (80.43% → 98.21% funcs). ### On what these tests actually pin Line coverage overstates this, and it is worth being precise. `bun` credits a whole function body once it is entered, so the first test alone takes the uncovered count from 292 to 27. Most of the remaining 24 buy no additional lines — they exist because each kills a mutation nothing else kills. They are mutation guards, not coverage. The matrix ran 44 mutations against a pristine source with a checkout-and-verify between each. Six were re-run independently after the tests were merged into the existing spec: | Mutation | Expected | Result | |---|---|---| | a tool call without `operatorId` still auto-executes | red | red | | an `[ERROR]` tool result no longer suppresses the follow-up run | red | red | | the `EXECUTE_AFTER_TOOLS` filter dropped | red | red | | input tokens not mapped | red | red | | `totalUsage` preferred over `usage` | **survives** | survives | | the `content: text \|\| ""` fallback | **survives** | survives | The last two are listed deliberately. They survive because they are unobservable in `[email protected]` — `totalUsage` and `usage` are the same object, and the SDK already hands `""` to a text-less step. No test claims to pin them, and no test was written to cement them. Five further fragments are line-covered but not behaviourally pinned, for the same reason: `lastPreparedMessages = undefined` (re-assigned before every step), `isError: !!(tr.output)?.error` (no tool ever returns an object), the `?? finalUsage?.promptTokens` / `?? completionTokens` arms (v4-era key names that no longer exist), and the delegate guard at 408–410 (masked by the catch below it). ### Deliberately not included - **`getStepsById` (line 261)** — the one line left uncovered. No call site anywhere in the repo; `server.ts` uses `getReActSteps` / `getAllSteps` / `getVisibleReActSteps`. It also hands out the live private `Map` by reference. Deleting it beats testing it, and that belongs in its own change. - **`currentMessageId`** — five writes, zero reads. An assertion on it would cement dead state. - **`maxSteps: 0`** — writing that test hangs the suite rather than failing it. Filed as #7484. Two defects surfaced while writing these and are filed rather than fixed here, since this PR touches no production code: #7484 (a `maxSteps` of 0 silently disables the step cap) and #7485 (a falsy throw from the model makes `sendMessage` reject instead of reporting an error step). No production file is touched. ### Any related issues, documentation, discussions? Closes #7486 ### How was this PR tested? ``` bun test ``` ``` 253 pass 0 fail ``` 25 new on top of the existing 228. `bun run typecheck` passes. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
