aglinxinyuan opened a new issue, #7438:
URL: https://github.com/apache/texera/issues/7438
### Task Summary
`ExecutionConsoleServiceSpec` covers the `ConsoleMessageProcessor` object;
the `ExecutionConsoleService` class around it is untouched. That class owns
three things the frontend depends on:
1. **The console diff.**
`info.consoleMessages.diff(oldConsole.consoleMessages)` — the frontend appends
what it is sent, so emitting the whole buffer instead of the delta duplicates
every earlier line on each update.
2. **Worker-to-operator keying.** A `ConsoleMessage` arrives tagged with a
worker id carrying the physical layer and worker index; the console is keyed by
`logicalOpId`. Anything else strands the output where the frontend will not
look for it.
3. **The debug-command handler.** Attribution as `"USER-" +
uidOpt.getOrElse("UNKNOWN")`, the message filed under the *operator* while the
coordinator call carries the *worker*.
All of it is reachable with no infrastructure: an empty-plan `AmberClient`
subclass that captures the `registerCallback[ConsoleMessage]` handler, a mocked
`CoordinatorServiceFs2Grpc`, and a real `ExecutionStateStore` +
`WebsocketInput`. `ExecutionRuntimeServiceSpec` already establishes that
harness.
Out of scope: `getOrCreateWriter` and the execution-state commit loop are
`private` and Iceberg-bound, and should stay uncovered rather than be padded
with a no-throw test.
Note for whoever picks this up: the console store's event observable replays
on subscribe, so subscribe first and assert on the batch published for the
*second* message — that is what shows the delta.
### Task Type
- [ ] Refactor / Cleanup
- [ ] DevOps / Deployment / CI
- [x] Testing / QA
- [ ] Documentation
- [ ] Performance
- [ ] Other
--
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]
