What causes "$FLOW_STACK_SIZE must be a number, got {s}" in facebook/flow?

Set a plain decimal byte count: FLOW_STACK_SIZE=134217728 for 128 MiB.

$FLOW_STACK_SIZE must be a number, got {s}

Error message

$FLOW_STACK_SIZE must be a number, got {s}

What it means

Flow's ThreadPool reads $FLOW_STACK_SIZE to override the default worker stack size (deep recursion in the typechecker needs big stacks). The value must parse as usize — a plain decimal byte count. Any non-numeric value panics the moment a ThreadPool is constructed, which is at server/parser/codemod startup, before any real work starts.

Source

Thrown at rust_port/crates/flow_utils_concurrency/src/thread_pool.rs:110

    {
        NonZeroUsize::new(num_cpus::get_physical()).unwrap_or_else(logical_parallelism)
    }
}

#[cfg(not(target_arch = "wasm32"))]
pub struct ThreadPool(Option<rayon::ThreadPool>);

#[cfg(target_arch = "wasm32")]
pub struct ThreadPool;

impl ThreadPool {
    #[cfg(not(target_arch = "wasm32"))]
    fn stack_size() -> usize {
        match env::var("FLOW_STACK_SIZE") {
            Ok(s) => {
                let res = s
                    .parse::<usize>()
                    .unwrap_or_else(|_| panic!("$FLOW_STACK_SIZE must be a number, got {s}"));
                info!(
                    "Using stack size of {} bytes (due to `$FLOW_STACK_SIZE`)",
                    number_thousands(res)
                );
                res
            }
            Err(_) => DEFAULT_STACK_SIZE,
        }
    }

    pub fn with_thread_count(count: ThreadCount) -> Self {
        #[cfg(target_arch = "wasm32")]
        {
            let _ = count;
            return Self;
        }
        #[cfg(not(target_arch = "wasm32"))]
        {

View on GitHub (pinned to f88ac94bcf)

Solutions

Set a plain decimal byte count: FLOW_STACK_SIZE=134217728 for 128 MiB.
Unset the variable to fall back to the built-in DEFAULT_STACK_SIZE.
Fix the deployment manifest/script that assigns the suffixed value.
Sanitize the variable in your launcher (strip or unset non-numeric values) so bad configs fail soft.

Example fix

# before
export FLOW_STACK_SIZE=8MB   # panic: $FLOW_STACK_SIZE must be a number, got 8MB

# after
export FLOW_STACK_SIZE=8388608

Defensive patterns

Strategy: validation

Validate before calling

# sanitize before launching anything that builds a ThreadPool
if [ -n "$FLOW_STACK_SIZE" ] && ! [[ "$FLOW_STACK_SIZE" =~ ^[0-9]+$ ]]; then
  echo "FLOW_STACK_SIZE='$FLOW_STACK_SIZE' is not a plain number - unsetting" >&2
  unset FLOW_STACK_SIZE
fi

Type guard

# bash type guard for launch scripts
is_valid_stack_size() { [[ "$1" =~ ^[0-9]+$ ]]; }
is_valid_stack_size "$FLOW_STACK_SIZE" || unset FLOW_STACK_SIZE

Prevention

Use plain decimal byte counts (134217728 = 128 MiB); never unit suffixes.
Centralize the variable in one manifest and lint it for ^[0-9]+$ in CI.
Document the byte semantics next to every place it is set.
If unsure, unset it and rely on DEFAULT_STACK_SIZE.

When it happens

Trigger: Setting FLOW_STACK_SIZE to a value with units or a non-decimal form — 8MB, 8m, 0x800000, '1 gb', '8_388_608', or an empty string — and then starting any binary that builds a ThreadPool.

Common situations: Ops configs copying ulimit-style values with suffixes; CI pipelines exporting the variable globally with a typo; users assuming MiB units; empty assignments like FLOW_STACK_SIZE= in scripts.

Related errors

AI-assisted analysis of facebook/flow@f88ac94bcf (2026-08-20). Data as JSON: /api/errors/5258041a8c9c4947. Report an issue: GitHub.