gortiz opened a new pull request, #19002:
URL: https://github.com/apache/pinot/pull/19002
## Summary
When an MSE query fails, an `ErrorMseBlock` is created and propagated
downstream, where it is usually logged before the error reaches the user.
`ErrorMseBlock` already carries the **stage id**, **worker id** and **server
id** where the error originated (populated from `QueryThreadContext` in
`ErrorMseBlock.fromMap`), but `ErrorMseBlock.toString()` only rendered the
error messages. As a result, the log lines that print the block did not show
*where* the failure actually happened, which makes it harder to pinpoint the
offending stage/worker/host in a distributed query.
This PR surfaces the provenance that is already captured, **in the logs
only**:
1. `ErrorMseBlock.toString()` now includes `stageId`, `workerId` and
`serverId`. Every log line that prints an error block gains the provenance for
free (e.g. `QueryRunner`'s `"...sending error block: {}"`).
2. `OpChainSchedulerService`'s op-chain-failure message now includes the
stage and worker (it previously printed only the server), and falls back to
`"unknown"` when the origin could not be determined, consistent with `fromMap`.
No customer-facing error message and no wire/serialization format is changed
— the provenance was already serialized across gRPC via `MetadataBlock`; this
only affects logging/`toString()` rendering.
## Example: `QueryRunner` error log (`toString()`)
**Before**
```
Error executing stage for request: 8123456789, stage: 2, sending error
block: {"type":"error","errorMessages":{"INTERNAL":"Caught exception while
processing query"}}
```
**After**
```
Error executing stage for request: 8123456789, stage: 2, sending error
block:
{"type":"error","stageId":2,"workerId":0,"serverId":"Server_10.0.12.7_8098","errorMessages":{"INTERNAL":"Caught
exception while processing query"}}
```
## Example: `OpChainSchedulerService` op-chain failure log
**Before**
```
Failed to execute operator chain: Error block from Server_10.0.12.7_8098.
Msg: {INTERNAL=Caught exception while processing query}. Stats: {...}
```
**After**
```
Failed to execute operator chain: Error block from stage 2 worker 0 on
Server_10.0.12.7_8098. Msg: {INTERNAL=Caught exception while processing query}.
Stats: {...}
```
When the origin is undetermined (e.g. an error built outside a query thread
context), the fields render as `"stageId":-1,"workerId":-1,"serverId":null` in
`toString()` and as `from stage -1 worker -1 on unknown` in the
`OpChainSchedulerService` message.
## Testing
- New unit test `ErrorMseBlockTest` covers both the populated-provenance and
unknown-origin (`-1`/`null`) rendering of `toString()`.
- `spotless`, `checkstyle` and `license` checks pass on
`pinot-query-runtime`.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
