Troubleshooting
The problems people actually hit, what causes them, and the fix.
Check, in order:
- Is a worker online that may fire it?
listWorkers(), or the dashboard's Workers page. A rule assigned to one worker waits for that worker. - Can that worker run the action? Telegram needs a worker with a bot token; its
actionslist says. - Is the deadline in the past?
getRule(key).deadline. For expire rules the deadline follows the target; an extended target fires later. - Was it created seconds before its deadline? A worker notices new rules within about 30 seconds.
The target has expired, been deleted, or never existed, and createRule refuses to spend a transaction
on it. If you just created the target, a read right after a write can still miss it: wait a second and retry.
Your IP address used up Arkiv's anonymous read budget. Wait, switch network, or read through a relay that adds an access key on the server. See Access keys and quota.
The key's monthly quota is spent (QUOTA_EXCEEDED). Use a new key, and give each worker a key nothing
else uses.
A rate-limited query (often a missing access key) that would otherwise hang. Set ARKIV_ACCESS_KEY.
Fund the worker's address from the faucet, then start again.
Public workers will not call localhost or private networks. Expose your receiver on a public https://
URL, or test with a worker started with allowLocal: true on your own machine.
The chat was sealed to a different worker than the one that fired it, or the bot cannot message you (tap Start on the bot first). Telegram rules should name the worker the chat was sealed to.
Arkiv's WebSocket closes about once a minute. The worker reconnects once per drop; this line is normal.