Asynchronous Report Generation
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- nextjs, typescript
- Área
- backend
Línea de trabajo
Empieza leyendo la acción de servidor submit en app/actions.tsx, incluidos processResolutionSearch, processEvents y el bucle del researcher. Compara el comportamiento actual de streaming con OPTIMIZATION_SUMMARY.md y las páginas wiki de orquestación enlazadas antes de elegir un enfoque para la cola y la persistencia. Se considera terminado cuando la generación del informe devuelve rápidamente un job ID, el trabajo en segundo plano realiza el seguimiento del estado y de los resultados intermedios, y los clientes reciben actualizaciones de progreso.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I understand you want to make report generation asynchronous so users can interact with other parts of the system while reports are being generated. Currently, the submit server action in app/actions.tsx processes requests synchronously, blocking until all agent work completes before returning 1 .
Current Blocking Behavior
The system uses streaming primitives for progressive UI rendering, but the server action itself is synchronous:
- The
submitfunction initializes streaming state but waits for all processing to complete 1 - The researcher agent runs in a synchronous loop until a non-empty response is generated 2
- Resolution search processing is called synchronously 3
- The function only returns after all work is done 4
Required Changes for Asynchronous Processing
To make report generation truly asynchronous, you would need to implement a background job queue system:
1. Job Queue Infrastructure
- Implement a job queue (e.g., Bull, Agenda, or database-backed queue)
- Create a separate worker process to handle report generation jobs
- Store job state in a database for persistence
2. Modified Submit Flow
// Instead of blocking, return immediately with job ID
async function submit(formData?: FormData, skip?: boolean) {
const jobId = nanoid()
// Enqueue the job for background processing
await queue.add('report-generation', {
jobId,
formData,
skip
})
// Return immediately with job ID
return {
jobId,
status: 'processing'
}
}
3. Status Checking Mechanism
- Create a new server action to check job status
- Implement polling or websocket updates on the client
- Stream partial results as they become available from the worker
4. Worker Process
- Move the current
processEvents()andprocessResolutionSearch()logic to a worker - Update AIState progressively as results are generated
- Store intermediate results in the database
Notes
This is a significant architectural change that requires implementing a job queue system, worker processes, and status tracking infrastructure. The current streaming approach in app/actions.tsx provides progressive UI updates but still blocks the server action. True asynchronous processing would require background job processing with a queue system like Bull or a database-backed solution. The existing optimizations in OPTIMIZATION_SUMMARY.md focus on reducing re-renders and caching, not on making the actual generation process non-blocking.
Wiki pages you might want to explore:
Citations
File: app/actions.tsx (L36-42)
async function submit(formData?: FormData, skip?: boolean) {
'use server'
const aiState = getMutableAIState<typeof AI>()
const uiStream = createStreamableUI()
const isGenerating = createStreamableValue(true)
const isCollapsed = createStreamableValue(false)
File: app/actions.tsx (L223-223)
processResolutionSearch();
File: app/actions.tsx (L516-550)
while (
useSpecificAPI
? answer.length === 0
: answer.length === 0 && !errorOccurred
) {
const { fullResponse, hasError, toolResponses } = await researcher(
currentSystemPrompt,
uiStream,
streamText,
messages,
mapProvider,
useSpecificAPI,
drawnFeatures
)
answer = fullResponse
toolOutputs = toolResponses
errorOccurred = hasError
if (toolOutputs.length > 0) {
toolOutputs.map(output => {
aiState.update({
...aiState.get(),
messages: [
...aiState.get().messages,
{
id: groupeId,
role: 'tool',
content: JSON.stringify(output.result),
name: output.toolName,
type: 'tool'
}
]
})
})
}
File: app/actions.tsx (L619-624)
return {
id: nanoid(),
isGenerating: isGenerating.value,
component: uiStream.value,
isCollapsed: isCollapsed.value
}
- Lenguaje dominante
- TypeScript
- Estrellas
- 19
- Forks
- 7
- Merge medio
- 59 min
- PR fusionados (30 d)
- 16
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de QueueLab/QCX
-
Settings Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Update Gemini 3.1 Pro Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
Collaboration Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
-
Image preview Gen UI Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
Todos los issues de QueueLab/QCX
Issues similares
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Crush Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
ElementsProject/cln-application#167 · 1 comentario · 1 reacción ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Quantco/pnpm-licenses#17 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100