decouple metadata and tweet processing from submission

[whoabuddy]

problem: response time is a challenge with LLMs, sometimes queries take up to 15s to get a response and this blocks the frontend getting a result from the API to create a new contribution

possible solution: create more detailed statuses to account for how a contribution is being handled in the backend, and defer metadata generation and tweet processing to later steps, e.g.

DRAFT: received from frontend, stored in DB with minimal info
PROCESSING: backend is fetching X tweet info for DB, backend is fetching proposal metadata
PROCESSING_FAILED: catch-all for if something goes wrong, can manually review
PROCESSED: we have X tweet info in DB, we have proposal metadata now (tags/title/summary)
SUBMITTED_ONCHAIN_PENDING: we sent the tx to create the proposal (could do this before/after processing depending on what data we store)
SUBMITTED_ONCHAIN_SUCCESS: tx succeeded, we know it's a valid contribution with all info
SUBMITTED_ONCHAIN_FAILED: tx failed, parse error from tx, catch-all for broadcast errors, can manually review

this would allow a much faster response from the API and the frontend could display placeholders until info is processed, as well as have a clearer picture of what's happening with that contribution in the backend

[tfireubs-ui]

The status progression design looks right. A few implementation notes that might help scope the work:

Minimal path to the API timeout fix:
The core problem is that the X API call + LLM metadata generation block the HTTP response. The quickest fix is probably to:

1. Return DRAFT status immediately after DB insert (< 100ms)
2. Kick off background processing via a task queue or async Python task

The full 7-state machine above is the eventual goal, but even just DRAFT + PROCESSING + PROCESSED gets the UX win without the full overhaul.

Background processing options:

• Python's asyncio.create_task() if the backend is async
• A simple in-memory task queue with a worker loop
• A Celery task if that's already in the stack

Rollback safety:
The PROCESSING_FAILED state is especially useful here — it prevents agents from seeing a half-processed contribution with no way to know what happened.

Happy to look at a PR for the DRAFT → async flow if the scope fits.

[biwasxyz]

This repository has been retired and will be archived soon. The hosted agent infrastructure has been superseded. If this issue is still relevant, please open a new issue in the appropriate active repo.