Skip to content

fix: normalize timeframe case for alert poll interval - #293

Merged
brokermr810 merged 1 commit into
OpenByteInc:mainfrom
Bortlesboat:fix/alert-poll-timeframe-case
Oct 18, 2026
Merged

brokermr810 merged 1 commit into
OpenByteInc:mainfrom
Bortlesboat:fix/alert-poll-timeframe-case

Conversation

@Bortlesboat

Copy link
Copy Markdown
Contributor

Summary

_poll_seconds in the indicator signal alert service only had uppercase keys (1H, 4H, 1D, 1W), but timeframes are stored as entered and the create path defaults to "1h". So 1h, 4h, 1d and 1w alerts all fell through to the 120s default, and 3m (added in #87) had no entry at all.

Related issue

  • None

Changes

  • Normalize the timeframe with the existing normalize_frequency() and use lowercase keys to match.
  • Add a 3m interval of 25s, between the 1m and 5m values.
  • Add a parametrized regression test covering both cases.

Test plan

  • Tested locally with docker compose up -d --build
  • Backend logs show no errors
  • Relevant pytest tests pass

python -m pytest tests/test_indicator_signal_alerts.py -q passes (28 tests). Without the fix, the new test fails for 3m, 4h, 1d and 1w.

@brokermr810
brokermr810 merged commit aa5f491 into OpenByteInc:main Oct 18, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants