Job retry WEBHOOK_DISPATCH branch passes a dict where a delivery id is expected, and no code ever creates such jobs

[usmanimamu17-create]

Problem

retry_job (app/api/v1/endpoints/jobs.py) has a webhook branch:

elif job.job_type == JobType.WEBHOOK_DISPATCH:
    from app.tasks.webhook_tasks import dispatch_webhook_delivery
    task_result = dispatch_webhook_delivery.delay(payload)   # payload is the parsed JSON dict

dispatch_webhook_delivery(self, delivery_id: str) (app/tasks/webhook_tasks.py) expects a delivery UUID string and immediately calls UUID(delivery_id) — passing the payload dict raises TypeError inside the task, which then retries 5 times and dies.

Separately, JobType.WEBHOOK_DISPATCH is referenced nowhere else: no code path creates a job with that type (app/tasks/sla_tasks.py only creates SLA_COMPUTATION/BULK_SLA_COMPUTATION), so the branch is unreachable today.

Consequences:

• The branch is broken if ever reached: a manually-inserted or future webhook job retried through the API schedules a task that fails on UUID({...}) — the retry is silently doomed, and the audit event job_retry_initiated records a success that will never happen.
• The dead branch is a trap for the webhook-dispatch work: when webhook dispatch jobs are introduced (the service already documents webhook delivery retry semantics), this path will mislead a contributor into thinking retry works.
• The branch's payload semantics are undefined: a webhook job's payload should carry a delivery_id, not the raw event dict the SLA paths use — the two job types have different payload shapes and the retry code treats them the same.

Root cause

The retry branch was scaffolded to match the enum without the corresponding job-creating code path or a payload contract.

Why this is architecturally hard

1. The fix requires defining what a WEBHOOK_DISPATCH job's payload is (the delivery id? the event?) and who creates such jobs — either remove the branch and the enum value, or implement the creator and a schema-validated retry.
2. If kept, the branch must validate payload is a string delivery id before .delay(), mirroring dispatch_delivery(db, UUID(delivery_id))'s expectations.
3. A test must create a WEBHOOK_DISPATCH job (or assert the branch is unreachable) — today the enum value and branch are completely untested.

Proposed design

Either delete the WEBHOOK_DISPATCH retry branch (and the enum value) until webhook jobs exist, or implement job creation for webhook dispatch with a delivery_id payload and fix the .delay(payload) call to pass the id. Add a test covering whichever path remains.

Acceptance criteria

Service

• No retry path can schedule a task with an invalid delivery id.
• WEBHOOK_DISPATCH jobs are either creatable with a validated payload or the branch is removed.

Tests

• A test covers the remaining branch (valid retry or explicit rejection).
• Existing job tests pass.

Out of scope

The duplicate-row retry bug (tracked separately) and webhook delivery semantics.

Getting started

pytest tests/test_payment_retry_queue_backoff.py -q
make typecheck

Good first files to read: app/api/v1/endpoints/jobs.py, app/tasks/webhook_tasks.py, app/models/job.py.

[heymide]

@heymide has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I can take this on. I've gone through the details and will provide a well-tested solution aligned with the project standards.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @heymide to this issue.

[Femaleotaku]

@Femaleotaku has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello, I'd like to pick this issue up.

This touches Python, which I have hands-on experience with. I'll implement this following the existing conventions in the codebase, with tests covering the new behavior.

I'd love the opportunity to work on this — please consider assigning it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Femaleotaku to this issue.

[drips-wave]

Congratulations, @Femaleotaku! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Femaleotaku: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @Femaleotaku as part of the Stellar Wave Program's 8th Wave 🥳

😎 @Femaleotaku: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.