Skip to content

feat(featureflags): read int flag fallbacks from the environment - #3654

Open
wei-w-wang wants to merge 1 commit into
e2b-dev:mainfrom
wei-w-wang:env-override-int-feature-flags
Open

wei-w-wang wants to merge 1 commit into
e2b-dev:mainfrom
wei-w-wang:env-override-int-feature-flags

Conversation

@wei-w-wang

Copy link
Copy Markdown

On a deployment without LAUNCH_DARKLY_API_KEY, every flag resolves to its compiled-in fallback. For the per-node limits that is a hard ceiling only a rebuild can change: "max-sandboxes-per-node" falls back to 200, which is sized for cloud node types, not for the host it runs on.

On a self-hosted node with 384 CPUs and 1.5 TB of memory, the orchestrator refuses the 201st sandbox with max number of running sandboxes on node reached (200), even though the host has capacity for several times that.

Change

Adds 'envIntOr', the int counterpart of the existing 'envBoolOr', and applies it to the two per-node limits:

  • max-sandboxes-per-node, set via MAX_SANDBOXES_PER_NODE` (fallback 200)
  • max-starting-instances-per-node, set via MAX_STARTING_INSTANCES_PER_NODE (fallback 3)

The override replaces the fallback, not the evaluated value:

  • Without a LaunchDarkly key: it's the value the offline store serves.
  • With a key: it's the default for flags the environment doesn't define. A defined LaunchDarkly flag still wins, so live configuration is not bypassed.

Unset, empty, unparseable, and non-positive values keep the existing fallback. Rejecting non-positive values means a typo can't silently stop a node from accepting sandboxes, and it matches the "Must be > 0" comment on MaxStartingInstancesPerNode.

Only these two flags opt in; no other behavior changes.

Testing

  • "go test ./pkg/featureflags/... -run TestEnvIntOr -v" and "golangci-lint run ./pkg/featureflags/..." (run from packages/shared) Pass
  • Verified on a 384-CPU, 1.5 TB node: with MAX_SANDBOXES_PER_NODE=1000, the orchestrator accepts sandboxes past 200 and the refusal no longer appears.

Notes

Other int flags could opt in the same way if useful; I kept this to the two limits that block self-hosted capacity.

@cla-bot

cla-bot Bot commented Sep 21, 2026

Copy link
Copy Markdown

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Wei Wang.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email email@example.com
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

@wei-w-wang
wei-w-wang force-pushed the env-override-int-feature-flags branch from ecf712e to a77a1c9 Compare September 21, 2026 14:43
@cla-bot

cla-bot Bot commented Sep 21, 2026

Copy link
Copy Markdown

We require contributors to sign our Contributor License Agreement, and we don't have @wei-w-wang on file. You can sign our CLA at https://e2b.dev/docs/cla . Once you've signed, post a comment here that says '@cla-bot check'

@wei-w-wang

Copy link
Copy Markdown
Author

@cla-bot check

@cla-bot cla-bot Bot added the cla-signed label Sep 21, 2026
@cla-bot

cla-bot Bot commented Sep 21, 2026

Copy link
Copy Markdown

The cla-bot has been summoned, and re-checked this pull request!

A deployment with no LAUNCH_DARKLY_API_KEY serves every flag's compiled-in
fallback, so an int flag resolves to a value only a rebuild can change.
That is fine for flags whose fallback is a safe default, but not for the
per-node limits: max-sandboxes-per-node falls back to 200, which is sized
for cloud node types rather than for the host it runs on. A self-hosted
node with 384 CPUs and 1.5 TB of memory refuses the 201st sandbox with
ResourceExhausted, and the only way past it is editing a literal in
flags.go.

Read the fallback of the two per-node limits from the environment:
max-sandboxes-per-node (MAX_SANDBOXES_PER_NODE) and
max-starting-instances-per-node (MAX_STARTING_INSTANCES_PER_NODE). The
override applies to the fallback rather than to the evaluated value, so
both modes stay consistent: without a LaunchDarkly key it is the value
the offline store serves, and with a key set it is the default for flags
that the LaunchDarkly environment does not define. A defined LaunchDarkly
flag still wins, so live configuration is not bypassed.

Both limits go through envPositiveIntOr, a thin wrapper added around the
existing envIntOr. envIntOr deliberately accepts zero and negative
values, since pause-admission-disk-headroom-mib uses -1 to turn its
check off, but these two limits must stay positive, so the wrapper keeps
the fallback for non-positive values. A typo then cannot silently stop a
node from accepting sandboxes, and it matches the "Must be > 0"
requirement already documented on MaxStartingInstancesPerNode.

Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
@wei-w-wang
wei-w-wang force-pushed the env-override-int-feature-flags branch from a7e74a8 to 30a9230 Compare October 20, 2026 15:18

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant