[Bug] Scheduled webhook reports can hang forever without an HTTP timeout

[DhruvalBhinsara1]

Problem

Scheduled report delivery can block indefinitely when a webhook endpoint accepts the TCP connection but never sends a response.

Current Behavior

internal/scheduler/scheduler.go sends webhook reports with the package-level http.Post helper:

resp, err := http.Post(webhookURL, "application/json", bytes.NewBuffer(jsonData))

http.Post uses http.DefaultClient, which has no timeout. If the destination webhook stalls, the scheduled job goroutine can remain stuck forever and the scheduler cannot reliably finish, retry, or record the failed report delivery.

Why This Matters

This affects automated reporting reliability. A slow or malicious webhook receiver can pin a scheduled report job indefinitely, which is especially risky for daemon/scheduled usage where the user expects jobs to complete or fail within a bounded time.

Reproduction Evidence

1. Configure a scheduled job with a webhook destination.
2. Point the webhook URL to an endpoint that accepts the request and sleeps without responding.
3. Run the scheduled export path.
4. The call to sendToWebhook waits without a bounded deadline because the client has no timeout.

Proposed Solution

Use an HTTP client with an explicit timeout for webhook delivery and add a focused scheduler test that proves stalled webhooks return a timeout error instead of hanging.

Expected Outcome

Webhook report delivery should fail fast with a clear error when the receiver stalls, allowing the scheduled job to complete its failure path instead of blocking forever.

Duplicate Check

Checked existing issues/PRs for scheduled report webhook hangs, http.Post timeout, scheduled report webhook timeout http.Post, and webhook blocks scheduler. No matching open issue or PR was found.

[github-actions]

📌 Thanks for reporting an issue!

Please ensure you have:

• Searched for existing issues to avoid duplicates.
• Included steps to reproduce (if reporting a bug).
• Described the expected vs actual behavior.
• Provided any relevant logs or screenshots.

We will look into this as soon as possible.

[DhruvalBhinsara1]

/assign gssoc

[KartikeyG-world]

Hello @agnivo988 ,

I would like to work on this issue under GSSoC 2026.

After reviewing the report, I identified that webhook delivery currently relies on http.Post, which internally uses http.DefaultClient. Since the default client does not define a timeout, a webhook endpoint that accepts the connection but never responds can cause the scheduler goroutine to block indefinitely.

My approach would be:

• Analyze the current webhook delivery flow in the scheduler module.
• Replace the direct usage of http.Post with a dedicated HTTP client configured with an explicit timeout.
• Ensure timeout-related failures are properly propagated and logged so scheduled jobs can follow their normal failure and retry paths.
• Verify that stalled webhook requests no longer block scheduler execution indefinitely.
• Add focused unit/integration tests using a mock HTTP server that intentionally delays responses.
• Validate that timeout errors are returned within the configured deadline and that scheduler behavior remains predictable.
• Review related network operations for similar unbounded blocking scenarios to maintain consistency.

This change will improve the reliability and fault tolerance of scheduled report delivery by ensuring webhook failures are handled within a bounded timeframe rather than allowing jobs to hang indefinitely.

I would be happy to implement and thoroughly test this fix.

Kindly assign this issue to me.

Thank you.

[DhruvalBhinsara1]

@agnivo988 assign this to me and review my pull request

[PranavAgarkar07]

Hey @agnivo988, I've been looking at this. The fix is straightforward — create an http.Client with a Timeout field set and use it instead of http.Post in the webhook delivery path. I'd also add a test with a server that delays responses to confirm it times out cleanly instead of hanging.

I can pick this up if no one else is actively working on it.

[Shubham-Gotawade]

Hi @agnivo988!

I've tackled Issue #391 for GSSoC '26. The un-bounded HTTP client bug has been resolved by configuring a strict 10-second timeout on a dedicated client instance, and I've verified the fix completely using a simulated high-latency mock server suite.

The tests are passing perfectly green locally. Please review the changes whenever you get a moment!

[saurabhhhcodes]

Hi! I'd like to work on this issue under GSSoC'26. I've submitted PR #484 with the fix. Please assign this to me.