Repository navigation
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.
|
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! |
wei-w-wang
force-pushed
the
env-override-int-feature-flags
branch
from
October 3, 2026 02:48
8fc485f to
8a7ebff
Compare
wei-w-wang
force-pushed
the
env-override-int-feature-flags
branch
from
October 20, 2026 15:02
8a7ebff to
c64f052
Compare
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
force-pushed
the
env-override-int-feature-flags
branch
from
October 20, 2026 15:18
a7e74a8 to
30a9230
Compare
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
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.