feat(featureflags): read int flag fallbacks from the environment - #3654
Open
wei-w-wang wants to merge 1 commit into
Open
wei-w-wang wants to merge 1 commit into
wei-w-wang wants to merge 1 commit into
Conversation
wei-w-wang
requested review from
ValentaTomas,
dobrac and
jakubno
as code owners
September 21, 2026 14:13
|
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Wei Wang.
|
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 this file. Add envIntOr, the int twin of envBoolOr, and use it for the two per-node limits: 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. Unset, empty, unparseable and non-positive values all keep the existing fallback. Rejecting non-positive values means a typo cannot silently stop a node from accepting sandboxes, and it matches the "Must be > 0" requirement already documented on MaxStartingInstancesPerNode. Only these two flags opt in; other int flags are unchanged. Other flag types can follow the same shape if there is demand. Signed-off-by: Wei Wang <wei.w.wang@hotmail.com>
wei-w-wang
force-pushed
the
env-override-int-feature-flags
branch
from
September 21, 2026 14:43
ecf712e to
a77a1c9
Compare
|
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' |
Author
|
@cla-bot check |
|
The cla-bot has been summoned, and re-checked this pull request! |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
The override replaces the fallback, not the evaluated value:
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
Notes
Other int flags could opt in the same way if useful; I kept this to the two limits that block self-hosted capacity.