@trayai/helix-sdk 1.13.0 → 1.13.1

package/CHANGELOG.md

@@ -8,6 +8,14 @@ project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 The SDK and [`@trayai/helix-cli`](https://www.npmjs.com/package/@trayai/helix-cli) are
 released together and share a version — install matching versions.
 
+## 1.13.1
+
+### Changed
+
+- Documented the 15-minute handler time limit for scheduled functions and
+  `ctx.callFunctionAsync` targets (previously documented as 180 seconds), and that a failed
+  run is retried about a minute later rather than five.
+
 ## 1.9.0
 
 ### Added

package/README.md

@@ -256,10 +256,10 @@ Things to know:
 - Files and directories starting with `_` below `_scheduled/` are treated as helpers, not schedules — the only files that belong in the directory besides schedule definitions.
 - `getContext()` works inside schedule handlers; shared code can detect a scheduled run by checking for `ctx.trigger`.
 
-Limits — schedules run in the same deployed runtime as HTTP functions and share its execution limits:
+Limits — schedules run in the same deployed runtime as HTTP functions but get a longer time limit:
 
-- **Handler time limit: 180 seconds.** A run still going at the limit is killed and counts as failed. Work that can't reliably finish in time should be split across runs — persist progress (for example in `ctx.kv()`) and continue on the next fire.
-- **Delivery is at-least-once.** A failed run — a thrown error, a timed-out handler, or an infrastructure failure — is retried once roughly five minutes later, then dropped. Write handlers to be idempotent: a retry re-runs the whole handler with the same `ctx.trigger.scheduledAt`.
+- **Handler time limit: 15 minutes.** A run still going at the limit is killed and counts as failed. Work that can't reliably finish in time should be split across runs — persist progress (for example in `ctx.kv()`) and continue on the next fire.
+- **Delivery is at-least-once.** A failed run — a thrown error, a timed-out handler, or an infrastructure failure — is retried once, usually about a minute later, then dropped. Write handlers to be idempotent: a retry re-runs the whole handler with the same `ctx.trigger.scheduledAt`.
 - **Highest frequency is once per minute** — 5-field cron has minute granularity.
 - **Memory is managed by the platform** and is not configurable per function.
 - Fires are scheduled for the exact cron minute, but execution can start late under load or on a cold start — compare `ctx.trigger.scheduledAt` (intended) with `ctx.trigger.firedAt` (actual) when lateness matters.
@@ -297,6 +297,8 @@ Things to know:
 
 - **Fire-and-forget only.** `callFunctionAsync` resolves once the call is accepted, not once the
   target runs — there is no result, status, or execution id to get back.
+- **15-minute time limit.** The target runs with the same 15-minute handler time limit as a
+  scheduled function; a run still going at the limit is killed and counts as failed.
 - **Chaining is capped at two hops.** A normal (HTTP or scheduled) execution can call once; the
   execution it starts can call once more; a third hop is refused.
 - **The target must accept `POST`.** The call always dispatches as `POST`, regardless of the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trayai/helix-sdk",
-  "version": "1.13.0",
+  "version": "1.13.1",
   "description": "Helix SDK runtime — defineFunction, ctx, defineConfig, authed HTTP",
   "license": "Apache-2.0",
   "author": "trayio",