Asynchronous Report Generation
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- nextjs, typescript
- Ambito
- backend
Direzione di ricerca
Inizia leggendo la server action submit in app/actions.tsx, inclusi processResolutionSearch, processEvents e il researcher loop. Confronta il comportamento attuale dello streaming con OPTIMIZATION_SUMMARY.md e le pagine wiki di orchestrazione collegate prima di scegliere un approccio per la coda e la persistenza. Il lavoro è completato quando la generazione del report restituisce prontamente un job ID, il lavoro in background tiene traccia dello stato e dei risultati intermedi e i client ricevono aggiornamenti sull'avanzamento.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
}
- Lingua principale
- TypeScript
- Stelle
- 19
- Fork
- 7
- Merge medio
- 59m
- PR unite (30g)
- 16
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di QueueLab/QCX
-
Settings Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Update Gemini 3.1 Pro Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
Collaboration Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
-
Image preview Gen UI Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
Tutte le issue di QueueLab/QCX
Issue simili
-
VerificationGate: ATTRIBUTION quote guard never matches a normal quotation (\b around the quote) Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
danielmiessler/LifeOS#2234 ·
-
T: Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
-
Mend: dependency security vulnerability untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100