2021-03-08 14:05:37 +00:00
|
|
|
# piker: trading gear for hackers
|
2023-04-08 23:22:53 +00:00
|
|
|
# Copyright (C) Tyler Goodlet (in stewardship for pikers)
|
2021-03-08 14:05:37 +00:00
|
|
|
|
|
|
|
# This program is free software: you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU Affero General Public License as published by
|
|
|
|
# the Free Software Foundation, either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU Affero General Public License for more details.
|
|
|
|
|
|
|
|
# You should have received a copy of the GNU Affero General Public License
|
|
|
|
# along with this program. If not, see <https://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
"""
|
2021-03-12 02:40:06 +00:00
|
|
|
Chart trading, the only way to scalp.
|
2021-03-08 14:05:37 +00:00
|
|
|
|
|
|
|
"""
|
2022-09-06 12:14:54 +00:00
|
|
|
from __future__ import annotations
|
2021-08-27 18:53:30 +00:00
|
|
|
from contextlib import asynccontextmanager
|
2021-03-08 14:05:37 +00:00
|
|
|
from dataclasses import dataclass, field
|
2021-08-23 18:48:20 +00:00
|
|
|
from functools import partial
|
2021-03-08 14:05:37 +00:00
|
|
|
from pprint import pformat
|
|
|
|
import time
|
2022-09-06 12:14:54 +00:00
|
|
|
from typing import (
|
|
|
|
Callable,
|
|
|
|
Any,
|
|
|
|
TYPE_CHECKING,
|
|
|
|
)
|
2021-03-08 14:05:37 +00:00
|
|
|
import uuid
|
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
from bidict import bidict
|
2021-07-16 22:32:56 +00:00
|
|
|
import tractor
|
2021-06-16 12:28:57 +00:00
|
|
|
import trio
|
2022-06-05 21:01:41 +00:00
|
|
|
from PyQt5.QtCore import Qt
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-09-07 01:36:30 +00:00
|
|
|
from .. import config
|
2023-05-24 19:30:17 +00:00
|
|
|
from ..accounting import (
|
|
|
|
Allocator,
|
|
|
|
Position,
|
2021-09-07 02:05:42 +00:00
|
|
|
mk_allocator,
|
2023-05-24 19:30:17 +00:00
|
|
|
MktPair,
|
|
|
|
Symbol,
|
2021-09-07 02:05:42 +00:00
|
|
|
)
|
2023-03-30 20:21:18 +00:00
|
|
|
from ..clearing._client import (
|
|
|
|
open_ems,
|
|
|
|
OrderClient,
|
|
|
|
)
|
2022-06-05 21:01:41 +00:00
|
|
|
from ._style import _font
|
2022-11-10 03:30:15 +00:00
|
|
|
from ..data.feed import (
|
|
|
|
Feed,
|
|
|
|
Flume,
|
|
|
|
)
|
2022-07-06 16:54:03 +00:00
|
|
|
from ..data.types import Struct
|
2021-03-08 14:05:37 +00:00
|
|
|
from ..log import get_logger
|
2021-07-16 22:32:56 +00:00
|
|
|
from ._editors import LineEditor, ArrowEditor
|
2021-08-15 17:38:46 +00:00
|
|
|
from ._lines import order_line, LevelLine
|
2021-09-07 01:36:30 +00:00
|
|
|
from ._position import (
|
|
|
|
PositionTracker,
|
|
|
|
SettingsPane,
|
|
|
|
)
|
2022-06-05 21:01:41 +00:00
|
|
|
from ._forms import FieldsForm
|
2021-07-23 18:20:29 +00:00
|
|
|
from ._window import MultiStatus
|
2022-08-08 17:35:01 +00:00
|
|
|
from ..clearing._messages import (
|
2022-10-28 19:10:48 +00:00
|
|
|
# Cancel,
|
2022-08-08 17:35:01 +00:00
|
|
|
Order,
|
|
|
|
Status,
|
|
|
|
# BrokerdOrder,
|
|
|
|
# BrokerdStatus,
|
|
|
|
BrokerdPosition,
|
|
|
|
)
|
2021-08-23 18:48:20 +00:00
|
|
|
from ._forms import open_form_input_handling
|
2022-10-05 14:59:50 +00:00
|
|
|
from ._notify import notify_from_ems_status_msg
|
2021-03-08 14:05:37 +00:00
|
|
|
|
|
|
|
|
2022-09-06 12:14:54 +00:00
|
|
|
if TYPE_CHECKING:
|
2022-09-06 18:30:35 +00:00
|
|
|
from ._chart import (
|
|
|
|
ChartPlotWidget,
|
|
|
|
GodWidget,
|
|
|
|
)
|
2022-09-06 12:14:54 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
log = get_logger(__name__)
|
|
|
|
|
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
class Dialog(Struct):
|
2022-06-08 15:25:17 +00:00
|
|
|
'''
|
|
|
|
Trade dialogue meta-data describing the lifetime
|
2021-07-13 19:28:19 +00:00
|
|
|
of an order submission to ``emsd`` from a chart.
|
|
|
|
|
|
|
|
'''
|
2021-08-09 15:21:05 +00:00
|
|
|
# TODO: use ``pydantic.UUID4`` field
|
2021-07-13 19:28:19 +00:00
|
|
|
uuid: str
|
2021-08-15 17:38:46 +00:00
|
|
|
order: Order
|
2022-11-25 21:41:26 +00:00
|
|
|
symbol: str
|
2022-09-06 20:10:40 +00:00
|
|
|
lines: list[LevelLine]
|
2023-05-24 19:30:17 +00:00
|
|
|
last_status_close: Callable | None = None
|
2021-07-13 19:28:19 +00:00
|
|
|
msgs: dict[str, dict] = {}
|
2022-09-06 12:14:54 +00:00
|
|
|
fills: dict[str, Any] = {}
|
2021-03-12 02:40:06 +00:00
|
|
|
|
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
@dataclass
|
|
|
|
class OrderMode:
|
2022-03-02 14:20:17 +00:00
|
|
|
'''
|
|
|
|
Major UX mode for placing orders on a chart view providing so
|
2021-08-09 15:21:05 +00:00
|
|
|
called, "chart trading".
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-08-09 15:21:05 +00:00
|
|
|
This is the other "main" mode that pairs with "view mode" (when
|
|
|
|
wathing the rt price update at the current time step) and allows
|
|
|
|
entering orders using mouse and keyboard. This object is chart
|
|
|
|
oriented, so there is an instance per chart / view currently.
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-06-17 21:00:57 +00:00
|
|
|
Current manual:
|
|
|
|
a -> alert
|
|
|
|
s/ctrl -> submission type modifier {on: live, off: dark}
|
2021-07-13 19:28:19 +00:00
|
|
|
f (fill) -> 'buy' limit order
|
|
|
|
d (dump) -> 'sell' limit order
|
2021-06-17 21:00:57 +00:00
|
|
|
c (cancel) -> cancel order under cursor
|
|
|
|
cc -> cancel all submitted orders on chart
|
|
|
|
mouse click and drag -> modify current order under cursor
|
|
|
|
|
|
|
|
'''
|
2022-09-07 15:30:41 +00:00
|
|
|
godw: GodWidget
|
2022-09-07 01:21:57 +00:00
|
|
|
feed: Feed
|
2022-09-06 12:14:54 +00:00
|
|
|
chart: ChartPlotWidget # type: ignore # noqa
|
2022-09-06 18:30:35 +00:00
|
|
|
hist_chart: ChartPlotWidget # type: ignore # noqa
|
2022-09-07 01:21:57 +00:00
|
|
|
nursery: trio.Nursery # used by ``ui._position`` code?
|
2023-04-08 23:22:53 +00:00
|
|
|
client: OrderClient
|
2021-03-08 14:05:37 +00:00
|
|
|
lines: LineEditor
|
|
|
|
arrows: ArrowEditor
|
2021-07-23 18:20:29 +00:00
|
|
|
multistatus: MultiStatus
|
2021-08-27 18:53:30 +00:00
|
|
|
pane: SettingsPane
|
2021-09-10 15:50:24 +00:00
|
|
|
trackers: dict[str, PositionTracker]
|
2021-08-23 18:48:20 +00:00
|
|
|
|
2021-09-10 15:50:24 +00:00
|
|
|
# switched state, the current position
|
2023-02-21 14:14:26 +00:00
|
|
|
current_pp: PositionTracker | None = None
|
2021-08-18 12:42:56 +00:00
|
|
|
active: bool = False
|
2021-06-18 21:13:39 +00:00
|
|
|
name: str = 'order'
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
dialogs: dict[str, Dialog] = field(default_factory=dict)
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
_colors = {
|
|
|
|
'alert': 'alert_yellow',
|
|
|
|
'buy': 'buy_green',
|
|
|
|
'sell': 'sell_red',
|
|
|
|
}
|
2023-02-21 14:14:26 +00:00
|
|
|
_staged_order: Order | None = None
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2022-08-18 20:04:44 +00:00
|
|
|
def on_level_change_update_next_order_info(
|
|
|
|
self,
|
|
|
|
level: float,
|
|
|
|
|
|
|
|
# these are all ``partial``-ed in at callback assignment time.
|
|
|
|
line: LevelLine,
|
|
|
|
order: Order,
|
|
|
|
tracker: PositionTracker,
|
|
|
|
|
|
|
|
) -> None:
|
|
|
|
'''
|
|
|
|
A callback applied for each level change to the line
|
|
|
|
which will recompute the order size based on allocator
|
|
|
|
settings. this is assigned inside
|
2022-10-03 17:41:40 +00:00
|
|
|
``OrderMode.new_line_from_order()``
|
2022-08-18 20:04:44 +00:00
|
|
|
|
|
|
|
'''
|
|
|
|
# NOTE: the ``Order.account`` is set at order stage time inside
|
2022-10-03 17:41:40 +00:00
|
|
|
# ``OrderMode.new_line_from_order()`` or is inside ``Order`` msg
|
2022-08-18 20:04:44 +00:00
|
|
|
# field for loaded orders.
|
|
|
|
order_info = tracker.alloc.next_order_info(
|
|
|
|
startup_pp=tracker.startup_pp,
|
|
|
|
live_pp=tracker.live_pp,
|
|
|
|
price=level,
|
|
|
|
action=order.action,
|
|
|
|
)
|
|
|
|
line.update_labels(order_info)
|
|
|
|
|
|
|
|
# update bound-in staged order
|
|
|
|
order.price = level
|
|
|
|
order.size = order_info['size']
|
|
|
|
|
|
|
|
# when an order is changed we flip the settings side-pane to
|
|
|
|
# reflect the corresponding account and pos info.
|
|
|
|
self.pane.on_ui_settings_change('account', order.account)
|
|
|
|
|
2022-10-03 17:41:40 +00:00
|
|
|
def new_line_from_order(
|
2021-08-15 17:38:46 +00:00
|
|
|
self,
|
|
|
|
order: Order,
|
2023-02-21 14:14:26 +00:00
|
|
|
chart: ChartPlotWidget | None = None,
|
2021-08-15 17:38:46 +00:00
|
|
|
**line_kwargs,
|
|
|
|
|
|
|
|
) -> LevelLine:
|
|
|
|
|
2021-08-26 14:34:59 +00:00
|
|
|
level = order.price
|
2022-09-06 20:10:40 +00:00
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
line = order_line(
|
2022-09-06 20:10:40 +00:00
|
|
|
chart or self.chart,
|
2021-08-15 17:38:46 +00:00
|
|
|
# TODO: convert these values into human-readable form
|
|
|
|
# (i.e. with k, m, M, B) type embedded suffixes
|
2021-08-26 14:34:59 +00:00
|
|
|
level=level,
|
2021-08-15 17:38:46 +00:00
|
|
|
action=order.action,
|
|
|
|
|
|
|
|
size=order.size,
|
|
|
|
color=self._colors[order.action],
|
|
|
|
|
|
|
|
dotted=True if (
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
order.exec_mode == 'dark'
|
|
|
|
and order.action != 'alert'
|
2021-08-15 17:38:46 +00:00
|
|
|
) else False,
|
|
|
|
|
|
|
|
**line_kwargs,
|
|
|
|
)
|
|
|
|
|
2021-08-23 18:48:20 +00:00
|
|
|
# set level update callback to order pane method and update once
|
|
|
|
# immediately
|
2021-08-25 14:38:04 +00:00
|
|
|
if order.action != 'alert':
|
|
|
|
line._on_level_change = partial(
|
2022-08-18 20:04:44 +00:00
|
|
|
self.on_level_change_update_next_order_info,
|
2021-08-25 14:38:04 +00:00
|
|
|
line=line,
|
|
|
|
order=order,
|
2022-08-18 20:04:44 +00:00
|
|
|
# use the corresponding position tracker for the
|
|
|
|
# order's account.
|
|
|
|
tracker=self.trackers[order.account],
|
2021-08-25 14:38:04 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
else:
|
|
|
|
# for alerts we don't need to compute per price sizing via
|
|
|
|
# the order mode allocator but we still need to update the
|
|
|
|
# "staged" order message we'll send to the ems
|
|
|
|
def update_order_price(y: float) -> None:
|
|
|
|
order.price = y
|
|
|
|
|
|
|
|
line._on_level_change = update_order_price
|
2021-08-15 17:38:46 +00:00
|
|
|
|
2021-08-26 14:34:59 +00:00
|
|
|
line.set_level(level)
|
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
return line
|
|
|
|
|
2022-09-06 20:10:40 +00:00
|
|
|
def lines_from_order(
|
|
|
|
self,
|
|
|
|
order: Order,
|
|
|
|
**line_kwargs,
|
|
|
|
|
|
|
|
) -> list[LevelLine]:
|
|
|
|
|
|
|
|
lines: list[LevelLine] = []
|
2022-09-13 22:31:21 +00:00
|
|
|
for chart, kwargs in [
|
|
|
|
(self.chart, {}),
|
2022-09-23 21:16:48 +00:00
|
|
|
(self.hist_chart, {'only_show_markers_on_hover': True}),
|
2022-09-13 22:31:21 +00:00
|
|
|
]:
|
|
|
|
kwargs.update(line_kwargs)
|
2022-10-03 17:41:40 +00:00
|
|
|
line = self.new_line_from_order(
|
2022-09-06 20:10:40 +00:00
|
|
|
order=order,
|
|
|
|
chart=chart,
|
2022-09-13 22:31:21 +00:00
|
|
|
**kwargs,
|
2022-09-06 20:10:40 +00:00
|
|
|
)
|
|
|
|
lines.append(line)
|
|
|
|
|
|
|
|
return lines
|
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
def stage_order(
|
2021-03-08 14:05:37 +00:00
|
|
|
self,
|
2021-08-09 15:21:05 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
action: str,
|
2021-08-15 17:38:46 +00:00
|
|
|
trigger_type: str,
|
2021-08-09 15:21:05 +00:00
|
|
|
|
2022-09-07 15:30:41 +00:00
|
|
|
) -> list[LevelLine]:
|
|
|
|
'''
|
|
|
|
Stage an order for submission by showing level lines and
|
|
|
|
configuring the order request message dynamically based on
|
|
|
|
allocator settings.
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-08-09 15:21:05 +00:00
|
|
|
'''
|
2021-06-16 12:28:57 +00:00
|
|
|
# not initialized yet
|
2022-09-07 17:24:17 +00:00
|
|
|
cursor = self.godw.get_cursor()
|
2022-09-12 19:39:40 +00:00
|
|
|
if not cursor:
|
|
|
|
return
|
2022-09-07 17:24:17 +00:00
|
|
|
|
2022-09-12 19:39:40 +00:00
|
|
|
chart = cursor.linked.chart
|
2022-09-07 17:24:17 +00:00
|
|
|
if (
|
|
|
|
not chart
|
|
|
|
and cursor
|
|
|
|
and cursor.active_plot
|
|
|
|
):
|
2021-06-16 12:28:57 +00:00
|
|
|
return
|
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
chart = cursor.active_plot
|
|
|
|
price = cursor._datum_xy[1]
|
2022-09-12 19:39:40 +00:00
|
|
|
if not price:
|
|
|
|
# zero prices are not supported by any means
|
|
|
|
# since that's illogical / a no-op.
|
|
|
|
return
|
|
|
|
|
2023-05-24 19:30:17 +00:00
|
|
|
mkt: MktPair = self.chart.linked.mkt
|
2021-03-14 00:31:03 +00:00
|
|
|
|
2023-04-11 02:22:17 +00:00
|
|
|
# NOTE : we could also use instead,
|
2023-05-24 19:30:17 +00:00
|
|
|
# mkt.quantize(price, quantity_type='price')
|
2023-04-11 02:22:17 +00:00
|
|
|
# but it returns a Decimal and it's probably gonna
|
|
|
|
# be slower?
|
|
|
|
# TODO: should we be enforcing this precision
|
|
|
|
# at a different layer in the stack? right now
|
|
|
|
# any precision error will literally be relayed
|
|
|
|
# all the way back from the backend.
|
|
|
|
|
|
|
|
price = round(
|
|
|
|
price,
|
2023-05-28 17:13:43 +00:00
|
|
|
ndigits=mkt.price_tick_digits,
|
2023-04-11 02:22:17 +00:00
|
|
|
)
|
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
order = self._staged_order = Order(
|
2021-03-14 00:31:03 +00:00
|
|
|
action=action,
|
2021-08-15 17:38:46 +00:00
|
|
|
price=price,
|
2021-09-14 17:10:39 +00:00
|
|
|
account=self.current_pp.alloc.account,
|
2021-08-15 17:38:46 +00:00
|
|
|
size=0,
|
2023-05-24 19:30:17 +00:00
|
|
|
symbol=mkt.fqme,
|
|
|
|
brokers=[mkt.broker],
|
2021-08-15 17:38:46 +00:00
|
|
|
oid='', # filled in on submit
|
|
|
|
exec_mode=trigger_type, # dark or live
|
|
|
|
)
|
|
|
|
|
2022-09-07 17:24:17 +00:00
|
|
|
# TODO: staged line mirroring? - need to keep track of multiple
|
|
|
|
# staged lines in editor - need to call
|
|
|
|
# `LineEditor.unstage_line()` on all staged lines..
|
|
|
|
# lines = self.lines_from_order(
|
|
|
|
|
2022-10-03 17:41:40 +00:00
|
|
|
line = self.new_line_from_order(
|
2021-08-15 17:38:46 +00:00
|
|
|
order,
|
2022-09-07 17:24:17 +00:00
|
|
|
chart=chart,
|
2021-08-15 17:38:46 +00:00
|
|
|
show_markers=True,
|
2022-09-23 21:16:48 +00:00
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
# just for the stage line to avoid
|
|
|
|
# flickering while moving the cursor
|
|
|
|
# around where it might trigger highlight
|
|
|
|
# then non-highlight depending on sensitivity
|
|
|
|
always_show_labels=True,
|
2022-09-23 21:16:48 +00:00
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
# don't highlight the "staging" line
|
|
|
|
highlight_on_hover=False,
|
2022-09-23 21:16:48 +00:00
|
|
|
|
2021-08-15 17:38:46 +00:00
|
|
|
# prevent flickering of marker while moving/tracking cursor
|
|
|
|
only_show_markers_on_hover=False,
|
|
|
|
)
|
2022-09-07 17:24:17 +00:00
|
|
|
self.lines.stage_line(line)
|
|
|
|
|
|
|
|
# add line to cursor trackers
|
|
|
|
cursor._trackers.add(line)
|
|
|
|
|
|
|
|
# TODO: see above about mirroring.
|
|
|
|
# for line in lines:
|
|
|
|
# if line._chart is chart:
|
|
|
|
# self.lines.stage_line(line)
|
|
|
|
# cursor._trackers.add(line)
|
|
|
|
# break
|
2021-08-15 17:38:46 +00:00
|
|
|
|
|
|
|
# hide crosshair y-line and label
|
|
|
|
cursor.hide_xhair()
|
|
|
|
|
2022-09-07 17:24:17 +00:00
|
|
|
return line
|
2021-08-15 17:38:46 +00:00
|
|
|
|
|
|
|
def submit_order(
|
|
|
|
self,
|
2022-08-05 18:51:15 +00:00
|
|
|
send_msg: bool = True,
|
2023-02-21 14:14:26 +00:00
|
|
|
order: Order | None = None,
|
2021-08-15 17:38:46 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
) -> Dialog:
|
2022-07-08 14:55:02 +00:00
|
|
|
'''
|
|
|
|
Send execution order to EMS return a level line to
|
2021-08-15 17:38:46 +00:00
|
|
|
represent the order on a chart.
|
|
|
|
|
|
|
|
'''
|
2022-08-05 18:51:15 +00:00
|
|
|
if not order:
|
2023-01-02 21:21:23 +00:00
|
|
|
staged: Order = self._staged_order
|
2023-03-22 02:28:26 +00:00
|
|
|
|
2022-08-18 20:04:44 +00:00
|
|
|
# apply order fields for ems
|
2022-08-05 18:51:15 +00:00
|
|
|
oid = str(uuid.uuid4())
|
2023-03-22 02:28:26 +00:00
|
|
|
|
2023-03-22 15:41:11 +00:00
|
|
|
# NOTE: we have to str-ify `MktPair` first since we can't
|
|
|
|
# cast to it without being mega explicit with
|
|
|
|
# `msgspec.Struct`, which we're not yet..
|
2023-04-11 02:22:17 +00:00
|
|
|
order: Order = staged.copy({
|
2023-03-22 15:41:11 +00:00
|
|
|
'symbol': str(staged.symbol),
|
|
|
|
'oid': oid,
|
|
|
|
})
|
2022-08-05 18:51:15 +00:00
|
|
|
|
2022-09-06 20:10:40 +00:00
|
|
|
lines = self.lines_from_order(
|
2021-08-15 17:38:46 +00:00
|
|
|
order,
|
|
|
|
show_markers=True,
|
|
|
|
)
|
|
|
|
# register the "submitted" line under the cursor
|
|
|
|
# to be displayed when above order ack arrives
|
|
|
|
# (means the marker graphic doesn't show on screen until the
|
|
|
|
# order is live in the emsd).
|
|
|
|
|
|
|
|
# TODO: update the line once an ack event comes back
|
|
|
|
# from the EMS!
|
|
|
|
# maybe place a grey line in "submission" mode
|
|
|
|
# which will be updated to it's appropriate action
|
|
|
|
# color once the submission ack arrives.
|
2022-09-06 20:10:40 +00:00
|
|
|
self.lines.submit_lines(
|
|
|
|
lines=lines,
|
2022-08-05 18:51:15 +00:00
|
|
|
uuid=order.oid,
|
2021-03-08 14:05:37 +00:00
|
|
|
)
|
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
dialog = Dialog(
|
2022-08-05 18:51:15 +00:00
|
|
|
uuid=order.oid,
|
2021-08-15 17:38:46 +00:00
|
|
|
order=order,
|
2022-11-25 21:41:26 +00:00
|
|
|
symbol=order.symbol, # XXX: always a str?
|
2022-09-06 20:10:40 +00:00
|
|
|
lines=lines,
|
2021-08-15 17:38:46 +00:00
|
|
|
last_status_close=self.multistatus.open_status(
|
2022-08-05 18:51:15 +00:00
|
|
|
f'submitting {order.exec_mode}-{order.action}',
|
|
|
|
final_msg=f'submitted {order.exec_mode}-{order.action}',
|
2021-08-15 17:38:46 +00:00
|
|
|
clear_on_next=True,
|
|
|
|
)
|
|
|
|
)
|
|
|
|
# enter submission which will be popped once a response
|
|
|
|
# from the EMS is received to move the order to a different# status
|
2022-08-05 18:51:15 +00:00
|
|
|
self.dialogs[order.oid] = dialog
|
2021-08-15 17:38:46 +00:00
|
|
|
|
2022-09-06 20:10:40 +00:00
|
|
|
for line in lines:
|
|
|
|
|
|
|
|
# TODO: create a new ``OrderLine`` with this optional var defined
|
|
|
|
line.dialog = dialog
|
|
|
|
|
|
|
|
# hook up mouse drag handlers
|
|
|
|
line._on_drag_start = self.order_line_modify_start
|
|
|
|
line._on_drag_end = self.order_line_modify_complete
|
2021-08-15 17:38:46 +00:00
|
|
|
|
|
|
|
# send order cmd to ems
|
2022-08-05 18:51:15 +00:00
|
|
|
if send_msg:
|
2023-04-08 23:22:53 +00:00
|
|
|
self.client.send_nowait(order)
|
2022-08-05 18:51:15 +00:00
|
|
|
else:
|
|
|
|
# just register for control over this order
|
|
|
|
# TODO: some kind of mini-perms system here based on
|
|
|
|
# an out-of-band tagging/auth sub-sys for multiplayer
|
|
|
|
# order control?
|
2023-04-08 23:22:53 +00:00
|
|
|
self.client._sent_orders[order.oid] = order
|
2021-08-15 17:38:46 +00:00
|
|
|
|
|
|
|
return dialog
|
|
|
|
|
|
|
|
# order-line modify handlers
|
|
|
|
|
|
|
|
def order_line_modify_start(
|
|
|
|
self,
|
|
|
|
line: LevelLine,
|
|
|
|
|
|
|
|
) -> None:
|
|
|
|
|
2022-09-07 14:42:12 +00:00
|
|
|
log.info(f'Order modify: {line}')
|
2021-08-15 17:38:46 +00:00
|
|
|
# cancel original order until new position is found?
|
|
|
|
# TODO: make a config option for this behaviour..
|
|
|
|
|
|
|
|
def order_line_modify_complete(
|
|
|
|
self,
|
|
|
|
line: LevelLine,
|
|
|
|
|
|
|
|
) -> None:
|
2023-04-11 02:22:17 +00:00
|
|
|
'''
|
|
|
|
Retreive the level line's end state, compute the size
|
|
|
|
and price for the new price-level, send an update msg to
|
|
|
|
the EMS, adjust mirrored level line on secondary chart.
|
2021-08-15 17:38:46 +00:00
|
|
|
|
2023-04-11 02:22:17 +00:00
|
|
|
'''
|
2023-05-24 19:30:17 +00:00
|
|
|
mktinfo: MktPair = self.chart.linked.mkt
|
2023-04-11 02:22:17 +00:00
|
|
|
level = round(
|
|
|
|
line.value(),
|
2023-05-28 17:13:43 +00:00
|
|
|
ndigits=mktinfo.price_tick_digits,
|
2023-04-11 02:22:17 +00:00
|
|
|
)
|
2022-10-03 17:41:40 +00:00
|
|
|
# updated by level change callback set in ``.new_line_from_order()``
|
2022-09-07 14:42:12 +00:00
|
|
|
dialog = line.dialog
|
|
|
|
size = dialog.order.size
|
2021-08-15 17:38:46 +00:00
|
|
|
|
2022-10-03 17:41:40 +00:00
|
|
|
# NOTE: sends modified order msg to EMS
|
2023-04-08 23:22:53 +00:00
|
|
|
self.client.update_nowait(
|
2021-08-15 17:38:46 +00:00
|
|
|
uuid=line.dialog.uuid,
|
|
|
|
price=level,
|
|
|
|
size=size,
|
|
|
|
)
|
|
|
|
|
2022-09-07 14:42:12 +00:00
|
|
|
# adjust corresponding slow/fast chart line
|
|
|
|
# to match level
|
|
|
|
for ln in dialog.lines:
|
|
|
|
if ln is not line:
|
|
|
|
ln.set_level(line.value())
|
2021-08-15 17:38:46 +00:00
|
|
|
|
2022-09-07 14:42:12 +00:00
|
|
|
# EMS response msg handlers
|
2021-08-09 15:21:05 +00:00
|
|
|
def on_submit(
|
|
|
|
self,
|
2022-10-03 17:41:40 +00:00
|
|
|
uuid: str,
|
2023-02-21 14:14:26 +00:00
|
|
|
order: Order | None = None,
|
2021-08-09 15:21:05 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
) -> Dialog:
|
2021-08-09 15:21:05 +00:00
|
|
|
'''
|
|
|
|
Order submitted status event handler.
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-07-13 19:28:19 +00:00
|
|
|
Commit the order line and registered order uuid, store ack time stamp.
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-07-13 19:28:19 +00:00
|
|
|
'''
|
2022-09-06 20:10:40 +00:00
|
|
|
lines = self.lines.commit_line(uuid)
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2021-07-13 19:28:19 +00:00
|
|
|
# a submission is the start of a new order dialog
|
|
|
|
dialog = self.dialogs[uuid]
|
2022-09-06 20:10:40 +00:00
|
|
|
dialog.lines = lines
|
2023-05-24 19:30:17 +00:00
|
|
|
cls: Callable | None = dialog.last_status_close
|
|
|
|
if cls:
|
|
|
|
cls()
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2022-09-13 22:31:21 +00:00
|
|
|
for line in lines:
|
2022-10-03 17:41:40 +00:00
|
|
|
|
|
|
|
# if an order msg is provided update the line
|
|
|
|
# **from** that msg.
|
|
|
|
if order:
|
|
|
|
line.set_level(order.price)
|
|
|
|
self.on_level_change_update_next_order_info(
|
|
|
|
level=order.price,
|
|
|
|
line=line,
|
|
|
|
order=order,
|
|
|
|
# use the corresponding position tracker for the
|
|
|
|
# order's account.
|
|
|
|
tracker=self.trackers[order.account],
|
|
|
|
)
|
|
|
|
|
2022-09-13 22:31:21 +00:00
|
|
|
# hide any lines not currently moused-over
|
|
|
|
if not line.get_cursor():
|
|
|
|
line.hide_labels()
|
|
|
|
|
2021-07-13 19:28:19 +00:00
|
|
|
return dialog
|
2021-03-08 14:05:37 +00:00
|
|
|
|
|
|
|
def on_fill(
|
|
|
|
self,
|
2021-08-09 15:21:05 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
uuid: str,
|
|
|
|
price: float,
|
2022-12-09 19:17:36 +00:00
|
|
|
time_s: float,
|
2021-08-09 15:21:05 +00:00
|
|
|
|
2023-02-21 14:14:26 +00:00
|
|
|
pointing: str | None = None,
|
2021-07-13 19:28:19 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
) -> None:
|
2021-08-09 15:21:05 +00:00
|
|
|
'''
|
|
|
|
Fill msg handler.
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-08-09 15:21:05 +00:00
|
|
|
Triggered on reception of a `filled` message from the
|
|
|
|
EMS.
|
|
|
|
|
|
|
|
Update relevant UIs:
|
|
|
|
|
|
|
|
- add arrow annotation on bar
|
|
|
|
- update fill bar size
|
|
|
|
|
|
|
|
'''
|
2021-07-13 19:28:19 +00:00
|
|
|
dialog = self.dialogs[uuid]
|
2022-09-06 20:10:40 +00:00
|
|
|
lines = dialog.lines
|
2022-12-09 19:17:36 +00:00
|
|
|
chart = self.chart
|
|
|
|
|
2022-09-21 19:42:29 +00:00
|
|
|
# XXX: seems to fail on certain types of races?
|
|
|
|
# assert len(lines) == 2
|
2022-09-06 20:10:40 +00:00
|
|
|
if lines:
|
2023-05-24 19:30:17 +00:00
|
|
|
flume: Flume = self.feed.flumes[chart.linked.mkt.fqme]
|
2022-11-10 03:30:15 +00:00
|
|
|
_, _, ratio = flume.get_ds_info()
|
2022-12-09 19:17:36 +00:00
|
|
|
|
|
|
|
for chart, shm in [
|
|
|
|
(self.chart, flume.rt_shm),
|
|
|
|
(self.hist_chart, flume.hist_shm),
|
2022-09-07 01:21:57 +00:00
|
|
|
]:
|
2022-12-09 19:17:36 +00:00
|
|
|
viz = chart.get_viz(chart.name)
|
|
|
|
index_field = viz.index_field
|
|
|
|
arr = shm.array
|
2022-12-13 21:02:34 +00:00
|
|
|
|
|
|
|
# TODO: borked for int index based..
|
2022-12-09 19:17:36 +00:00
|
|
|
index = flume.get_index(time_s, arr)
|
|
|
|
|
2022-12-13 21:02:34 +00:00
|
|
|
# get absolute index for arrow placement
|
|
|
|
arrow_index = arr[index_field][index]
|
2022-12-09 19:17:36 +00:00
|
|
|
|
2022-09-06 20:10:40 +00:00
|
|
|
self.arrows.add(
|
2022-09-07 01:21:57 +00:00
|
|
|
chart.plotItem,
|
2022-09-06 20:10:40 +00:00
|
|
|
uuid,
|
2022-12-13 21:02:34 +00:00
|
|
|
arrow_index,
|
2022-09-06 20:10:40 +00:00
|
|
|
price,
|
|
|
|
pointing=pointing,
|
2022-09-07 01:21:57 +00:00
|
|
|
color=lines[0].color
|
2022-09-06 20:10:40 +00:00
|
|
|
)
|
2021-07-13 19:28:19 +00:00
|
|
|
else:
|
2022-09-06 20:10:40 +00:00
|
|
|
log.warn("No line(s) for order {uuid}!?")
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-08-09 15:21:05 +00:00
|
|
|
def on_cancel(
|
|
|
|
self,
|
|
|
|
uuid: str
|
|
|
|
|
|
|
|
) -> None:
|
2021-03-17 12:36:34 +00:00
|
|
|
|
2023-06-26 17:39:32 +00:00
|
|
|
msg: Order = self.client._sent_orders.pop(uuid, None)
|
2021-03-17 12:36:34 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
if msg is not None:
|
|
|
|
self.lines.remove_line(uuid=uuid)
|
2021-06-22 11:17:49 +00:00
|
|
|
self.chart.linked.cursor.show_xhair()
|
2021-03-17 12:36:34 +00:00
|
|
|
|
2021-07-13 19:28:19 +00:00
|
|
|
dialog = self.dialogs.pop(uuid, None)
|
|
|
|
if dialog:
|
|
|
|
dialog.last_status_close()
|
2021-03-08 14:05:37 +00:00
|
|
|
else:
|
|
|
|
log.warning(
|
|
|
|
f'Received cancel for unsubmitted order {pformat(msg)}'
|
|
|
|
)
|
|
|
|
|
2021-06-17 21:00:57 +00:00
|
|
|
def cancel_orders_under_cursor(self) -> list[str]:
|
2023-06-17 20:50:56 +00:00
|
|
|
return self.cancel_orders(
|
|
|
|
self.oids_from_lines(
|
|
|
|
self.lines.lines_under_cursor()
|
|
|
|
)
|
2021-06-17 21:00:57 +00:00
|
|
|
)
|
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
def oids_from_lines(
|
2021-06-17 21:00:57 +00:00
|
|
|
self,
|
|
|
|
lines: list[LevelLine],
|
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
) -> list[Dialog]:
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
oids: set[str] = set()
|
|
|
|
for line in lines:
|
|
|
|
dialog: Dialog = getattr(line, 'dialog', None)
|
|
|
|
oid: str = dialog.uuid
|
|
|
|
if (
|
|
|
|
dialog
|
|
|
|
and oid not in oids
|
|
|
|
):
|
|
|
|
oids.add(oid)
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
return oids
|
2021-07-13 19:28:19 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
def cancel_orders(
|
|
|
|
self,
|
|
|
|
oids: list[str],
|
2021-07-13 19:28:19 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
) -> None:
|
|
|
|
'''
|
|
|
|
Cancel all orders from a list of order ids: `oids`.
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
'''
|
|
|
|
key = self.multistatus.open_status(
|
|
|
|
f'cancelling {len(oids)} orders',
|
|
|
|
final_msg=f'cancelled orders:\n{oids}',
|
|
|
|
group_key=True
|
|
|
|
)
|
|
|
|
for oid in oids:
|
|
|
|
dialog: Dialog = self.dialogs[oid]
|
|
|
|
self.client.cancel_nowait(uuid=oid)
|
|
|
|
cancel_status_close = self.multistatus.open_status(
|
|
|
|
f'cancelling order {oid}',
|
|
|
|
group_key=key,
|
|
|
|
)
|
|
|
|
dialog.last_status_close = cancel_status_close
|
2021-06-17 21:00:57 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
def cancel_all_orders(self) -> None:
|
|
|
|
'''
|
|
|
|
Cancel all unique orders / executions by extracting unique
|
|
|
|
order ids from all order lines and then submitting cancel
|
|
|
|
requests for each dialog.
|
|
|
|
|
|
|
|
'''
|
|
|
|
return self.cancel_orders(
|
|
|
|
self.oids_from_lines(
|
|
|
|
self.lines.all_lines()
|
|
|
|
)
|
|
|
|
)
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2022-08-06 00:39:00 +00:00
|
|
|
def load_unknown_dialog_from_msg(
|
|
|
|
self,
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
msg: Status,
|
2022-08-06 00:39:00 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
) -> Dialog:
|
2022-08-08 17:35:01 +00:00
|
|
|
# NOTE: the `.order` attr **must** be set with the
|
|
|
|
# equivalent order msg in order to be loaded.
|
2022-08-18 20:04:44 +00:00
|
|
|
order = msg.req
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
oid = str(msg.oid)
|
|
|
|
symbol = order.symbol
|
2022-08-08 17:35:01 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
# TODO: MEGA UGGG ZONEEEE!
|
|
|
|
src = msg.src
|
|
|
|
if (
|
|
|
|
src
|
2022-08-14 20:42:29 +00:00
|
|
|
and src not in ('dark', 'paperboi')
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
and src not in symbol
|
|
|
|
):
|
2023-04-19 17:58:38 +00:00
|
|
|
fqme = symbol + '.' + src
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
brokername = src
|
2022-08-06 00:39:00 +00:00
|
|
|
else:
|
2023-04-19 17:58:38 +00:00
|
|
|
fqme = symbol
|
|
|
|
*head, brokername = fqme.rsplit('.')
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
|
|
|
|
# fill out complex fields
|
|
|
|
order.oid = str(order.oid)
|
|
|
|
order.brokers = [brokername]
|
2023-04-20 17:04:40 +00:00
|
|
|
|
|
|
|
# TODO: change this over to `MktPair`, but it's
|
|
|
|
# gonna be tough since we don't have any such data
|
|
|
|
# really in our clearing msg schema..
|
|
|
|
order.symbol = Symbol.from_fqme(
|
|
|
|
fqsn=fqme,
|
2022-08-06 00:39:00 +00:00
|
|
|
info={},
|
|
|
|
)
|
|
|
|
dialog = self.submit_order(
|
|
|
|
send_msg=False,
|
|
|
|
order=order,
|
|
|
|
)
|
|
|
|
assert self.dialogs[oid] == dialog
|
|
|
|
return dialog
|
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
|
2021-08-27 18:53:30 +00:00
|
|
|
@asynccontextmanager
|
|
|
|
async def open_order_mode(
|
2021-06-16 12:28:57 +00:00
|
|
|
|
2021-08-28 18:18:37 +00:00
|
|
|
feed: Feed,
|
2022-09-06 18:30:35 +00:00
|
|
|
godw: GodWidget,
|
2023-05-22 16:13:00 +00:00
|
|
|
fqme: str,
|
2021-06-16 12:28:57 +00:00
|
|
|
started: trio.Event,
|
2023-02-25 23:56:25 +00:00
|
|
|
loglevel: str = 'info'
|
2021-06-16 12:28:57 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
) -> None:
|
2023-06-26 17:39:32 +00:00
|
|
|
'''
|
|
|
|
Activate chart-trader order mode loop:
|
2021-08-09 15:21:05 +00:00
|
|
|
|
2021-06-10 15:31:40 +00:00
|
|
|
- connect to emsd
|
|
|
|
- load existing positions
|
2021-08-09 15:21:05 +00:00
|
|
|
- begin EMS response handling loop which updates local
|
|
|
|
state, mostly graphics / UI.
|
2021-06-10 15:31:40 +00:00
|
|
|
|
|
|
|
'''
|
2022-09-06 18:30:35 +00:00
|
|
|
chart = godw.rt_linked.chart
|
|
|
|
hist_chart = godw.hist_linked.chart
|
|
|
|
|
2021-07-23 18:20:29 +00:00
|
|
|
multistatus = chart.window().status_bar
|
|
|
|
done = multistatus.open_status('starting order mode..')
|
2021-04-13 22:25:13 +00:00
|
|
|
|
2023-04-08 23:22:53 +00:00
|
|
|
client: OrderClient
|
2021-07-16 22:32:56 +00:00
|
|
|
trades_stream: tractor.MsgStream
|
2021-10-29 20:05:50 +00:00
|
|
|
|
|
|
|
# The keys in this dict **must** be in set our set of "normalized"
|
|
|
|
# symbol names (i.e. the same names you'd get back in search
|
|
|
|
# results) in order for position msgs to correctly trigger the
|
|
|
|
# display of a position indicator on screen.
|
2023-04-11 02:22:17 +00:00
|
|
|
position_msgs: dict[str, dict[str, BrokerdPosition]]
|
2021-07-16 22:32:56 +00:00
|
|
|
|
2021-03-08 14:05:37 +00:00
|
|
|
# spawn EMS actor-service
|
2021-05-24 14:09:54 +00:00
|
|
|
async with (
|
2023-04-08 23:22:53 +00:00
|
|
|
open_ems(
|
2023-05-22 16:13:00 +00:00
|
|
|
fqme,
|
2023-04-08 23:22:53 +00:00
|
|
|
loglevel=loglevel,
|
|
|
|
) as (
|
|
|
|
client,
|
2021-07-16 22:32:56 +00:00
|
|
|
trades_stream,
|
2021-09-14 14:37:30 +00:00
|
|
|
position_msgs,
|
|
|
|
brokerd_accounts,
|
2022-08-06 00:39:00 +00:00
|
|
|
ems_dialog_msgs,
|
2021-07-16 22:32:56 +00:00
|
|
|
),
|
2021-09-07 13:23:18 +00:00
|
|
|
trio.open_nursery() as tn,
|
2021-06-16 12:28:57 +00:00
|
|
|
|
2021-05-24 14:09:54 +00:00
|
|
|
):
|
2023-05-22 16:13:00 +00:00
|
|
|
log.info(f'Opening order mode for {fqme}')
|
2021-08-23 18:48:20 +00:00
|
|
|
|
|
|
|
# annotations editors
|
2022-09-06 18:30:35 +00:00
|
|
|
lines = LineEditor(godw=godw)
|
2022-09-07 01:21:57 +00:00
|
|
|
arrows = ArrowEditor(godw=godw)
|
2021-07-16 22:32:56 +00:00
|
|
|
|
2023-05-24 19:30:17 +00:00
|
|
|
# market endpoint info
|
|
|
|
mkt: MktPair = chart.linked.mkt
|
2021-09-07 01:36:30 +00:00
|
|
|
|
2021-09-10 15:50:24 +00:00
|
|
|
# map of per-provider account keys to position tracker instances
|
|
|
|
trackers: dict[str, PositionTracker] = {}
|
2021-09-07 01:36:30 +00:00
|
|
|
|
2021-09-05 19:13:35 +00:00
|
|
|
# load account names from ``brokers.toml``
|
2023-06-17 20:50:56 +00:00
|
|
|
accounts_def: bidict[str, str | None] = config.load_accounts(
|
2023-05-24 19:30:17 +00:00
|
|
|
providers=[mkt.broker],
|
2021-09-14 14:37:30 +00:00
|
|
|
)
|
2023-06-26 17:39:32 +00:00
|
|
|
# await tractor.pause()
|
2021-09-14 14:37:30 +00:00
|
|
|
|
2022-07-02 19:53:12 +00:00
|
|
|
# XXX: ``brokerd`` delivers a set of account names that it
|
|
|
|
# allows use of but the user also can define the accounts they'd
|
|
|
|
# like to use, in order, in their `brokers.toml` file.
|
2023-06-26 17:39:32 +00:00
|
|
|
accounts: dict[str, str] = {}
|
2021-09-14 14:37:30 +00:00
|
|
|
for name in brokerd_accounts:
|
2021-09-14 18:26:15 +00:00
|
|
|
# ensure name is in ``brokers.toml``
|
2021-09-14 14:37:30 +00:00
|
|
|
accounts[name] = accounts_def[name]
|
|
|
|
|
2023-06-26 17:39:32 +00:00
|
|
|
# always add a paper entry so that paper cleared
|
|
|
|
# order dialogs can be tracked in the order mode UIs.
|
|
|
|
accounts['paper'] = 'paper'
|
|
|
|
|
2021-09-14 18:26:15 +00:00
|
|
|
# first account listed is the one we select at startup
|
|
|
|
# (aka order based selection).
|
2021-10-12 14:34:54 +00:00
|
|
|
pp_account = next(
|
|
|
|
# choose first account based on line order from `brokers.toml`.
|
|
|
|
iter(accounts.keys())
|
|
|
|
) if accounts else 'paper'
|
2021-09-10 15:50:24 +00:00
|
|
|
|
2021-09-14 18:26:15 +00:00
|
|
|
# update pp trackers with data relayed from ``brokerd``.
|
|
|
|
for account_name in accounts:
|
2021-09-10 18:01:29 +00:00
|
|
|
|
2021-09-10 15:50:24 +00:00
|
|
|
# net-zero pp
|
|
|
|
startup_pp = Position(
|
2023-05-24 19:30:17 +00:00
|
|
|
mkt=mkt,
|
2021-09-10 15:50:24 +00:00
|
|
|
size=0,
|
2022-07-27 16:08:13 +00:00
|
|
|
ppu=0,
|
2022-06-14 20:22:30 +00:00
|
|
|
|
|
|
|
# XXX: BLEH, do we care about this on the client side?
|
2023-05-24 19:30:17 +00:00
|
|
|
bs_mktid=mkt.key,
|
2021-09-10 15:50:24 +00:00
|
|
|
)
|
2022-08-29 15:36:09 +00:00
|
|
|
|
2022-03-18 21:31:09 +00:00
|
|
|
# allocator config
|
2023-05-24 19:30:17 +00:00
|
|
|
alloc: Allocator = mk_allocator(
|
|
|
|
mkt=mkt,
|
2021-09-10 18:01:29 +00:00
|
|
|
account=account_name,
|
|
|
|
|
|
|
|
# if this startup size is greater the allocator limit,
|
|
|
|
# the limit is increased internally in this factory.
|
2021-09-10 15:50:24 +00:00
|
|
|
startup_pp=startup_pp,
|
|
|
|
)
|
2021-09-10 18:01:29 +00:00
|
|
|
|
2021-09-10 15:50:24 +00:00
|
|
|
pp_tracker = PositionTracker(
|
2022-09-07 19:55:23 +00:00
|
|
|
[chart, hist_chart],
|
2021-09-10 15:50:24 +00:00
|
|
|
alloc,
|
|
|
|
startup_pp
|
|
|
|
)
|
2022-09-07 19:55:23 +00:00
|
|
|
pp_tracker.nav.hide()
|
2021-09-10 18:01:29 +00:00
|
|
|
trackers[account_name] = pp_tracker
|
2021-09-10 15:50:24 +00:00
|
|
|
|
2021-09-10 18:01:29 +00:00
|
|
|
assert pp_tracker.startup_pp.size == pp_tracker.live_pp.size
|
2021-09-10 15:50:24 +00:00
|
|
|
|
|
|
|
# TODO: do we even really need the "startup pp" or can we
|
|
|
|
# just take the max and pass that into the some state / the
|
|
|
|
# alloc?
|
2021-09-10 18:01:29 +00:00
|
|
|
pp_tracker.update_from_pp()
|
|
|
|
|
2021-10-22 16:58:12 +00:00
|
|
|
# on existing position, show pp tracking graphics
|
2021-09-10 18:01:29 +00:00
|
|
|
if pp_tracker.startup_pp.size != 0:
|
2022-09-07 19:55:23 +00:00
|
|
|
pp_tracker.nav.show()
|
|
|
|
pp_tracker.nav.hide_info()
|
2021-09-10 18:01:29 +00:00
|
|
|
|
2021-09-12 23:36:14 +00:00
|
|
|
# setup order mode sidepane widgets
|
2022-06-05 21:01:41 +00:00
|
|
|
form: FieldsForm = chart.sidepane
|
|
|
|
form.vbox.setSpacing(
|
2022-08-05 18:51:15 +00:00
|
|
|
int((1 + 5 / 8) * _font.px_size)
|
2022-02-06 21:17:32 +00:00
|
|
|
)
|
2021-09-16 13:19:02 +00:00
|
|
|
|
2022-06-05 21:01:41 +00:00
|
|
|
from ._feedstatus import mk_feed_label
|
|
|
|
|
|
|
|
feed_label = mk_feed_label(
|
|
|
|
form,
|
|
|
|
feed,
|
|
|
|
chart,
|
2021-09-16 13:19:02 +00:00
|
|
|
)
|
2021-09-12 23:36:14 +00:00
|
|
|
|
2022-06-05 21:01:41 +00:00
|
|
|
# XXX: we set this because?
|
|
|
|
form.feed_label = feed_label
|
2021-08-27 18:53:30 +00:00
|
|
|
order_pane = SettingsPane(
|
2021-08-23 18:48:20 +00:00
|
|
|
form=form,
|
2021-09-07 01:36:30 +00:00
|
|
|
# XXX: ugh, so hideous...
|
2021-08-23 18:48:20 +00:00
|
|
|
fill_bar=form.fill_bar,
|
|
|
|
pnl_label=form.left_label,
|
|
|
|
step_label=form.bottom_label,
|
|
|
|
limit_label=form.top_label,
|
|
|
|
)
|
2021-09-14 14:37:30 +00:00
|
|
|
order_pane.set_accounts(list(trackers.keys()))
|
|
|
|
|
2022-06-05 21:01:41 +00:00
|
|
|
form.vbox.addWidget(
|
|
|
|
feed_label,
|
|
|
|
alignment=Qt.AlignBottom,
|
|
|
|
)
|
|
|
|
|
2021-09-14 16:26:26 +00:00
|
|
|
# update pp icons
|
2021-09-12 23:36:14 +00:00
|
|
|
for name, tracker in trackers.items():
|
2021-09-14 16:26:26 +00:00
|
|
|
order_pane.update_account_icons({name: tracker.live_pp})
|
2021-09-07 02:05:42 +00:00
|
|
|
|
2021-09-07 01:36:30 +00:00
|
|
|
# top level abstraction which wraps all this crazyness into
|
|
|
|
# a namespace..
|
|
|
|
mode = OrderMode(
|
2022-09-07 15:30:41 +00:00
|
|
|
godw,
|
2022-09-07 01:21:57 +00:00
|
|
|
feed,
|
2021-09-07 01:36:30 +00:00
|
|
|
chart,
|
2022-09-06 18:30:35 +00:00
|
|
|
hist_chart,
|
2021-09-10 18:59:42 +00:00
|
|
|
tn,
|
2023-04-08 23:22:53 +00:00
|
|
|
client,
|
2021-09-07 01:36:30 +00:00
|
|
|
lines,
|
|
|
|
arrows,
|
|
|
|
multistatus,
|
|
|
|
pane=order_pane,
|
2021-09-10 15:50:24 +00:00
|
|
|
trackers=trackers,
|
|
|
|
|
2021-09-07 01:36:30 +00:00
|
|
|
)
|
2021-09-10 15:50:24 +00:00
|
|
|
# XXX: MUST be set
|
|
|
|
order_pane.order_mode = mode
|
|
|
|
|
|
|
|
# select a pp to track
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
tracker: PositionTracker = trackers[pp_account]
|
2021-09-10 15:50:24 +00:00
|
|
|
mode.current_pp = tracker
|
2022-09-07 19:55:23 +00:00
|
|
|
tracker.nav.show()
|
|
|
|
tracker.nav.hide_info()
|
2021-08-23 18:48:20 +00:00
|
|
|
|
2021-08-25 14:38:04 +00:00
|
|
|
# XXX: would love to not have to do this separate from edit
|
|
|
|
# fields (which are done in an async loop - see below)
|
|
|
|
# connect selection signals (from drop down widgets)
|
|
|
|
# to order sync pane handler
|
|
|
|
for key in ('account', 'size_unit',):
|
2021-08-23 18:48:20 +00:00
|
|
|
w = form.fields[key]
|
|
|
|
w.currentTextChanged.connect(
|
|
|
|
partial(
|
2021-09-11 17:20:44 +00:00
|
|
|
order_pane.on_selection_change,
|
2021-08-23 18:48:20 +00:00
|
|
|
key=key,
|
|
|
|
)
|
|
|
|
)
|
2021-07-23 18:20:29 +00:00
|
|
|
|
2021-09-10 15:50:24 +00:00
|
|
|
# make fill bar and positioning snapshot
|
2022-09-21 19:42:29 +00:00
|
|
|
order_pane.update_status_ui(tracker)
|
2021-09-10 15:50:24 +00:00
|
|
|
|
2021-08-10 21:02:17 +00:00
|
|
|
# TODO: create a mode "manager" of sorts?
|
|
|
|
# -> probably just call it "UxModes" err sumthin?
|
2021-07-22 15:39:47 +00:00
|
|
|
# so that view handlers can access it
|
2022-09-06 12:14:54 +00:00
|
|
|
chart.view.order_mode = mode
|
|
|
|
hist_chart.view.order_mode = mode
|
2021-07-16 22:32:56 +00:00
|
|
|
|
2021-09-10 18:59:42 +00:00
|
|
|
order_pane.on_ui_settings_change('account', pp_account)
|
2021-09-11 22:41:49 +00:00
|
|
|
mode.pane.display_pnl(mode.current_pp)
|
2021-08-28 18:18:37 +00:00
|
|
|
|
2021-04-05 12:09:26 +00:00
|
|
|
# Begin order-response streaming
|
2021-06-10 15:31:40 +00:00
|
|
|
done()
|
2021-05-31 23:48:11 +00:00
|
|
|
|
2022-08-29 15:36:09 +00:00
|
|
|
# Pack position messages by account, should only be one-to-one.
|
|
|
|
# NOTE: requires the backend exactly specifies
|
|
|
|
# the expected symbol key in its positions msg.
|
2023-04-11 02:22:17 +00:00
|
|
|
for (
|
|
|
|
(broker, acctid),
|
|
|
|
pps_by_fqme
|
|
|
|
) in position_msgs.items():
|
|
|
|
for msg in pps_by_fqme.values():
|
2022-08-27 03:41:47 +00:00
|
|
|
await process_trade_msg(
|
|
|
|
mode,
|
2023-04-08 23:22:53 +00:00
|
|
|
client,
|
2022-08-27 03:41:47 +00:00
|
|
|
msg,
|
|
|
|
)
|
|
|
|
|
2021-06-16 12:28:57 +00:00
|
|
|
# start async input handling for chart's view
|
2021-07-24 20:09:42 +00:00
|
|
|
async with (
|
2021-08-25 14:38:04 +00:00
|
|
|
|
|
|
|
# ``ChartView`` input async handler startup
|
2021-08-15 17:38:46 +00:00
|
|
|
chart.view.open_async_input_handler(),
|
2022-09-06 12:14:54 +00:00
|
|
|
hist_chart.view.open_async_input_handler(),
|
2021-07-24 20:09:42 +00:00
|
|
|
|
2021-08-23 18:48:20 +00:00
|
|
|
# pp pane kb inputs
|
|
|
|
open_form_input_handling(
|
|
|
|
form,
|
|
|
|
focus_next=chart.linked.godwidget,
|
2021-08-25 14:38:04 +00:00
|
|
|
on_value_change=order_pane.on_ui_settings_change,
|
2021-08-23 18:48:20 +00:00
|
|
|
),
|
2021-07-24 20:09:42 +00:00
|
|
|
|
|
|
|
):
|
2021-06-16 12:28:57 +00:00
|
|
|
# signal to top level symbol loading task we're ready
|
|
|
|
# to handle input since the ems connection is ready
|
|
|
|
started.set()
|
2021-06-10 16:02:57 +00:00
|
|
|
|
2022-08-06 00:39:00 +00:00
|
|
|
for oid, msg in ems_dialog_msgs.items():
|
|
|
|
|
|
|
|
# HACK ALERT: ensure a resp field is filled out since
|
|
|
|
# techincally the call below expects a ``Status``. TODO:
|
|
|
|
# parse into proper ``Status`` equivalents ems-side?
|
2022-08-08 17:35:01 +00:00
|
|
|
# msg.setdefault('resp', msg['broker_details']['resp'])
|
|
|
|
# msg.setdefault('oid', msg['broker_details']['oid'])
|
2022-08-06 00:39:00 +00:00
|
|
|
msg['brokerd_msg'] = msg
|
|
|
|
|
|
|
|
await process_trade_msg(
|
|
|
|
mode,
|
2023-04-08 23:22:53 +00:00
|
|
|
client,
|
2022-08-06 00:39:00 +00:00
|
|
|
msg,
|
|
|
|
)
|
|
|
|
|
2021-09-07 13:23:18 +00:00
|
|
|
tn.start_soon(
|
2021-08-27 18:53:30 +00:00
|
|
|
process_trades_and_update_ui,
|
|
|
|
trades_stream,
|
2022-08-06 00:39:00 +00:00
|
|
|
mode,
|
2023-04-08 23:22:53 +00:00
|
|
|
client,
|
2021-08-27 18:53:30 +00:00
|
|
|
)
|
2022-08-06 00:39:00 +00:00
|
|
|
|
2021-08-27 18:53:30 +00:00
|
|
|
yield mode
|
2021-08-28 18:18:37 +00:00
|
|
|
|
|
|
|
|
2021-08-27 18:53:30 +00:00
|
|
|
async def process_trades_and_update_ui(
|
|
|
|
|
|
|
|
trades_stream: tractor.MsgStream,
|
2022-08-06 00:39:00 +00:00
|
|
|
mode: OrderMode,
|
2023-04-08 23:22:53 +00:00
|
|
|
client: OrderClient,
|
2021-08-27 18:53:30 +00:00
|
|
|
|
|
|
|
) -> None:
|
|
|
|
|
|
|
|
# this is where we receive **back** messages
|
|
|
|
# about executions **from** the EMS actor
|
|
|
|
async for msg in trades_stream:
|
2022-08-06 00:39:00 +00:00
|
|
|
await process_trade_msg(
|
|
|
|
mode,
|
2023-04-08 23:22:53 +00:00
|
|
|
client,
|
2022-08-06 00:39:00 +00:00
|
|
|
msg,
|
|
|
|
)
|
2021-08-27 18:53:30 +00:00
|
|
|
|
2022-08-05 18:51:15 +00:00
|
|
|
|
2022-08-06 00:39:00 +00:00
|
|
|
async def process_trade_msg(
|
|
|
|
mode: OrderMode,
|
2023-04-08 23:22:53 +00:00
|
|
|
client: OrderClient,
|
2022-08-06 00:39:00 +00:00
|
|
|
msg: dict,
|
2021-08-27 18:53:30 +00:00
|
|
|
|
2023-04-17 21:28:43 +00:00
|
|
|
# emit linux DE notification?
|
|
|
|
# XXX: currently my experience with `dunst` is that this
|
|
|
|
# is horrible slow and clunky and invasive and noisy so i'm
|
|
|
|
# disabling it for now until we find a better UX solution..
|
|
|
|
do_notify: bool = False,
|
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
) -> tuple[Dialog, Status]:
|
2021-08-27 18:53:30 +00:00
|
|
|
|
2022-08-06 00:39:00 +00:00
|
|
|
fmsg = pformat(msg)
|
2022-08-11 18:20:23 +00:00
|
|
|
log.debug(f'Received order msg:\n{fmsg}')
|
2022-08-06 00:39:00 +00:00
|
|
|
name = msg['name']
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
|
2022-08-06 00:39:00 +00:00
|
|
|
if name in (
|
|
|
|
'position',
|
|
|
|
):
|
2023-05-24 19:42:14 +00:00
|
|
|
sym: MktPair = mode.chart.linked.mkt
|
2022-08-06 00:39:00 +00:00
|
|
|
pp_msg_symbol = msg['symbol'].lower()
|
2023-04-05 15:58:52 +00:00
|
|
|
fqme = sym.fqme
|
2023-03-15 00:17:19 +00:00
|
|
|
broker = sym.broker
|
2022-08-06 00:39:00 +00:00
|
|
|
if (
|
2023-04-05 15:58:52 +00:00
|
|
|
pp_msg_symbol == fqme
|
|
|
|
or pp_msg_symbol == fqme.removesuffix(f'.{broker}')
|
2021-08-27 18:53:30 +00:00
|
|
|
):
|
2023-04-05 15:58:52 +00:00
|
|
|
log.info(
|
|
|
|
f'Loading position for `{fqme}`:\n'
|
|
|
|
f'{fmsg}'
|
|
|
|
)
|
2022-08-06 00:39:00 +00:00
|
|
|
tracker = mode.trackers[msg['account']]
|
|
|
|
tracker.live_pp.update_from_msg(msg)
|
2023-04-18 23:12:14 +00:00
|
|
|
tracker.update_from_pp(
|
|
|
|
set_as_startup=True,
|
|
|
|
)
|
|
|
|
# status/pane UI
|
2022-08-06 00:39:00 +00:00
|
|
|
mode.pane.update_status_ui(tracker)
|
|
|
|
|
|
|
|
if tracker.live_pp.size:
|
|
|
|
# display pnl
|
|
|
|
mode.pane.display_pnl(tracker)
|
|
|
|
|
|
|
|
# short circuit to next msg to avoid
|
|
|
|
# unnecessary msg content lookups
|
|
|
|
return
|
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
msg = Status(**msg)
|
|
|
|
resp = msg.resp
|
|
|
|
oid = msg.oid
|
|
|
|
dialog: Dialog = mode.dialogs.get(oid)
|
2022-08-06 00:39:00 +00:00
|
|
|
|
2022-11-25 21:41:26 +00:00
|
|
|
if dialog:
|
2023-05-22 16:13:00 +00:00
|
|
|
fqme = dialog.symbol
|
2022-11-24 20:04:16 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
match msg:
|
2022-10-27 18:44:59 +00:00
|
|
|
case Status(
|
|
|
|
resp='dark_open' | 'open',
|
|
|
|
) if msg.req['action'] != 'cancel':
|
2021-08-27 18:53:30 +00:00
|
|
|
|
2022-10-03 17:41:40 +00:00
|
|
|
order = Order(**msg.req)
|
|
|
|
|
2022-10-27 18:44:59 +00:00
|
|
|
if (
|
|
|
|
dialog is not None
|
|
|
|
and order.action != 'cancel'
|
|
|
|
):
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
# show line label once order is live
|
2022-10-03 17:41:40 +00:00
|
|
|
mode.on_submit(oid, order=order)
|
2022-07-10 19:44:52 +00:00
|
|
|
|
2022-10-27 18:44:59 +00:00
|
|
|
elif order.action != 'cancel':
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
log.warning(
|
|
|
|
f'received msg for untracked dialog:\n{fmsg}'
|
|
|
|
)
|
|
|
|
assert msg.resp in ('open', 'dark_open'), f'Unknown msg: {msg}'
|
2021-08-27 18:53:30 +00:00
|
|
|
|
2023-05-24 19:42:14 +00:00
|
|
|
sym: MktPair = mode.chart.linked.mkt
|
2023-05-22 16:13:00 +00:00
|
|
|
fqme = sym.fqme
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
if (
|
2023-05-22 16:13:00 +00:00
|
|
|
((order.symbol + f'.{msg.src}') == fqme)
|
2021-08-27 18:53:30 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
# a existing dark order for the same symbol
|
|
|
|
or (
|
2023-05-22 16:13:00 +00:00
|
|
|
order.symbol == fqme
|
2022-08-14 20:42:29 +00:00
|
|
|
and (
|
|
|
|
msg.src in ('dark', 'paperboi')
|
2023-05-22 16:13:00 +00:00
|
|
|
or (msg.src in fqme)
|
2022-08-14 20:42:29 +00:00
|
|
|
|
|
|
|
)
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
)
|
|
|
|
):
|
2022-08-18 20:04:44 +00:00
|
|
|
msg.req = order
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
dialog = mode.load_unknown_dialog_from_msg(msg)
|
|
|
|
mode.on_submit(oid)
|
|
|
|
|
|
|
|
case Status(resp='error'):
|
|
|
|
# delete level line from view
|
|
|
|
mode.on_cancel(oid)
|
|
|
|
broker_msg = msg.brokerd_msg
|
|
|
|
log.error(
|
|
|
|
f'Order {oid}->{resp} with:\n{pformat(broker_msg)}'
|
|
|
|
)
|
2021-08-27 18:53:30 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
case Status(resp='canceled'):
|
|
|
|
# delete level line from view
|
|
|
|
mode.on_cancel(oid)
|
2022-10-28 19:37:24 +00:00
|
|
|
action = msg.req["action"]
|
|
|
|
log.cancel(f'Canceled {action}:{oid}')
|
2021-08-27 18:53:30 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
case Status(
|
|
|
|
resp='triggered',
|
2022-10-28 19:10:48 +00:00
|
|
|
# req=Order(exec_mode='dark') # TODO: msgspec
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
req={'exec_mode': 'dark'},
|
|
|
|
):
|
2022-08-11 18:20:23 +00:00
|
|
|
# TODO: UX for a "pending" clear/live order
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
log.info(f'Dark order triggered for {fmsg}')
|
2021-08-27 18:53:30 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
case Status(
|
|
|
|
resp='triggered',
|
|
|
|
# req=Order(exec_mode='live', action='alert') as req, # TODO
|
|
|
|
req={'exec_mode': 'live', 'action': 'alert'} as req,
|
|
|
|
):
|
|
|
|
# should only be one "fill" for an alert
|
|
|
|
# add a triangle and remove the level line
|
2022-08-11 18:20:23 +00:00
|
|
|
req = Order(**req)
|
2022-12-09 19:17:36 +00:00
|
|
|
tm = time.time()
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
mode.on_fill(
|
|
|
|
oid,
|
|
|
|
price=req.price,
|
2022-12-09 19:17:36 +00:00
|
|
|
time_s=tm,
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
)
|
|
|
|
mode.lines.remove_line(uuid=oid)
|
2022-08-11 18:20:23 +00:00
|
|
|
msg.req = req
|
2023-04-17 21:28:43 +00:00
|
|
|
if do_notify:
|
|
|
|
await notify_from_ems_status_msg(msg)
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
|
|
|
|
# response to completed 'dialog' for order request
|
|
|
|
case Status(
|
|
|
|
resp='closed',
|
|
|
|
# req=Order() as req, # TODO
|
|
|
|
req=req,
|
|
|
|
):
|
|
|
|
msg.req = Order(**req)
|
2023-04-17 21:28:43 +00:00
|
|
|
if do_notify:
|
|
|
|
await notify_from_ems_status_msg(msg)
|
2022-08-06 00:39:00 +00:00
|
|
|
mode.lines.remove_line(uuid=oid)
|
2021-08-27 18:53:30 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
# each clearing tick is responded individually
|
|
|
|
case Status(resp='fill'):
|
2022-08-11 18:20:23 +00:00
|
|
|
|
|
|
|
# handle out-of-piker fills reporting?
|
2023-06-20 18:40:57 +00:00
|
|
|
order: Order | None
|
|
|
|
if not (order := client._sent_orders.get(oid)):
|
|
|
|
|
|
|
|
# set it from last known request msg
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
log.warning(f'order {oid} is unknown')
|
2022-10-06 12:38:19 +00:00
|
|
|
order = msg.req
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
|
2023-06-20 18:40:57 +00:00
|
|
|
# XXX TODO: have seen order be a dict here!?
|
|
|
|
# that should never happen tho?
|
|
|
|
action: str = order.action
|
|
|
|
details: dict = msg.brokerd_msg
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
|
2023-06-17 20:50:56 +00:00
|
|
|
# TODO: state tracking:
|
|
|
|
# - put the actual exchange timestamp?
|
|
|
|
# - some kinda progress system?
|
2022-12-09 19:17:36 +00:00
|
|
|
|
2022-11-24 20:04:16 +00:00
|
|
|
# NOTE: currently the ``kraken`` openOrders sub
|
|
|
|
# doesn't deliver their engine timestamp as part of
|
|
|
|
# it's schema, so this value is **not** from them
|
|
|
|
# (see our backend code). We should probably either
|
|
|
|
# include all provider-engine timestamps in the
|
|
|
|
# summary 'closed' status msg and/or figure out
|
|
|
|
# a way to indicate what is a `brokerd` stamp versus
|
|
|
|
# a true backend one? This will require finagling
|
|
|
|
# with how each backend tracks/summarizes time
|
|
|
|
# stamps for the downstream API.
|
2022-12-09 19:17:36 +00:00
|
|
|
tm = details['broker_time']
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
mode.on_fill(
|
|
|
|
oid,
|
|
|
|
price=details['price'],
|
2022-12-09 19:17:36 +00:00
|
|
|
time_s=tm,
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
pointing='up' if action == 'buy' else 'down',
|
|
|
|
)
|
2021-08-27 18:53:30 +00:00
|
|
|
|
2022-10-06 12:38:19 +00:00
|
|
|
# TODO: append these fill events to the position's clear
|
|
|
|
# table?
|
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
# tracker = mode.trackers[msg['account']]
|
|
|
|
# tracker.live_pp.fills.append(msg)
|
2021-08-27 18:53:30 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
# record message to dialog tracking
|
|
|
|
if dialog:
|
|
|
|
dialog.msgs[oid] = msg
|
2021-07-22 15:39:47 +00:00
|
|
|
|
Add full EMS order-dialog (re-)load support!
This includes darks, lives and alerts with all connecting clients
being broadcast all existing order-flow dialog states. Obviously
for now darks and alerts only live as long as the `emsd` actor lifetime
(though we will store these in local state eventually) and "live" orders
have lifetimes managed by their respective backend broker.
The details of this change-set is extensive, so here we go..
Messaging schema:
- change the messaging `Status` status-key set to:
`resp: Literal['pending', 'open', 'dark_open', 'triggered',
'closed', 'fill', 'canceled', 'error']`
which better reflects the semantics of order lifetimes and was
partially inspired by the status keys `kraken` provides for their
order-entry API. The prior key set was based on `ib`'s horrible
semantics which sound like they're right out of the 80s..
Also, we reflect this same set in the `BrokerdStatus` msg and likely
we'll just get rid of the separate brokerd-dialog side type
eventually.
- use `Literal` type annots for statuses where applicable and as they
are supported by `msgspec`.
- add additional optional `Status` fields:
-`req: Order` to allow each status msg to optionally ref its
commanding order-request msg allowing at least a request-response
style implicit tracing in all response msgs.
-`src: str` tag string to show the source of the msg.
-`reqid: str | int` such that the ems can relay the `brokerd`
request id both to the client side and have one spot to look
up prior status msgs and
- draft a (unused/commented) `Dialog` type which can be eventually used
at all EMS endpoints to track msg-flow states
EMS engine adjustments/rework:
- use the new status key set throughout and expect `BrokerdStatus` msgs
to use the same new schema as `Status`.
- add a `_DarkBook._active: dict[str, Status]` table which is now used for
all per-leg-dialog associations and order flow state tracking
allowing for the both the brokerd-relay and client-request handler loops
to read/write the same msg-table and provides for delivering
the overall EMS-active-orders state to newly/re-connecting clients
with minimal processing; this table replaces what the `._ems_entries`
table from prior.
- add `Router.client_broadcast()` to send a msg to all currently
connected peers.
- a variety of msg handler block logic tweaks including more `case:`
blocks to be both flatter and improve explicitness:
- for the relay loop move all `Status` msg update and sending to
within each block instead of a fallthrough case plus hard-to-follow
state logic.
- add a specific case for unhandled backend status keys and just log
them.
- pop alerts from `._active` immediately once triggered.
- where possible mutate status msgs fields over instantiating new
ones.
- insert and expect `Order` instances in the dark clearing loop and
adjust `case:` blocks accordingly.
- tag `dark_open` and `triggered` statuses as sourced from the ems.
- drop all the `ChainMap` stuff for now; we're going to make our own
`Dialog` type for this purpose..
Order mode rework:
- always parse the `Status` msg and use match syntax cases with object
patterns, hackily assign the `.req` in many blocks to work around not
yet having proper on-the-wire decoding yet.
- make `.load_unknown_dialog_from_msg()` expect a `Status` with boxed
`.req: Order` as input.
- change `OrderDialog` -> `Dialog` in prep for a general purpose type
of the same name.
`ib` backend order loading support:
- do "closed" status detection inside the msg-relay loop instead
of expecting the ems to do this..
- add an attempt to cancel inactive orders by scheduling cancel
submissions continually (no idea if this works).
- add a status map to go from the 80s keys to our new set.
- deliver `Status` msgs with an embedded `Order` for existing live order
loading and make sure to try an get the source exchange info (instead
of SMART).
Paper engine ported to match:
- use new status keys in `BrokerdStatus` msgs
- use `match:` syntax in request handler loop
2022-08-10 04:16:08 +00:00
|
|
|
return dialog, msg
|