Skip to content

Add the streaming-worker subchart - #244

Merged
koikonom merged 1 commit into
lago-v2from
inf-415_streaming_worker
Sep 7, 2026
Merged

Add the streaming-worker subchart#244
koikonom merged 1 commit into
lago-v2from
inf-415_streaming_worker

Conversation

@koikonom

@koikonom koikonom commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

Context

The streaming events feature needs a Sidekiq worker with an AWS identity of
its own. The lago-api side is getlago/lago-api#6298, which adds
config/sidekiq/sidekiq_streaming.yml and
scripts/start.streaming.worker.sh, and states that the worker deployment is
infrastructure work. Tracked as INF-415.

Description

Adds the lago-rails alias streaming-worker, gated on
global.sidekiq.queues.streaming and off by default. It runs
./scripts/start.streaming.worker.sh, which consumes the hard-coded
streaming queue.

The alias renders no enqueue-side env var, unlike alerts, wallets, and
aiAgent. DeliverEventJob is pinned to the queue with
queue_as :streaming, and nothing is enqueued unless the organization holds a
streaming_destinations row. So a cluster that leaves the toggle off never
fills the queue, and no rails pod needs a SIDEKIQ_STREAMING flag.

The worker writes to a customer transport through sts:AssumeRole, so its pod
needs an identity the other workers do not have. The lago-rails
serviceAccount.create and serviceAccount.name values cover that: a cluster
can bind the pods to one fixed account. EKS Pod Identity maps one account to
one role with no wildcard, and preview releases name their accounts per
branch, so the fixed account is what keeps that to a single association.

Verification

helm unittest charts/lago — 65 pass in 8 suites, 4 cases new:

  • the Deployment renders with the start script,
  • the worker gets its own ServiceAccount,
  • serviceAccount.create: false plus a name binds the pods to that account,
  • and then the chart renders no ServiceAccount of its own.

helm template with the toggle off renders no lago-streaming-worker object.
With it on it renders rel-lago-streaming-worker as a Deployment and a
ServiceAccount, with command: ["./scripts/start.streaming.worker.sh"].

Notes for review

  • No version bump here. chart-release.yml bumps every chart and commits it,
    so the release is a workflow_dispatch on lago-v2 after this merges.
  • charts/lago/README.md is not regenerated. helm-docs gives 91 lines of
    diff because the checked-in file is stale since 0.6.0, and neither the
    ai-agent-worker commit nor the architecture split touched it.
  • Chart.lock moved because helm dependency update is needed to run the unit
    tests.

Adds the `lago-rails` alias that consumes the `streaming` Sidekiq queue,
gated on `global.sidekiq.queues.streaming`. It runs
`./scripts/start.streaming.worker.sh`
(config/sidekiq/sidekiq_streaming.yml), which lago-api adds in
getlago/lago-api#6298.

The alias renders no enqueue-side env var, unlike alerts, wallets, and
aiAgent. `DeliverEventJob` is pinned to the queue with
`queue_as :streaming`, and nothing is enqueued unless the organization
holds a `streaming_destinations` row. So a cluster that leaves the
toggle off never fills the queue, and no rails pod needs a
`SIDEKIQ_STREAMING` flag.

The worker writes to a customer transport through `sts:AssumeRole`, so
its pod needs an AWS identity the other workers do not have. The
lago-rails ServiceAccount values carry that: `serviceAccount.create` and
`serviceAccount.name` let a cluster bind the pods to one fixed account,
which is what EKS Pod Identity needs, since it maps one account to one
role with no wildcard.

Verified with `helm unittest charts/lago` (65 PASS, 4 of them new) and
`helm template`: the toggle off renders nothing, and on it renders the
Deployment with the start script plus its own ServiceAccount.

Refs INF-415
@koikonom
koikonom merged commit 7ea23ed into lago-v2 Sep 7, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants