@trayai/helix-sdk 0.99.0 → 0.101.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +15 -0
- package/README.md +8 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -9,6 +9,21 @@ general availability, minor versions may include breaking changes.
|
|
|
9
9
|
The SDK and [`@trayai/helix-cli`](https://www.npmjs.com/package/@trayai/helix-cli) are
|
|
10
10
|
released together and share a version — install matching versions.
|
|
11
11
|
|
|
12
|
+
## 0.100.0
|
|
13
|
+
|
|
14
|
+
### Added
|
|
15
|
+
|
|
16
|
+
- **Documented the runtime limits for scheduled functions.** The README's scheduled-functions
|
|
17
|
+
section now lists the limits a schedule handler runs under — the 180-second handler time
|
|
18
|
+
limit, at-least-once delivery with a single retry roughly five minutes after a failed run,
|
|
19
|
+
once-per-minute maximum frequency, and firing-precision behaviour — with guidance on
|
|
20
|
+
idempotent handlers and splitting long work across runs.
|
|
21
|
+
|
|
22
|
+
## 0.99.0
|
|
23
|
+
|
|
24
|
+
No user-visible changes in this release — co-versioned with
|
|
25
|
+
[`@trayai/helix-cli`](https://www.npmjs.com/package/@trayai/helix-cli)'s changes.
|
|
26
|
+
|
|
12
27
|
## 0.98.0
|
|
13
28
|
|
|
14
29
|
### Added
|
package/README.md
CHANGED
|
@@ -182,6 +182,14 @@ Things to know:
|
|
|
182
182
|
- Files and directories starting with `_` below `_scheduled/` are treated as helpers, not schedules — the only files that belong in the directory besides schedule definitions.
|
|
183
183
|
- `getContext()` works inside schedule handlers; shared code can detect a scheduled run by checking for `ctx.trigger`.
|
|
184
184
|
|
|
185
|
+
Limits — schedules run in the same deployed runtime as HTTP functions and share its execution limits:
|
|
186
|
+
|
|
187
|
+
- **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.
|
|
188
|
+
- **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`.
|
|
189
|
+
- **Highest frequency is once per minute** — 5-field cron has minute granularity.
|
|
190
|
+
- **Memory is managed by the platform** and is not configurable per function.
|
|
191
|
+
- 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.
|
|
192
|
+
|
|
185
193
|
## Authentication
|
|
186
194
|
|
|
187
195
|
Authenticated features (`ctx.http.authed`, `ctx.kv`, `ctx.files`) require you to be logged in during local development:
|