Bot Initialization & Lifecycle

Relevant source files

The following files were used as context for generating this wiki page:

• bot.py
• core/bot.py
• core/commands.py
• core/database.py
• railway.json

The GentelmeN-CorE bot initialization and lifecycle process encompasses environment validation, database schema establishment, third-party integration setup, and a dual-threaded operational model. The system is designed to run within a cloud environment, specifically optimized for Railway's deployment lifecycle, ensuring persistent execution and automated recovery from polling failures.

Startup Entry Point

The application starts via a root-level bot.py script that acts as a wrapper. It uses runpy to execute the core logic located in the core/bot.py module. This structure separates the deployment entry point from the internal library structure.

Sources: bot.py:1-8

The diagram above illustrates the redirection from the root entry point to the core initialization logic.

Initialization Sequence

The core initialization process follows a strict sequence to ensure all dependencies are available before the bot begins processing messages.

Environment & Client Setup

The bot requires several environment variables for operation. If TELEGRAM_TOKEN or GROQ_KEY are missing, the system raises a RuntimeError immediately to prevent partial failures.
Sources: core/bot.py:15-22

The system initializes three primary clients:

1. TeleBot: The main Telegram interface.
2. Groq Client: For AI-driven completions.
3. Kucoin: A CCXT exchange client for cryptocurrency data (initialized within a try-except block to handle potential API failures gracefully).
   Sources: core/bot.py:24-37

Database and Handlers

Following client instantiation, the bot performs two critical setup tasks:

• Database Schema: Calls init_db() to create the users and alerts tables if they do not exist.
• Command Registration: Executes register_handlers() to map Telegram commands to their respective Python functions.
  Sources: core/bot.py:39-40, core/database.py:12-38, core/commands.py:236-252

Lifecycle Components

The bot operates using two concurrent execution flows: the main message polling loop and a background price monitoring thread.

Background Price Monitor

A daemon thread is started specifically for the price_monitor function. This thread runs an infinite loop with a 60-second sleep interval. It queries the PostgreSQL database for active alerts, fetches current market prices via Kucoin, and dispatches notifications if price thresholds are met.
Sources: core/bot.py:42-83

This flowchart describes the logic of the background monitoring system.

Main Polling Loop

The main thread enters a 15-second "cooldown" period during startup to allow old Railway processes to terminate before starting the infinity_polling loop. The loop is wrapped in a try-except block to ensure that if a "polling crash" occurs, the bot waits 15 seconds and restarts automatically.
Sources: core/bot.py:85-94

Configuration Summary

The following table summarizes the key environment variables and deployment configurations required for the bot's lifecycle:

Variable	Source File	Description
TELEGRAM_TOKEN	core/bot.py	API token for the Telegram bot.
GROQ_KEY	core/bot.py	API key for the Groq AI service.
DATABASE_URL	core/bot.py	Connection string for PostgreSQL.
KUCOIN_API_KEY	core/bot.py	Optional API key for Kucoin integration.
OWNER_USER_ID	core/commands.py	Used to authorize administrative commands.

Deployment Specifications

The deployment behavior is defined in railway.json, specifying the start command and restart policies.

Setting	Value	Description
startCommand	python bot.py	Command to launch the application.
restartPolicyType	ON_FAILURE	Restart only if the process crashes.
numReplicas	1	Single instance deployment.
Sources: railway.json:1-14

Conclusion

The GentelmeN-CorE lifecycle is characterized by a "fail-fast" initialization strategy followed by a resilient, dual-purpose execution state. By separating market monitoring from user interaction into different threads, the bot maintains responsiveness while performing periodic data processing tasks. The inclusion of automated polling recovery ensures high availability in production environments.