Paginación de wiki_lint_contradictions
Contexto y motivación
El run 24832185988 (primer run real del lint consolidation en modo full) falló con 77/77 pares con el error:
Too many subrequests by single Worker invocationCF Workers impone un límite de 50 subrequests por invocación (plan free) / 1000 (plan paid). Con 77 pares, cada par requiere al menos 2 subrequests (fetch snippet A + fetch snippet B), lo que supera el budget incluso con chunking de snippets.
El refactor previo de snippets en chunks no era suficiente: todo el scan en una sola invocación excede el presupuesto.
Cambios introducidos (commit de47c6f)
1. Handler wikiLintContradictions (functions/api/mcp/handlers/wiki.ts)
| Antes | Después |
|---|---|
maxTotalPairs cortaba allPairs durante la construcción (break buildPairs) | allPairs se construye completo (sin corte). Se pagina después con slice |
Sin parámetro offset | Nuevo offset (default 0): primer par a procesar |
max_total_pairs = límite global de la invocación | max_total_pairs = batch size (pares procesados en este slice) |
| Response sin cursor | Response añade total_pairs_available, next_offset, offset, batch_size |
Log D1: "pairs=N contradictions=M" | Log D1: "offset=O batch=N/Total contradictions=M" |
Nuevo flujo de paginación en el handler:
// Fase 1: construir allPairs SIN cortar por límite
for (const [group, list] of byCommunity.entries()) {
// ... candidatePairs[:maxPairsPerCommunity]
allPairs.push(...);
}
// Paginar
const totalPairsAvailable = allPairs.length;
const pageSlice = allPairs.slice(offset, offset + batchSize);
const nextOffset = offset + pageSlice.length < totalPairsAvailable
? offset + pageSlice.length
: null;
// Fases 2-4 operan sobre pageSlice, no sobre allPairs2. Declaración MCP (functions/api/mcp/tools.ts)
max_total_pairs: descripción actualizada — ahora documenta semántica de batch size y paginación.- Nuevo campo
offset: documentado con instrucción explícita de uso junto anext_offset.
3. Workflow CI (wiki-lint-consolidation.yml)
Antes: llamada única al MCP → resultado directo.
Después: loop bash con cursor paginado:
OFFSET=0
BATCH=0
while [ "$BATCH" -lt "$MAX_BATCHES" ]; do
BATCH=$((BATCH + 1))
# llama MCP con offset=$OFFSET, max_total_pairs=$BATCH_SIZE
# acumula /tmp/batch-$BATCH.json
NEXT=$(echo "$RESULT" | jq -r '.next_offset')
[ "$NEXT" = "null" ] && break
OFFSET=$NEXT
sleep 2
done
# Combina todos los batches en /tmp/lint-consolidation.jsonInputs renombrados:
| Input antiguo | Input nuevo | Default |
|---|---|---|
max_total_pairs (límite global, 200) | batch_size (tamaño por invocación, 30) | 30 |
| — | max_batches (safety cap) | 20 |
Timeout: aumentado de 20 min a 30 min para acomodar múltiples llamadas.
Artifact final: combina todos los batches con jq -s '.[0] + .[1].results' en un único JSON que incluye batches_run, total_pairs_available, y el array consolidado de results.
Compatibilidad y migración
Sin migración necesaria. El cron diario (incremental) no especifica
max_total_pairsy usa el default (100). En modo incremental el número de pares suele ser bajo, por lo que no supera el budget. El cambio semántico solo afecta a llamadas explícitas en modofullque pasaranmax_total_pairscon intención de límite global — estas deben revisarse y reinterpretarse como batch size.
Parámetros del workflow (post-cambio)
| Parámetro | Descripción | Default |
|---|---|---|
apply | Si true, inserta contradicciones en D1 | false |
max_pairs_per_community | Límite de pares por comunidad (MCP) | 20 |
batch_size | Pares por invocación MCP (respeta budget CF Workers) | 30 |
max_batches | Cap de seguridad de iteraciones del loop | 20 |
Con los defaults: hasta 20 × 30 = 600 pares procesables por run, con 2 s entre batches (~40 s de latencia pura en 20 batches).
Entidad relacionada
Ver [[entity—biblioteca—tool—wiki-lint-contradictions]] para la referencia completa del contrato MCP (parámetros, response, arquitectura interna).
Véase también
- [[entity—biblioteca—tool—wiki-lint-contradictions]]