I seen a server using a webhook and it actually assigns a role not an actual bot it’s a webhook how can it be possible ?

I'm developing a Python asyncio Discord notification bot that monitors blockchain transactions. It uses PostgreSQL for durable delivery state and has an optional Fast Alert pipeline.

The intended flow:

1. Send an early preview containing only sufficiently verified evidence.
2. Save the confirmed Discord message ID.
3. Update the same message with the complete card using PATCH.
4. Preserve recipient authorization, delivery ownership, revision checks, reorg handling, and duplicate protection.

What I've observed:

During one production session, we recorded 41 full-card Discord API ACKs:

• Average source-to-full-ACK latency: 1.34 seconds
• Median: 0.96 seconds
• P95: 3.21 seconds
• Under 1 second: 21/41 cards

However, there were no [FAST_PREVIEW] markers in the session logs.

This does not necessarily mean the feature is broken.

The feature defaults to disabled, and its effective runtime setting for that session has not been confirmed. Some events may lack the minimum verified evidence, and the implementation intentionally skips preview when full enrichment finishes first.

Simplified scheduling code:

This is a sanitized reduction of the preview scheduling logic, not verbatim production code.

minimum_future and full_task represent existing asyncio Tasks/Futures. The full task represents enrichment/routing readiness, not a Discord full-message ACK.

Recipient authorization, durable ownership, detailed error handling, revision checks, and POST/PATCH implementation are intentionally omitted.

import asyncio
import logging

logger = logging.getLogger(__name__)


async def maybe_publish_preview(
    *,
    enabled,
    minimum_future,
    full_task,
    is_eligible,
    publish_preview,
):
    # These early exits are currently silent.
    if not enabled or minimum_future is None:
        return

    await asyncio.wait(
        (minimum_future, full_task),
        return_when=asyncio.FIRST_COMPLETED,
    )

    # Prefer the full path if it is already ready.
    if (
        full_task.done()
        or not minimum_future.done()
        or minimum_future.cancelled()
    ):
        return

    minimum_evidence = minimum_future.result()

    # Includes evidence validity and recipient checks.
    if not is_eligible(minimum_evidence):
        return

    # Full readiness may have changed.
    if full_task.done():
        return

    # Abstracts transport and durable ownership.
    result = await publish_preview(minimum_evidence)

    # Logged only if the call returns.
    logger.info("preview_result=%s", result)

What concerns me:

Several execution paths return without explaining why no preview was sent.

Also, .done() is true when a task completes successfully, fails, or is cancelled. In this simplified flow, those outcomes are not distinguished.

Likewise, minimum_future.result() or publish_preview() may raise an exception before a preview-result log is recorded.

This makes it difficult to determine whether:

• Fast Alert was disabled.
• Minimum evidence was unavailable or insufficient.
• The recipient was ineligible.
• Full enrichment finished before preview.
• Preview was attempted but failed or produced an uncertain outcome.
• Preview was acknowledged and later updated successfully.

My questions:

1. Instrumentation: Which counters, structured reason codes, or trace events would you add to distinguish these paths with minimal runtime overhead?
2. Task lifecycle: How should successful completion, exceptions, and cancellation be distinguished when using asyncio.FIRST_COMPLETED?
3. Delivery correctness: How would you correlate source-event identity, preview HTTP ACK, durable PostgreSQL ACK, message ID, PATCH revision, and final full-card completion?
4. Latency measurement: How would you measure source-to-preview ACK and source-to-full ACK separately without double-counting events or treating preview as full completion?
5. Testing: How would you validate concurrency, cancellation, reorg, ambiguous HTTP outcomes, and full-ready-first behavior without artificially delaying enrichment to force previews?

My goal:

I want to reduce the time until users receive their first useful Discord notification, ideally below one second when possible.

However, I don't want to weaken financial/security verification, send duplicate messages, update the wrong message, or incorrectly mark a preview as a completed full alert.

I'm looking for instrumentation and validation strategies before changing production behavior.

I can provide small sanitized code excerpts or synthetic traces if needed.