Executor pattern, RobinhoodClient, deferred task scheduler

[IamJasonBian]

Summary

• Split SafeCashBot into RobinhoodClient (thin broker wrapper) and Executor (execution quality layer)
• Add Brokerage ABC (utils/brokerage.py) for dependency inversion — Executor depends on the interface, not the concrete client
• Add TradeTask / ScheduledTask / DeferredTask (trade_task.py) using Command + Strategy patterns
• PDT-blocked orders are deferred to next trading day via in-memory _deferred_queue, drained at top of each engine cycle
• Fix cancel_order_by_id → cancel_order across main.py and all tests
• Align lot_size and strategy pricing defaults so tests match live config

Test plan

• pytest tests/ — all 166 tests pass
• Engine dry-run completes without attribute errors

[IamJasonBian]

Code Review — PR #53

Overall: Well-structured refactor splitting SafeCashBot into RobinhoodClient (thin broker wrapper) and Executor (execution quality layer). The Brokerage ABC for dependency inversion is a clean architectural improvement that will make testing and future broker integrations much easier.

Issues

1. Hardcoded account number — RobinhoodClient.EXPECTED_ACCOUNT = "490706777" is a class constant. This should be an env var or config value, not committed to source. Even as a safety check, hardcoding an account number in a public repo is a security concern.

2. Singleton RobinhoodClient complicates testing — create() returns a cached singleton and calls sys.exit(1) on missing env vars. Tests will need to call reset() between runs and mock env vars carefully. Consider making create() accept optional overrides or having a create_for_test() factory.

3. PDT retry in place_limit_buy bypasses the Executor — The client has its own PDT retry logic (cancel existing buy, resubmit) baked into place_limit_buy. But the Executor also owns PDT gating. This creates two competing PDT handling paths. The client should be a thin passthrough — move retry logic to the Executor.

4. _next_trading_day doesn't handle market holidays — Only skips weekends. An order deferred on Friday before a Monday holiday would attempt execution on that holiday. Consider using a holiday calendar or at minimum documenting the limitation.

5. 774-line robinhood_client.py — This is a large file for a "thin wrapper." Methods like get_portfolio_history, get_recent_orders, get_recent_option_orders, and order validation logic may belong in separate modules or mixins to keep the client focused on order placement and account state.

6. cancel_order_by_id → cancel_order rename — Good cleanup, but verify no other callers exist outside this PR (scripts, notebooks, etc.) that still reference the old name.

Strengths

• Brokerage ABC is minimal and well-defined (8 abstract methods)
• TradeTask hierarchy (ScheduledTask, DeferredTask) with Strategy pattern for should_execute() is clean
• Deferred queue draining at cycle start is the right approach
• Test updates are thorough — renaming load_broker_sell_orders → load_broker_orders and fixing created_at type assertions

---

Generated by Claude Code

[IamJasonBian]

Follow-up Review — PR #53

A few additional items not covered in the initial review:

1. drain_deferred() is never called — Executor.drain_deferred() is documented to run "at the top of each engine cycle," but there is no call site in main.py. Deferred orders will accumulate and never be retried.

2. self.executor can remain None — In main.py, self.executor = None is set initially, then only assigned inside a try block. If initialization fails, any subsequent self.executor.submit(...) call raises AttributeError. Add a None guard or fail fast.

3. validate_buy_order bypasses the Brokerage ABC — Called directly on self.trading_bot (the concrete RobinhoodClient), but validate_buy_order is not declared as an abstract method on Brokerage. This partially defeats the dependency inversion the PR introduces.

4. PDT check duplicated in _handle_order_replacement — main.py has an inline PDT status check via self.trading_bot.get_pdt_status(), separate from the PDTGate inside the Executor. Combined with the retry logic in place_limit_buy, this creates three competing PDT handling paths.

5. ScheduledTask is unused — Defined and imported but never instantiated. If this is forward scaffolding, consider deferring it to a later PR to keep the diff focused.

---

Generated by Claude Code

[IamJasonBian]

