🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== workflow excerpt =="
sed -n '1,90p' .github/workflows/build-release.yml 2>/dev/null || true

echo "== workflows in repo =="
git ls-files .github/workflows

Repository: netlify/humio-mcp-build-lambda

Length of output: 2068

🌐 Web query:

softprops/action-gh-release v1 Node 20 runner support actionlint cannot run

💡 Result:

The softprops/action-gh-release action has officially moved to Node 24 support with the release of version 3.0.0 [1][2]. Node.js 20 actions are deprecated on GitHub Actions [2], and starting June 2, 2026, actions are being forced to run on Node.js 24 by default [2]. If you are encountering issues or receiving deprecation warnings, you should upgrade your workflow to use the latest version of the action [1][2]. 1. Update your workflow: Change your usage from softprops/action-gh-release@v1 or @v2 to softprops/action-gh-release@v3 [3][4][5]. 2. Actionlint compatibility: If you receive errors from actionlint regarding the action, ensure you are using a recent version of actionlint. Actionlint typically validates workflow syntax against current GitHub Actions runner environments and specifications [6][7]. If the error persists, it may be due to cached metadata or a configuration issue in your repository, rather than a failure of the action itself to run [8][9]. Version v2.6.2 remains available if you absolutely require a final Node 20-compatible version, but migration to v3 is strongly recommended due to the deprecation of Node 20 [5].

Citations:

• 1: softprops/action-gh-release@b430933
• 2: release: cut v3.0.0 for Node 24 upgrade softprops/action-gh-release#670
• 3: https://github.com/softprops/action-gh-release?tab=readme-ov-file
• 4: https://github.com/marketplace/actions/gh-release
• 5: https://github.com/fourcels/action-gh-release/blob/4dd30955cca228da305ffee6fbc3fc1f95d447c2/CHANGELOG.md
• 6: https://github.com/rhysd/actionlint/blob/v1.7.12/docs/checks.md
• 7: https://github.com/rhysd/actionlint/blob/main/docs/checks.md
• 8: https://github.com/rhysd/actionlint/blob/main/README.md
• 9: https://github.com/rhysd/actionlint/tree/refs/heads/main

• build_layer.sh#L46-L47 (this comment)
• build_layer.sh#L61-L67
• .github/workflows/build-release.yml#L18-L21

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== repo files relevant =="
git ls-files | rg '(^|/)(build_layer\.sh|humio-query-config(\.example)?\.json|package\.json|README\.md)$' || true

echo
echo "== build_layer.sh outline/sections =="
wc -l build_layer.sh
sed -n '1,180p' build_layer.sh
echo

echo "== example config =="
if [ -f humio-query-config.example.json ]; then
  cat -n humio-query-config.example.json
fi
echo

echo "== config references in repo =="
rg -n "humio-query-config|HUMIO_QUERY_CONFIG|banana|team|JsonConfigProvider|dist/humio/config" . --glob '!node_modules' --glob '!dist' || true

Repository: netlify/humio-mcp-build-lambda

Length of output: 5140

🌐 Web query:

islam3zzat humio-mcp humio-query-config.example.json banana team

💡 Result:

The references to humio-query-config.example.json and the "banana team" are associated with a specific implementation of a Humio Model Context Protocol (MCP) server created by user islam3zzat [1]. This MCP server is designed to allow LLMs or other clients to execute pre-defined queries against Humio (Falcon LogScale) [1]. The humio-query-config.example.json file serves as a template that users populate to define the queries available to the server [1]. The "banana team" example included in this template demonstrates how to structure query configurations, specifically filtering for logs associated with a team label and grouping the results [1]. Key details regarding the humio-query-config.json structure include [1]: - name: A unique identifier for the query. - description: A human-readable explanation of the query's purpose (e.g., "Finds critical errors for the banana team"). - query: The actual Humio query string, which may include placeholders for variables (e.g., {{variableName}}). - fields: An array of fields to extract from the query results. - outputTemplate: A string template for formatting the results, often using placeholders for the extracted fields. - joinString: A separator used when multiple results are combined. - variables: A list of definitions for any parameters required by the query, such as type and requirement status. Users typically initialize their configuration by copying the example file: cp humio-query-config.example.json humio-query-config.json [1]. Other Humio MCP implementations exist (e.g., by weihong-xu-hpe), but they often use different configuration formats, such as TOML-based files [2][3][4].

Citations:

• 1: https://github.com/islam3zzat/humio-mcp
• 2: https://github.com/weihong-xu-hpe/humio-mcp
• 3: https://github.com/weihong-xu-hpe/humio-mcp/blob/main/README.md
• 4: https://lobehub.com/mcp/weihong-xu-hpe-humio-mcp

🌐 Web query:

github.com islam3zzat humio-mcp humio-query-config.example.json

💡 Result:

The file humio-query-config.example.json is a configuration template used by the humio-mcp server repository maintained by islam3zzat [1]. It serves as a schema and example for defining pre-configured queries that the Humio MCP server can expose to MCP-compatible clients [1]. Key details regarding this file and the humio-mcp project: Purpose: The humio-query-config.json (derived from the example) defines a list of available, predefined queries [1]. This allows users to store complex or frequently used Humio/LogScale queries in a structured format rather than writing raw queries repeatedly [1]. Configuration Structure: Each query entry in the JSON array requires the following fields [1]: - name: A unique identifier for the query [1]. - description: A human-readable explanation of the query's purpose [1]. - queryString: The actual Humio (Falcon LogScale) query string, which supports variables (e.g., {{variable}}) for dynamic interpolation [1]. - fields: A list of result fields to extract [1]. - outputTemplate: A string template used for formatting query results, supporting variable interpolation [1]. - joinString: A string used to join multiple formatted results [1]. Setup: To use this configuration, users typically copy the example file to the active configuration file [1]: cp humio-query-config.example.json humio-query-config.json Note: Several other "Humio MCP" projects exist (such as those by weihong-xu-hpe and bhayanak), but they typically utilize TOML-based configurations for cluster and authentication settings rather than the specific JSON-based query configuration file described in the islam3zzat repository [2][3][4][5].

