|
| 1 | +import { ulid } from 'ulid'; |
| 2 | + |
| 3 | +/** |
| 4 | + * Identifier for the compute instance (the warm serverless instance / |
| 5 | + * microVM) that this module was loaded into. |
| 6 | + * |
| 7 | + * Vercel exposes no native per-instance id under Fluid compute — all |
| 8 | + * `AWS_LAMBDA_*` env vars (including `AWS_LAMBDA_LOG_STREAM_NAME`) are |
| 9 | + * blocked — so we synthesize our own once at module load. The value is |
| 10 | + * therefore: |
| 11 | + * |
| 12 | + * - **stable for the life of the warm instance**, and |
| 13 | + * - **shared across every invocation that instance handles**, including the |
| 14 | + * concurrent invocations Fluid compute packs onto a single instance. |
| 15 | + * |
| 16 | + * Distinct warm instances (and every cold start) get distinct ids. Both the |
| 17 | + * flow and step route entrypoints import this module, so any bundles |
| 18 | + * co-resident on one instance report the same id. |
| 19 | + * |
| 20 | + * The value is a prefixed ULID (`cinst_<ulid>`), matching the id convention |
| 21 | + * used elsewhere (`wrun_`, `step_`, `hook_`, …). Using a ULID means the |
| 22 | + * timestamp component encodes the instance's birth time, so ids sort |
| 23 | + * lexicographically by creation — useful for ordering/aging instances and |
| 24 | + * spotting cold starts in observability tooling. |
| 25 | + * |
| 26 | + * Surfaced two ways: |
| 27 | + * - as a span attribute, and |
| 28 | + * - persisted on `step_started` events as `computeInstanceId`, so tooling can |
| 29 | + * tell which step attempts ran on the same instance vs different instances, |
| 30 | + * and within an instance which ran in the same invocation vs different ones. |
| 31 | + */ |
| 32 | +export const COMPUTE_INSTANCE_ID = `cinst_${ulid()}`; |
0 commit comments