Skip to content

Bound lyric harmonization timestamps and window count to prevent browser hangs (#28) - #31

Merged
cchacs merged 1 commit into
mainfrom
pullfrog/28-bound-lyric-harmonization
Oct 11, 2026
Merged

cchacs merged 1 commit into
mainfrom
pullfrog/28-bound-lyric-harmonization

Conversation

@pullfrog

@pullfrog pullfrog Bot commented Oct 11, 2026

Copy link
Copy Markdown
Contributor

Fixes #28.

_harmonizeMelody filtered each token's start/duration for finiteness, then summed them (t.start + t.duration) to pick the last window. Two finite values can sum to Infinity — the issue's repro {start: 1e308, duration: 1e308, midi: 60} — turning windowCount = Math.ceil(Infinity / windowSeconds) into an infinite main-thread loop. Large finite timestamps were equally unhappy: a 1e10s span means ~5 billion synchronous window iterations.

Changes:

  • _harmonizeMelody now validates the summed endpoint for finiteness and against a supported song horizon (MAX_HARMONIZED_MELODY_SECONDS = 900.0, sharing routes.py's 15-minute MAX_AUDIO_DURATION_SECONDS bound; unlike the audio path's truncation, an out-of-horizon melody is rejected outright) and returns no chords, which the caller turns into the existing graceful null — the same result a rest-only or lyrics-only track already produces.
  • The window count is hard-capped (MAX_HARMONY_WINDOWS = 3000) independently of timestamps, so the loop can never iterate an impractical number of times even if the horizon or minimum windowSeconds ever change.
  • Regression tests cover the overflow repro (with a real token alongside it, so the null can't be waved off as an empty window grid), a very large finite span past the horizon, and an in-horizon boundary (>=890s melody still harmonizes).
  • Docs/version: README generateAccompanimentFromLyrics null conditions, CHANGELOG Fixed entry, plugin.json 0.6.1 → 0.6.2, CLAUDE.md prose + test count.

Verified: JS suite 110/110 pass (was 107), Python 20/20 pass, node --check clean. Reintroducing the old reduce-based endpoint hangs the new overflow test (killed by a 12s external timeout), confirming the regression coverage pins the fix.

Pullfrog  | View workflow run | via Pullfrog | Using big-pickle (free) | 𝕏

_harmonizeMelody computed its window count from a raw sum of token start + duration, which a valid-numeric token like {start: 1e308, duration: 1e308} can overflow to Infinity (infinite main-thread loop) and which even at large finite spans means iterating one window per slice of the whole melody. Validate the summed endpoint for finiteness and against the 15-minute song horizon (sharing routes.py's MAX_AUDIO_DURATION_SECONDS), cap the window loop regardless of timestamps, and return the existing graceful null for out-of-bound melodies. Adds regression tests for overflow, very large finite timestamps, and an in-horizon boundary.
@kilo-code-bot

kilo-code-bot Bot commented Oct 11, 2026 •

Copy link
Copy Markdown

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (6 files)
  • chordr/screen.js - _harmonizeMelody endpoint validation + window cap; verified against routes.py MAX_AUDIO_DURATION_SECONDS (900.0) and test expectations
  • tests/generate_accompaniment_from_lyrics.test.js - 3 regression tests; verified t=[0,888] math for the in-horizon case
  • CHANGELOG.md - Fixed entry consistent with code
  • README.md - null-condition docs match implementation
  • CLAUDE.md - 0.6.2 / 110 pass prose matches plugin.json and tests
  • chordr/plugin.json - version bump 0.6.1 → 0.6.2

Reviewed by free · Input: 357.8K · Output: 26.9K · Cached: 223.7K

@cchacs
cchacs merged commit ea49dc1 into main Oct 11, 2026
5 checks passed
@cchacs
cchacs deleted the pullfrog/28-bound-lyric-harmonization branch October 11, 2026 03:29
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.

Bound lyric harmonization timestamps and window count to prevent browser hangs

1 participant