-
Notifications
You must be signed in to change notification settings - Fork 6
Open
Description
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
Metadata
Metadata
Assignees
Labels
No labels