Performing any long running task or CPU intensive work on transport_worker threads is problematic. This is typically very bad for cluster stability.

This issue has been filed to examine the usage of transport_worked threads by ESQL, with the intention of "offloading" as much as possible, including deserialising large(ish) amounts of data.
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/enrich/EnrichLookupService.java
public void lookupAsync(
        String sessionId,
        CancellableTask parentTask,
        String index,
        String matchType,
        String matchField,
        List<NamedExpression> extractFields,
        Page inputPage,
        ActionListener<Page> listener
    ) {
        ClusterState clusterState = clusterService.state();
        GroupShardsIterator<ShardIterator> shardIterators = clusterService.operationRouting()
            .searchShards(clusterState, new String[] { index }, Map.of(), "_local");
        if (shardIterators.size() != 1) {
            listener.onFailure(new EsqlIllegalArgumentException("target index {} has more than one shard", index));
            return;
        }
        ShardIterator shardIt = shardIterators.get(0);
        ShardRouting shardRouting = shardIt.nextOrNull();
        if (shardRouting == null) {
            listener.onFailure(new UnavailableShardsException(shardIt.shardId(), "enrich index is not available"));
            return;
        }
        DiscoveryNode targetNode = clusterState.nodes().get(shardRouting.currentNodeId());
        LookupRequest lookupRequest = new LookupRequest(sessionId, shardIt.shardId(), matchType, matchField, inputPage, extractFields);
        ThreadContext threadContext = transportService.getThreadPool().getThreadContext();
        listener = ContextPreservingActionListener.wrapPreservingContext(listener, threadContext);
        try (ThreadContext.StoredContext ignored = threadContext.stashWithOrigin(ClientHelper.ENRICH_ORIGIN)) {
            
            transportService.sendChildRequest(