Citations:

• 1: https://github.com/islam3zzat/humio-mcp
• 2: https://github.com/weihong-xu-hpe/humio-mcp/blob/main/README.md
• 3: https://github.com/weihong-xu-hpe/humio-mcp
• 4: https://github.com/bhayanak/logscale-mcp-server
• 5: https://lobehub.com/mcp/weihong-xu-hpe-humio-mcp

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== handler outline =="
ast-grep outline handler.ts || true

echo "== relevant handler section =="
cat -n handler.ts | sed -n '80,165p'

echo "== mcp process spawn/stdin usages =="
rg -n "spawn|mcpProcess|stdin|EPIPE|write\\(" handler.ts

Repository: netlify/humio-mcp-build-lambda

Length of output: 4424

🏁 Script executed (no clone):

#!/bin/bash
set -euo pipefail

echo "== EventEmmiter handling of unhandled stream errors in current Node =="
node - <<'JS'
console.log(process.version);
const stdin = process.stdin;
console.log('hasErrorListenerBefore:', stdin.listenerCount('error'));
setImmediate(() => {
  stdin.emit('error', new Error('handled later'));
  console.log('hasErrorListenerAfter:', stdin.listenerCount('error'));
});
setTimeout(() => {
  console.log('still running');
  process.exit(0);
}, 50);
setTimeout(() => {
  console.log('timeout exited');
  process.exit(0);
}, 500);
JS

echo "== ReadableStream stdin write behavior simulation =="
node - <<'JS'
const stream = require('stream');
const { ChildProcess } = require('child_process');
const p = new ChildProcess({ stdio: ['pipe', 'pipe', 'pipe'] });
console.log('stdinWritable:', p.stdin.writable);
p.stdin.once('close', () => console.log('stdin closed'));
let wrote = false, emitted = false;
try {
  const ok = p.stdin.write('x');
  wrote = ok;
} catch (err) {
  console.log('throw:' + err.constructor.name + ':' + err.message, true);
}
console.log('wrote:' + wrote + ' hasErrorListener:' + p.stdin.listenerCount('error'));
setTimeout(() => {
  console.log('emittedError:' + emitted + ' hasErrorListenerAfter:' + p.stdin.listenerCount('error'));
  if (p.stdin.listenerCount('error') === 0) process.exit(2); else process.exit(0);
}, 20);
JS

Length of output: 594

🌐 Web query:

Node.js writable stream write after child exits EPIPE unhandled error listener documentation

💡 Result:

In Node.js, an EPIPE error (Broken Pipe) occurs when you attempt to write to a writable stream (such as a child process's stdin or a network socket) after the reading end has closed [1][2]. Because Node.js handles this as an error event, an unhandled EPIPE event will cause the entire process to crash with an uncaught exception [1][2]. Key points regarding EPIPE and error handling: Mechanism of Crash: If no 'error' listener is attached to a writable stream, any error emitted by that stream—including EPIPE—is treated as an uncaught exception [1][2]. This design forces developers to explicitly manage stream errors [1]. Handling EPIPE: To prevent the process from crashing, you must attach an 'error' event listener to the writable stream [3][1]. It is common practice to check for the EPIPE error code and handle it gracefully [1]: stream.on('error', (err) => { if (err.code === 'EPIPE') { // Gracefully ignore or handle the broken pipe console.error('Remote end closed connection; ignoring EPIPE.'); } else { // Handle other types of errors throw err; } }); Contexts where EPIPE is common: - Child Processes: If you write to a child process's stdin after the process has exited or closed its stdin, the write will fail with EPIPE [4][5][6]. - Shell Pipes: When running a Node.js script in a shell pipeline (e.g., node script.js | head), the receiving process (head) may close its end early, causing the Node.js process to receive an EPIPE when it attempts to write to process.stdout [1]. Best Practices: - Always attach an 'error' listener to writable streams you interact with, especially those connected to child processes or external network sockets [1]. - For piping (a.pipe(b)), note that errors are not automatically propagated from the source to the destination [7][8]. You should attach listeners to all streams in a pipeline or use stream.pipeline to manage error propagation and cleanup automatically [7]. - Before writing, you can check the stream's state (e.g., stream.writableEnded, stream.destroyed) to avoid writing to a closed stream, although this does not eliminate the need for an 'error' listener as a safety measure [1].

Citations:

• 1: https://nodejs-errors.dev/EPIPE/
• 2: https://nodejs.org/api/errors.html
• 3: https://techqa.club/v/q/node-js-an-uncatchable-error-is-thrown-when-the-child-process-is-abruptly-closed-during-a-large-write-operation-to-it-s-stdin-stream-67296866
• 4: child_process: exec EPIPE nodejs/node#29206
• 5: EPIPE when writing to newly created child process's stdin nodejs/node#40085
• 6: writing to a child subprocess  nodejs/node#21365
• 7: https://stackoverflow.com/questions/21771220/error-handling-with-node-js-streams
• 8: https://www.bennadel.com/blog/2679-how-error-events-affect-piped-streams-in-node-js.htm

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.