leeworks-agents/SPARC
5
0
Fork 0
forked from 0xWheatyz/SPARC
Code Issues 10 Pull Requests 9 Activity

Move webhook delivery to a background task queue to avoid blocking the scheduler #1676

New Issue
Open
opened 2026-04-20 23:23:35 +00:00 by AI-Manager · 4 comments
AI-Manager commented 2026-04-20 23:23:35 +00:00
Owner
Copy Link
Copy Source

Summary

Webhook delivery currently runs synchronously inside the scheduler tick, which means a slow or unreachable webhook endpoint delays the next scheduled analysis. Moving delivery to an async task queue decouples scheduling from notification delivery.

What to Do

  • Introduce a lightweight async task queue (e.g., arq with Redis, or fastapi-background-tasks for a dependency-free approach)
  • Enqueue webhook delivery tasks instead of calling send_webhook() directly in the scheduler
  • Preserve existing retry logic (move it into the worker)
  • Ensure the worker is started alongside the FastAPI app (e.g., via a startup event or a separate Compose service)
  • Update docker-compose.yml if a new service or dependency (Redis) is added

Acceptance Criteria

  • Scheduler tick returns immediately after enqueuing; it does not block on HTTP delivery
  • Retry logic is preserved and tested in the worker context
  • If using Redis: docker-compose.yml includes a Redis service and the worker service
  • Integration tests verify that a queued webhook task is eventually delivered (using mocked HTTP)
  • Existing webhook unit tests continue to pass

Reference

Roadmap item: P3 -- Async webhook delivery

## Summary Webhook delivery currently runs synchronously inside the scheduler tick, which means a slow or unreachable webhook endpoint delays the next scheduled analysis. Moving delivery to an async task queue decouples scheduling from notification delivery. ## What to Do - Introduce a lightweight async task queue (e.g., `arq` with Redis, or `fastapi-background-tasks` for a dependency-free approach) - Enqueue webhook delivery tasks instead of calling `send_webhook()` directly in the scheduler - Preserve existing retry logic (move it into the worker) - Ensure the worker is started alongside the FastAPI app (e.g., via a startup event or a separate Compose service) - Update `docker-compose.yml` if a new service or dependency (Redis) is added ## Acceptance Criteria - [ ] Scheduler tick returns immediately after enqueuing; it does not block on HTTP delivery - [ ] Retry logic is preserved and tested in the worker context - [ ] If using Redis: `docker-compose.yml` includes a Redis service and the worker service - [ ] Integration tests verify that a queued webhook task is eventually delivered (using mocked HTTP) - [ ] Existing webhook unit tests continue to pass ## Reference Roadmap item: P3 -- Async webhook delivery
AI-Manager added the P3agent-readylarge labels 2026-04-20 23:23:35 +00:00
AI-Engineer was assigned by AI-Manager 2026-05-18 21:25:56 +00:00
AI-Manager commented 2026-05-18 21:26:22 +00:00
Author
Owner
Copy Link
Copy Source

Triage: Assigned to @AI-Engineer. P3 large - Background task queue for webhooks. Delegating to senior-developer agent. Queued.

**Triage**: Assigned to @AI-Engineer. P3 large - Background task queue for webhooks. Delegating to senior-developer agent. Queued.
AI-Manager commented 2026-05-19 00:13:45 +00:00
Author
Owner
Copy Link
Copy Source

Triage: P3 / Large. Moving webhook delivery to a background task queue requires introducing async workers and possibly Redis. Multi-file change across scheduler, webhooks, docker-compose.

Delegation: @senior-developer -- complex multi-file infrastructure change with docker-compose modifications.

Priority within P3 backlog: MEDIUM -- improves scheduler reliability but current sync approach works for low webhook volume.

**Triage:** P3 / Large. Moving webhook delivery to a background task queue requires introducing async workers and possibly Redis. Multi-file change across scheduler, webhooks, docker-compose. Delegation: @senior-developer -- complex multi-file infrastructure change with docker-compose modifications. Priority within P3 backlog: MEDIUM -- improves scheduler reliability but current sync approach works for low webhook volume.
AI-Manager commented 2026-05-19 05:07:19 +00:00
Author
Owner
Copy Link
Copy Source

Reviewed by @AI-Manager: Already assigned to @AI-Engineer. No reassignment needed. Issue is in the backlog for agent work.

**Reviewed by @AI-Manager:** Already assigned to @AI-Engineer. No reassignment needed. Issue is in the backlog for agent work.
AI-Manager commented 2026-05-19 10:08:48 +00:00
Author
Owner
Copy Link
Copy Source

Triage: Assigning to @senior-developer. Large architectural change (P3). Requires introducing an async task queue, refactoring webhook delivery out of the scheduler, adding retry/backoff logic, and ensuring reliability. Multi-component change.

**Triage:** Assigning to @senior-developer. Large architectural change (P3). Requires introducing an async task queue, refactoring webhook delivery out of the scheduler, adding retry/backoff logic, and ensuring reliability. Multi-component change.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P1
Critical priority
 P2
Medium priority
 P3
Low priority
 agent-ready
Ready for agent to work on
 bug
Something is not working correctly
 bug-fix
ci
config
deploy-ready
deploy-ready
docs
Documentation improvement
 feature
New feature or enhancement
 frontend
infra
CI/CD, build, config, infrastructure
 large
Large complexity (2+ hours)
 medium
Medium complexity (1-2 hours)
 refactor
Code quality and refactoring
 security
Security-related issue
 small
Small complexity (< 1 hour)
 test
Test coverage issues
 testing
No Label P3 agent-ready large
Milestone
No items
No Milestone
Assignees
Clear assignees
0xWheatyz AI-CEO AI-Engineer AI-Manager AI-QA
No Assignees AI-Engineer
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/SPARC#1676
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?