flora is a fast and secure runtime that lets you write discord bots for your servers, with a rich TypeScript SDK, without worrying about running infrastructure. [mirror]
fix(www): oops x2
+16
-18
+10
-10
apps/www/.vitepress/config.mts
+10
-10
apps/www/.vitepress/config.mts
···
10
10
// https://vitepress.dev/reference/default-theme-config
11
11
nav: [
12
12
{ text: 'Home', link: '/' },
13
-
{ text: 'SDK', link: '/sdk' },
14
-
{ text: 'Runtime', link: '/runtime' },
15
-
{ text: 'CLI', link: '/cli' },
16
-
{ text: 'Examples', link: '/examples' },
17
-
{ text: 'Limitations', link: '/limitations' }
13
+
{ text: 'SDK', link: '/docs/sdk' },
14
+
{ text: 'Runtime', link: '/docs/runtime' },
15
+
{ text: 'CLI', link: '/docs/cli' },
16
+
{ text: 'Examples', link: '/docs/examples' },
17
+
{ text: 'Limitations', link: '/docs/limitations' }
18
18
],
19
19
20
20
sidebar: [
21
21
{
22
22
text: 'Docs',
23
23
items: [
24
-
{ text: 'SDK', link: '/sdk' },
25
-
{ text: 'Runtime', link: '/runtime' },
26
-
{ text: 'CLI', link: '/cli' },
27
-
{ text: 'Examples', link: '/examples' },
28
-
{ text: 'Limitations', link: '/limitations' }
24
+
{ text: 'SDK', link: '/docs/sdk' },
25
+
{ text: 'Runtime', link: '/docs/runtime' },
26
+
{ text: 'CLI', link: '/docs/cli' },
27
+
{ text: 'Examples', link: '/docs/examples' },
28
+
{ text: 'Limitations', link: '/docs/limitations' }
29
29
]
30
30
}
31
31
],
+6
-8
apps/www/docs/limitations.md
+6
-8
apps/www/docs/limitations.md
···
4
4
5
5
# Limitations
6
6
7
-
This page documents known limitations and design trade-offs in the Flora runtime.
7
+
This page documents known limitations and design trade-offs in the flora runtime.
8
8
9
9
## Cron Jobs
10
10
···
21
21
| `is_running` flag | No | Reset to `false` |
22
22
| Execution history | No | No audit trail |
23
23
24
-
### Why This Is Usually Fine
24
+
### Why this is usually fine
25
25
26
26
1. **Scripts reload on startup.** When the runtime starts, it loads all deployments from the database and executes them. Your `cron()` calls run again, re-registering all jobs.
27
27
···
29
29
30
30
3. **Redeployment clears old jobs.** When you deploy a new version of your script, the runtime clears all cron jobs for that guild before loading the new script. This prevents stale jobs from lingering.
31
31
32
-
### Edge Cases to Be Aware Of
32
+
### Edge Cases to be aware of
33
33
34
34
**Duplicate execution on crash:** If the runtime crashes while a cron job is executing, the `is_running` flag is lost. On restart, the job may run again if it's due. Use `skipIfRunning: true` and design handlers to be idempotent where possible.
35
35
···
42
42
43
43
**Schedule drift:** If the runtime is down for an extended period, jobs won't "catch up" on missed executions. A job scheduled for midnight won't run at 2 AM if the bot was down at midnight — it will wait for the next midnight.
44
44
45
-
### When You Need More
45
+
### When you need more
46
46
47
47
If your use case requires:
48
48
···
50
50
- **Catch-up runs** after downtime
51
51
- **Non-idempotent side effects** (billing, one-time notifications)
52
52
53
-
Consider implementing your own persistence layer using the [KV store](/sdk#kv-store) to track execution state:
53
+
Consider implementing your own persistence layer using the [KV store](/docs/sdk#kv-store) to track execution state:
54
54
55
55
```ts
56
56
cron('critical-job', '0 * * * *', async () => {
···
62
62
return
63
63
}
64
64
65
-
await performCriticalWork()
65
+
await performCriticalWorkIdk()
66
66
await kv.set('critical-job:last-run', now)
67
67
})
68
68
```
···
82
82
| Cron timeout | 5 seconds |
83
83
| Boot timeout | 10 seconds |
84
84
| Max cron jobs per guild | 32 |
85
-
86
-
These can be adjusted via runtime configuration but are not exposed to end users.