What happened
When starting a Telegram or Discord bot channel in Maka Desktop, the UI can show a failure toast saying that the bot started but did not enter listening mode:
Telegram 启动后未进入监听Discord 启动后未进入监听
In both cases, the bot was subsequently able to receive a test message and send the expected reply. The startup diagnostic therefore does not match the eventual runtime state and can make a successfully configured channel look broken.
Expected behavior: keep the channel in a connecting state until the listener is ready, or clear/reconcile the transient startup warning once the listener becomes operational. A failure toast should only remain when the channel cannot receive messages.
How to reproduce
- Configure a Telegram Bot channel and start it from Maka Desktop.
- Observe the startup status shortly after enabling the channel.
- If the
Telegram 启动后未进入监听 toast appears, send a direct test message to the bot.
- Observe that the bot can still receive the message and return the expected text.
- Repeat the same flow with a Discord Bot channel and a test-server message mentioning the bot.
- Observe the same transient
Discord 启动后未进入监听 toast followed by a successful message round trip.
The behavior was observed during manual smoke testing on 2026-09-10 for both channels.
Environment
- Maka version or commit:
0.2.0-dev.26.20260909 (packaged nightly)
- OS and version: Windows 10,
10.0.19045, x64
- Surface: Desktop
- Locale:
zh-CN
- Electron:
43.4.1
- Chrome:
150.0.7871.224
- Node.js:
24.18.1 (packaged runtime)
- Affected channels: Telegram and Discord
Logs, screenshots, or additional context
The two desktop diagnostic reports had the titles above. The observed successful follow-up replies were exact-text smoke messages in the respective channels.
The Discord test used the Discord web client. Because Discord Gateway access required a system-level TUN route in this mainland-China network environment, the report focuses on the readiness-state mismatch rather than treating the network setup as the defect.
No bot tokens, user IDs, or raw provider payloads are included. Suspected area: a startup/readiness race where the UI reports failure before the listener reaches its ready state.
What happened
When starting a Telegram or Discord bot channel in Maka Desktop, the UI can show a failure toast saying that the bot started but did not enter listening mode:
Telegram 启动后未进入监听Discord 启动后未进入监听In both cases, the bot was subsequently able to receive a test message and send the expected reply. The startup diagnostic therefore does not match the eventual runtime state and can make a successfully configured channel look broken.
Expected behavior: keep the channel in a connecting state until the listener is ready, or clear/reconcile the transient startup warning once the listener becomes operational. A failure toast should only remain when the channel cannot receive messages.
How to reproduce
Telegram 启动后未进入监听toast appears, send a direct test message to the bot.Discord 启动后未进入监听toast followed by a successful message round trip.The behavior was observed during manual smoke testing on 2026-09-10 for both channels.
Environment
0.2.0-dev.26.20260909(packaged nightly)10.0.19045, x64zh-CN43.4.1150.0.7871.22424.18.1(packaged runtime)Logs, screenshots, or additional context
The two desktop diagnostic reports had the titles above. The observed successful follow-up replies were exact-text smoke messages in the respective channels.
The Discord test used the Discord web client. Because Discord Gateway access required a system-level TUN route in this mainland-China network environment, the report focuses on the readiness-state mismatch rather than treating the network setup as the defect.
No bot tokens, user IDs, or raw provider payloads are included. Suspected area: a startup/readiness race where the UI reports failure before the listener reaches its ready state.