fix: decouple warmup_minutes from HLCV cache hash for better reuse#562
Closed
fix: decouple warmup_minutes from HLCV cache hash for better reuse#562
Conversation
Wire Hyperliquid builder codes through CCXT's built-in infrastructure. Overrides CCXT's default builder address with Passivbot's own in broker_codes.hjson (ref, builder address, fee rate, fee int). On by default: CCXT auto-attaches builder info to orders when approved. Adds a periodic nag banner (every 30 min) encouraging users to approve the builder fee via their main wallet, modeled on Binance's print_new_user_suggestion pattern. Bot continues working without approval - users are never blocked. Default fee: 2 bps (0.02%), configurable via broker_codes.hjson. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Update builder code implementation to the full three-path design: Path A (already approved): Modest thank-you at startup, builder codes active on all orders. Path B (not approved + main wallet): Auto-approve via API, print notice banner explaining what happened, then thank-you. Path C (not approved + agent wallet): Force-enable builder codes so the first order fails with approval error. Catch the error, show nag banner with approval instructions, temporarily disable. Re-enable every ~30 min to re-nag or detect external approval. "Free version with ads" pattern. Also: suppress CCXT's default auto-approval (we handle it ourselves), add real builder address 0x5e20A6D7e11366390Fde63EA3d0A026903359a74, rewrite plan doc to reflect all three paths and early-warning strategy. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adopt improvements from Codex's branch comparison: - Add CHANGELOG.md entry for builder codes - Add docs/hyperliquid_guide.md builder codes section - Add builder_fee toggle in broker_codes.hjson - Add robust _is_positive_fee_value() and _extract_max_builder_fee() - Add input validation with fallback for fee_int - Add class constants for timing intervals - Add status check caching to prevent endpoint hammering - Add 13 unit tests covering static methods, config, async paths Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Initialize all builder state (_builder_initialized, _builder_pending_approval, _builder_disabled_ts) in __init__ instead of hasattr/getattr fallbacks - _has_builder_config() now respects builder_fee toggle, so _init_builder_codes skips entirely when disabled - _maybe_reenable_builder_codes() uses BUILDER_NAG_INTERVAL_MS class constant instead of hardcoded value - Support both camelCase (feeRate, feeInt, builderFee) and snake_case (fee_rate, fee_int, builder_fee) key names in broker_codes.hjson - execute_order uses logging.error for the failure + logging.warning for the fallback action (proper severity levels) - Add builder codes comment to api-keys.json.example - Add 4 new tests: camelCase aliases, toggle in _has_builder_config, re-enable cycle (still not approved), re-enable cycle (now approved) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Incorporate improvements from feature/hl_builder_codes_codex_gpt5: - Add _normalize_builder_settings() to centralize key alias resolution and cache in _builder_settings (eliminates duplicate parsing) - Add _builder_thank_you_printed dedup flag (prevents repeated banners) - Add dedicated _print_builder_thank_you_banner and _print_builder_approved_notice_banner methods - Add cca None guards in _check_builder_fee_approved, _set_builder_approved, _init_builder_codes - Fix disable bug: ref is now applied even when builder_fee=false Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Standalone async script that lets agent-wallet users approve the builder fee from their main wallet without modifying api-keys.json. Referenced by the nag banner and docs/hyperliquid_guide.md. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Guard getpass with TTY check to prevent plaintext key echo - Zero main_key reference after use - Never log exception messages (use type name only) to avoid leaking key material - Use logging.error instead of logging.exception to suppress tracebacks Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Configs that differ only in trading parameters (EMA spans, warmup ratio) now share the same HLCV cache slot instead of triggering redundant re-downloads. The cache uses a ratchet-up strategy: warmup sufficiency is checked at load time via cache_meta.json, and the cache is overwritten only when a larger warmup is needed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Owner
Author
|
Superseded by #564, which contains only the targeted HLCV cache warmup reuse changes on top of current master. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cache_meta.jsontreated as warmup=0)Problem
When backtesting two configs that share identical
backtest.*,live.approved_coins, and exchange settings but differ inbot.long(e.g., different EMA spans), the HLCV data was re-downloaded from scratch. This happened becausewarmup_minutes—derived from the max EMA span—was included in the cache hash. Different EMA spans → different warmup → different hash → cache miss → full re-download.Example with two real configs:
entry_volatility_ema_span_hours=672→ warmup=36,288 min (25.2 days)entry_volatility_ema_span_hours=2490→ warmup=44,820 min (31.1 days)Solution
get_cache_hash()— removedwarmup_minutesfrom the hash. The key now depends only on data-defining parameters (coins, dates, exchange, coin age, gap tolerance, sources).load_coins_hlcvs_from_cache()— newwarmup_minutesparameter. Readscache_meta.jsonand checkscached_warmup >= needed_warmup. ReturnsNoneif insufficient.save_coins_hlcvs_to_cache()— newwarmup_minutesparameter. Writescache_meta.json. Removed the early-return guard so that re-fetches with larger warmup can overwrite the same cache slot.prepare_hlcvs_mss()— threadsbacktest_warmup_minutesthrough to both load and save.Ratchet behavior
Test plan
tests/test_cache_warmup_reuse.pycovering:cache_meta.json)cache_meta.jsonfallbackcache_meta.json(uncompressed + compressed)🤖 Generated with Claude Code