Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Asynchronous Report Generation

未关闭
  • 哪里不对？
#660 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
nextjs, typescript
领域
backend

调研方向

首先阅读 app/actions.tsx 中的 submit server action，包括 processResolutionSearch、processEvents 和 researcher loop。在选择 queue 和 persistence 方案之前，将当前的 streaming 行为与 OPTIMIZATION_SUMMARY.md 以及链接的 orchestration wiki 页面进行比较。完成的标准是：报告生成能够及时返回 job ID，后台工作会跟踪状态和中间结果，并且客户端能够收到进度更新。

由索引模型根据 Issue 内容生成。

描述

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
  }
主要语言
TypeScript
星标
19
派生
7
平均合并
24 分钟
30 天内合并 PR
9

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

QueueLab/QCX 的其他 Issue

查看 QueueLab/QCX 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。