#!/bin/bash
# Description: Find all callers of drainIOThreadsQueue() and verify they have outbox guards

# Search for calls to drainIOThreadsQueue
rg -n 'drainIOThreadsQueue\(' src/ --type=c -B 10 -A 5

# For each call site, check if getPendingIOResponsesCount() is checked first
rg -n 'getPendingIOResponsesCount\|drainIOThreadsQueue' src/io_threads.c -B 5 -A 10

# Get detailed context around the two module.c calls to drainIOThreadsQueue()
echo "=== Context around line 1420 (module.c) ==="
sed -n '1400,1440p' src/module.c

echo -e "\n=== Context around line 13251 (module.c) ==="
sed -n '13230,13270p' src/module.c

# Also check for any guards or conditions in the functions calling drainIOThreadsQueue in module.c
echo -e "\n=== Check function signatures and preceding checks ==="
sed -n '1390,1425p' src/module.c | head -40
sed -n '13240,13275p' src/module.c | head -40

# Search for callers of VM_CreateCommand
echo "=== Callers of VM_CreateCommand ==="
rg -n 'VM_CreateCommand' src/ --type=c -B 3 -A 2

# Search for callers of moduleUnregisterCommands
echo -e "\n=== Callers of moduleUnregisterCommands ==="
rg -n 'moduleUnregisterCommands' src/ --type=c -B 3 -A 2

# Check module loading/unloading flow
echo -e "\n=== Module lifecycle functions ==="
rg -n 'loadModule|unloadModule|module.*load' src/ --type=c | head -20

# Find moduleLoad and moduleUnload callers to understand when they're called
echo "=== Callers of moduleLoad ==="
rg -n 'moduleLoad\(' src/ --type=c -B 3 -A 2 | head -40

echo -e "\n=== Callers of moduleUnload or moduleUnloadAllModules ==="
rg -n 'moduleUnload|moduleUnloadAllModules' src/ --type=c -B 2 -A 2 | head -50

echo -e "\n=== Check if modules can be loaded via commands ==="
rg -n 'MODULE.*LOAD|loadModule|unloadModule' src/server.c | head -20

# Look for MODULE LOAD/UNLOAD command implementation
echo "=== MODULE LOAD/UNLOAD command handlers ==="
sed -n '14550,14600p' src/module.c

# Check if there's any CLIENT PAUSE or similar synchronization
echo -e "\n=== Check for pausing or locking around module operations ==="
rg -n 'pauseClients|pauseall|pause' src/module.c | head -20

# Look at moduleUnloadInternal to see what checks it does
echo -e "\n=== moduleUnloadInternal implementation ==="
sed -n '13535,13625p' src/module.c

#!/bin/bash
set -euo pipefail

gh issue create \
  --repo "valkey-io/valkey" \
  --title "module: add outbox-guard before drainIOThreadsQueue() in VM_CreateCommand() and moduleUnregisterCommands()" \
  --body "## Summary

\`drainIOThreadsQueue()\` has a documented precondition (see [design-docs/io-threads.md](https://github.com/valkey-io/valkey/pull/4022)): callers must ensure the \`io_shared_outbox\` cannot fill while the spin is in progress, otherwise workers can stall in \`flushPendingIOResponses()\` and the drain never completes. \`updateIOThreads()\` already enforces this with:

\`\`\`c
if (getPendingIOResponsesCount() > io_shared_outbox.queue_size) { /* refuse */ }
\`\`\`

However, two module lifecycle paths call \`drainIOThreadsQueue()\` at runtime **without** this guard:

| Call site | File | Approx. line | Triggered by |
|---|---|---|---|
| \`VM_CreateCommand()\` | \`src/module.c\` | ~1420 | MODULE LOAD at runtime |
| \`moduleUnregisterCommands()\` | \`src/module.c\` | ~13251 | MODULE UNLOAD at runtime |

Because MODULE LOAD and UNLOAD are live commands that can execute while I/O is actively in flight, either call site can deadlock if the outbox fills during the drain spin.

## Required changes

In \`src/module.c\`, before each of the two \`drainIOThreadsQueue()\` calls:

1. Check \`getPendingIOResponsesCount() > io_shared_outbox.queue_size\` (or an equivalent \`pauseClients\`/pause-I/O mechanism).
2. If the condition is violated, either defer the operation and return an error to the caller, or fully drain the outbox first so the guard is satisfied before spinning.

The fix should mirror the approach already used in \`updateIOThreads()\` in \`src/io_threads.c\`.

## Acceptance criteria

- MODULE LOAD and UNLOAD no longer risk a deadlock/stall when \`io_shared_outbox\` is near capacity.
- Existing test coverage for module load/unload still passes.
- Ideally, a stress test or unit test exercises the guard path.

## References

- PR that introduced the design doc: https://github.com/valkey-io/valkey/pull/4022
- Review comment: https://github.com/valkey-io/valkey/pull/4022#discussion_r3460398103

/cc `@hpatro`"