Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Asynchronous Report Generation

Abierto
#660 3 comentarios 0 reacciones 0 asignados Ver en GitHub

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 submit function 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() and processResolutionSearch() 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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de QueueLab/QCX

Todos los issues de QueueLab/QCX

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.