Stale PR notice — This PR has been open for 15 days with no new commits since Mar 27. Two code reviews have been posted with actionable items (e.g., drain_deferred() never called, hardcoded account number, competing PDT paths). Please address the review feedback or close if superseded.

---

Generated by Claude Code

[IamJasonBian]

Stale — 4 weeks, no activity since Mar 27. Two prior reviews identified actionable bugs: drain_deferred() is never called (deferred orders silently accumulate), hardcoded account number 490706777 in a public repo, and three competing PDT handling paths. With PR #55 now adding IBKR broker support separately, the broker abstraction story is diverging. Recommend addressing the review feedback or closing if the Executor design has evolved.

---

Generated by Claude Code

[IamJasonBian]

Code Deletion Opportunities — PR #53

Focused follow-up on redundant code within robinhood_client.py and the task abstraction.

1. Extract duplicated order-parsing logic (~50 lines → ~20)

get_open_orders() and get_recent_orders() both contain identical blocks for:

• Symbol resolution from instrument_id (7 lines, duplicated)
• Order-type classification (trigger == 'stop' and order_type == 'limit' → 'Stop Limit', etc.) (8 lines, duplicated)
• Timestamp formatting (5 lines, duplicated)

Extract a _resolve_symbol(order) helper and a _classify_order_type(order) helper. Saves ~30 lines and ensures both methods stay consistent.

2. Move analytics out of the broker client (~130 lines deletable)

_recommend_option_action() (60 lines) and _calculate_expected_pnl() (15 lines) are analytical methods that don't touch robin_stocks at all. They compute option strategies and P&L scenarios — this is domain logic, not brokerage plumbing. Same for the analytics section inside get_option_positions() that calls them.

Move these to a dedicated options_analytics.py or inline them only where consumed. The broker client's job is to fetch positions, not make trading recommendations. This brings robinhood_client.py closer to the "thin wrapper" the PR description claims.

3. ScheduledTask always uses date.today() — abstraction adds no value

Every call site in main.py does:

task = ScheduledTask(symbol=..., ..., execute_date=date.today())
result = self.executor.submit(task)

Since should_execute() always returns True when execute_date == today, the ScheduledTask wrapper is pure ceremony. The Executor.submit() method could accept the trade params directly (or a simpler TradeTask dataclass without the scheduling logic). DeferredTask is the only subclass that actually uses the date check.

Consider deleting ScheduledTask, having Executor.submit() accept kwargs or a plain TradeTask dataclass, and keeping DeferredTask for the deferred queue. Removes ~15 lines of class definition plus simplifies every call site.

4. get_recent_option_orders() strips leg data

The method builds a flat dict per option order but drops the legs array, which is needed by PR #45's PDT gate for same-day fill detection. If these PRs are meant to work together, the legs data needs to be preserved here, or the PDT gate needs a separate fetch — which creates another redundant API call.

Net reduction potential: ~130 lines of analytics + ~30 lines of parsing duplication + ~15 lines of ScheduledTask

---

Generated by Claude Code

[IamJasonBian]

Stale — large refactor that overlaps with PR #32.

This PR introduces the Brokerage ABC, Executor, and TradeTask/DeferredTask patterns, which is a cleaner architecture than PR #32's ExecutionManager. However, both PRs are stale and likely have significant merge conflicts with main.

Cross-PR overlap:

• PR #32 adds execution/execution_manager.py, price_discovery.py, fill_monitor.py, slippage_controller.py
• This PR adds utils/brokerage.py (ABC), restructures RobinhoodClient out of SafeCashBot, and adds trade_task.py
• Both touch main.py extensively. Merging both is not viable without major reconciliation.

Recommendation: Decide which execution architecture to keep. If the Brokerage ABC / Executor pattern here is the winner, close PR #32 and rebase this. If pieces of #32's price discovery or slippage control are wanted, port them into this PR's architecture.

Code note on TradeTask / DeferredTask: The in-memory _deferred_queue will lose deferred orders on process restart. If the engine runs on Render (PR #52), crashes or deploys will silently drop queued orders. Consider persisting the queue to the state log or at least logging a warning on startup if the queue was non-empty.

---

Generated by Claude Code