feat(cron): make the media-send timeout configurable via HERMES_CRON_MEDIA_SEND_TIMEOUT - #87967
Closed
AiwendilInTheWoods wants to merge 1 commit into
Closed
Conversation
The media delivery path used a hardcoded future.result(timeout=30). Large attachments legitimately exceed it with no way to raise the limit. Read HERMES_CRON_MEDIA_SEND_TIMEOUT, matching the existing HERMES_CRON_SCRIPT_TIMEOUT / HERMES_CRON_TIMEOUT / HERMES_CRON_SESSION_DB_TIMEOUT convention in the same module.
alt-glitch
added
type/feature
teknium1
added a commit
that referenced
this pull request
Aug 18, 2026
Follow-up on the salvaged commits from PRs #87965 and #87967 (@AiwendilInTheWoods): - Promote the media-send timeout to the standard resolution pattern: HERMES_CRON_MEDIA_SEND_TIMEOUT env var, then cron.media_send_timeout_seconds in config.yaml, then 300s default (mirrors script_timeout_seconds; .env stays secrets-only). - Register the config key in DEFAULT_CONFIG and document both surfaces (environment-variables reference + cron user guide). - Fold the empty-str() exception fallback into the error string recorded in delivery_errors (post-#88631 the reason reaches the run status, not just the log line). - Tests: timeout resolution precedence + TimeoutError reason fallback.
Contributor
|
Merged via PR #88787 (merge commit bc76f62) — your commit landed with authorship preserved, together with your #87965 fix. On top of it we promoted the raw env-var read to the standard resolution pattern ( |
lisajlau
pushed a commit
to lisajlau/hermes-agent
that referenced
this pull request
Aug 20, 2026
Follow-up on the salvaged commits from PRs NousResearch#87965 and NousResearch#87967 (@AiwendilInTheWoods): - Promote the media-send timeout to the standard resolution pattern: HERMES_CRON_MEDIA_SEND_TIMEOUT env var, then cron.media_send_timeout_seconds in config.yaml, then 300s default (mirrors script_timeout_seconds; .env stays secrets-only). - Register the config key in DEFAULT_CONFIG and document both surfaces (environment-variables reference + cron user guide). - Fold the empty-str() exception fallback into the error string recorded in delivery_errors (post-NousResearch#88631 the reason reaches the run status, not just the log line). - Tests: timeout resolution precedence + TimeoutError reason fallback.
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
3 participants
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.
Problem
cron/scheduler.pybounds media delivery with a hardcodedfuture.result(timeout=30). Any job producing a large attachment — long TTS audio, a concatenated recording, a sizeable export — fails once the upload exceeds 30 seconds, and there is no way to raise the limit short of patching the file.Observed in production: a ~7.4 MB MP3 was generated correctly and then failed to deliver, while 3.0–3.3 MB files on the same path had always succeeded. Nothing was wrong with the file, the credentials, or the transport — the upload simply took longer than 30 s.
Why an environment variable, and why this name
The same module already reads three sibling timeouts from the environment:
HERMES_CRON_SCRIPT_TIMEOUTHERMES_CRON_TIMEOUTHERMES_CRON_SESSION_DB_TIMEOUTMedia send is the odd one out. This follows the established convention rather than introducing a new mechanism, and
osis already imported.Default
Raised from 30 s to 300 s. Set
HERMES_CRON_MEDIA_SEND_TIMEOUT=30to restore the previous behaviour exactly.Docs
The three sibling
HERMES_CRON_*variables are not currently documented inwebsite/docs/user-guide/configuration.mdorcli-config.yaml.example, so this PR matches that convention rather than expanding scope. Happy to add documentation for all four in this PR if you'd prefer.Related
failed to send media <path>:with no reason at all, becausestr(TimeoutError())is empty. The two PRs touch nearby lines in the same file and are independent; whichever lands second is a trivial rebase.plugins/platforms/telegram/adapter.py). This is the separatecron/scheduler.pydelivery path and does not overlap them.