Dealing Center model

Dealer pool

Field	Type	Meaning
id	int	Pool identifier
name	string	Unique pool name
description	string	Administrative description
enabled	bool	Pool status
dealer_logins	int[]	Staff ids allowed to process requests
created_at, updated_at	int64	Unix timestamps

Pools are persisted in bases/dealing_center.db. Deleting a pool removes its member rows explicitly in code.

Dealer request

Field	Type	Meaning
id	uint64	Request identifier
operation	int	0 ANY, 1 OPEN, 2 CLOSE, 3 PARTIAL_CLOSE
login	int	Trading account
order	int	Reserved/open position order
symbol, cmd, volume	mixed	Requested trade parameters
route_id	int	Matched route
route_step_position	int	Current plan step
dealer_pool_id	int	Pool responsible for the request
status	int	Current lifecycle status
assigned_dealer_login	int	Dealer who claimed the request, or 0
deadline_at	int64	Timeout deadline, or 0
execution_result	int	Core return code after execution
dealer_comment	string	Rejection comment

Requests are persisted in bases/dealer_requests.db. The original trade payload and immutable route-step chain are stored with the request so later route edits do not change an existing request.

Status values

Name	Value
PENDING	0
CLAIMED	1
EXECUTING	2
EXECUTED	3
REJECTED	4
EXPIRED	5
CANCELLED	6
EXECUTION_FAILED	7

Only the dealer who claimed a request can release, accept, or reject it. Atomic CLAIMED → EXECUTING prevents two concurrent accepts from executing the trade twice.

Timeout fallback

When deadline_at expires, the request becomes EXPIRED. The saved routing plan is advanced: INTERNAL resumes Core execution, REJECT stops the request, another MANUAL_DEALER creates a new pending request, and VIRTUAL_DEALER evaluates its referenced policy. A Virtual Dealer ACCEPT resumes Core execution, REJECT stops the operation, and NEXT_STEP continues through the saved plan.

Virtual Dealer policies and their automatic decision model are documented in Virtual Dealer.