What causes "No component_verify_ticket found." in w7corp/easywechat?

Point the component's 授权事件接收URL at a public route that runs $openPlatform->getServer()->serve() so ticket pushes get captured into the cache

w7corp/easywechat · error · RuntimeException

No component_verify_ticket found.

Error message

No component_verify_ticket found.

What it means

OpenPlatform\VerifyTicket::getTicket() only reads the shared cache for the component_verify_ticket that WeChat pushes roughly every 10 minutes to the component's auth-event (授权事件接收) endpoint — there is no HTTP fetch here. RuntimeException means the cache has no usable string ticket yet. All component-access-token flows (pre-auth codes, token refresh) fail fast until a push has been received and stored.

Source

Thrown at src/OpenPlatform/VerifyTicket.php:55

        return $this;
    }

    public function setTicket(string $ticket): static
    {
        $this->cache->set($this->getKey(), $ticket, 6000);

        return $this;
    }

    /**
     * @throws RuntimeException
     */
    public function getTicket(): string
    {
        $ticket = $this->cache->get($this->getKey());

        if (! $ticket || ! is_string($ticket)) {
            throw new RuntimeException('No component_verify_ticket found.');
        }

        return $ticket;
    }
}

View on GitHub (pinned to f0cf0a8b83)

Solutions

Point the component's 授权事件接收URL at a public route that runs $openPlatform->getServer()->serve() so ticket pushes get captured into the cache
Use one shared cache backend (Redis) with the same prefix for both the receiver and all consumers
After a first deploy or cache wipe, wait for the next push (up to ~10 minutes) before retrying
Log one push arrival to confirm the endpoint works, then monitor it

Example fix

// before: workers use a cache that never received the push
$code = $openPlatform->createPreAuthorizationCode(); // RuntimeException

// after: receiver route and workers share the same Redis-backed cache
// route: POST /open-platform/notify → $openPlatform->getServer()->serve();
$openPlatform->setCache(new \Symfony\Component\Cache\Adapter\RedisAdapter($redis, 'easywechat'));

Defensive patterns

Strategy: try-catch

Try / catch

try {
    $ticket = $openPlatform->getVerifyTicket()->getTicket();
} catch (\RuntimeException $e) {
    // pushes not arriving yet: back off and retry later; alert if this persists past ~20 minutes
    report($e);
    return retry_after(600);
}

Prevention

Health-check the 授权事件接收 endpoint externally so missed ticket pushes surface quickly
Never use per-instance file caches for open-platform state
After rotating cache backends or prefixes, expect one push cycle (~10 min) of warm-up
Alert when the cached ticket's age exceeds ~20 minutes

When it happens

Trigger: Calling createPreAuthorizationCode() or any component-token flow before the first push arrived; the receiving endpoint is not routed to the open-platform Server so pushes never reach the cache; the cache is not shared (file cache across containers) between receiver and consumers; cache recently wiped.

Common situations: Fresh open-platform deployment still waiting for the first push; the 授权事件接收URL is 404/behind auth; Redis switched or its prefix changed after a deploy; load-balanced workers each using local disk caches.

Related errors

AI-assisted analysis of w7corp/easywechat@f0cf0a8b83 (2026-08-21). Data as JSON: /api/errors/910996c9b83743b0. Report an issue: GitHub.