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.

Disclosure up front: Mention Reminder is our own bot (we're a small web agency in Warsaw). It's free for up to five people and paid per person beyond that.

The problem we kept hitting: someone pings you, you read it on your phone between two things, mean to answer later, and it scrolls away. Once you've opened the channel the red badge is gone, even though you never actually answered.

How it works

• Every @mention goes into a private thread only that person can see, with a jump link back to the original message.
• At the hours they pick, it reminds them about whatever is still open: by DM, or in that private thread if their DMs are closed.
• An item clears itself when they reply to the message, react to it, or press Done. A 🔔 on the original message shows it's still waiting on someone.
• @everyone and @role pings are ignored by default. On the paid plan they can be switched on, and an AI check decides whether the message actually asks someone for a reply, so one announcement doesn't turn into fifty reminders.
• Only a one-line excerpt is stored, anything that looks like a password or token is stripped first, and deleting the original message deletes its reminders.

I'd love your feedback on

1. How do you keep track of pings you meant to answer today? Mentions tab, "mark unread", a pinned note, or nothing at all?
2. Is there a bot you already use for this that I should look at?
3. Anything that would stop you from adding it. Brutal honesty welcome.

You can try it for free: Mention Reminder on the Discord App Directory

Thanks, I'll answer everything in the comments.

Looking for advice from anyone who has been through the new Privileged Intent review (the 10,000-user threshold introduced in June).

Our bot got the notification and the deadline was Oct 9. We submitted the review on Oct 10, one day late, and in the meantime Discord removed all three privileged intents (Server Members, Presence, Message Content). We got an automatic confirmation that the request was received, but nothing since.

We also opened a Developer Compliance ticket asking if access could be temporarily restored during the review. We confirmed it was a compliance issue as they asked, but no reply yet.

A few questions:

• How long did your review take under the new system?
• Has anyone had intents restored while the review was still pending?
• Is there a better channel to reach the right team, or any way to speed things up?

The bot is used daily by our community, so any tips would be really appreciated. Thanks a lot!