HKUDS/Vibe-Trading · error · ValueError

interval is too large; expected at most 15 digits of…

Error message

interval is too large; expected at most 15 digits of milliseconds

What it means

When a schedule matches the pure-digit interval form (milliseconds), it is capped at 15 digits (~31,000 years). Longer digit strings would overflow practical timing arithmetic and int conversion of huge strings, so they are rejected rather than silently accepted.

Solutions

1. Cap intervals to at most 15 digits of milliseconds; for anything longer just use cron or a very large but sane value.
2. Verify the unit is milliseconds: 3600000 = 1 hour.
3. If you meant a daily/weekly schedule, prefer a cron string over a giant interval.

Example fix

# before
validate_schedule('3600000000000000000')  # ns, not ms
# after
validate_schedule('3600000')  # 1 hour in ms

if schedule.strip().isdigit() and len(schedule.strip()) > 15:
    raise ValueError('interval too large; use a cron schedule instead')
validate_schedule(schedule)

When it happens

Trigger: validate_schedule('9999999999999999') (16 digits), a schedule built by multiplying milliseconds by an inflated factor, or a copy-pasted nanosecond value (18-19 digits).

Common situations: Unit confusion: passing nanoseconds or microseconds where milliseconds are expected; computing intervals from misparsed large numbers (e.g. ms*days*1000 applied twice).

Related errors

• cron field is out of range; expected
• cron field is not valid; each field must be *, */n, or a…
• cron field is out of range; expected
• cron range is reversed; expected low-high
• schedule must be a non-empty string

AI-assisted analysis of HKUDS/Vibe-Trading@80ffdda44c (2026-08-28). Data as JSON: /api/errors/6199670361fcd8b6. Report an issue: GitHub.

Appendix: source

Thrown at agent/src/scheduled_research/models.py:132

def validate_schedule(schedule: str) -> None:
    """Raise ``ValueError`` when *schedule* is malformed.

    Args:
        schedule: Either a positive integer string (interval-ms) or a
            simplified 5-field cron expression.

    Raises:
        ValueError: When the schedule does not match either accepted form.
    """
    if not schedule or not isinstance(schedule, str):
        raise ValueError("schedule must be a non-empty string")

    if _INTERVAL_MS_RE.fullmatch(schedule.strip()):
        # 15 digits ≈ 31,000 years in milliseconds — anything longer is not a
        # usable interval and would only feed int() conversion of huge strings.
        if len(schedule.strip()) > 15:
            raise ValueError("interval is too large; expected at most 15 digits of milliseconds")
        return  # valid interval

    parts = schedule.strip().split()
    if len(parts) != _CRON_PARTS:
        raise ValueError(f"schedule must be a positive integer (ms) or a 5-field cron string; got: {schedule!r}")
    for part, (low, high) in zip(parts, CRON_BOUNDS):
        _validate_cron_field(part, low, high)


def validate_timezone_shape(tz: Optional[str]) -> None:
    """Raise ``ValueError`` when *tz* is not ``None`` or a non-empty string.

    This is the persistence-level check: it deliberately does NOT resolve the
    key, because resolvability depends on the host's timezone database. A
    store written where a key resolved must keep loading and persisting on a
    host where it does not; the executor surfaces the unresolvable key as a
    per-job schedule failure instead.
    """

View on GitHub (pinned to 80ffdda44c)