facebook/flow · critical

init failed: {:?}

Error message

init failed: {:?}

What it means

The standalone Flow server runs type_service::init() on a thread pool during startup — this parses .flowconfig, sets up module resolution, loads libs, and allocates heaps. If init returns Err, the code panics with 'init failed: {:?}' where the debug payload IS the real error. The panic is just the outermost wrapper: diagnose the embedded error value, not this message.

Source

Thrown at rust_port/crates/flow_server/src/standalone.rs:296

            .spawn(move || {
                let init_result = std::panic::catch_unwind(AssertUnwindSafe(|| {
                    flow_server_env::monitor_rpc::status_update(server_status::Event::InitStart);
                    eprintln!("Initializing server...");
                    let init_start = std::time::Instant::now();
                    let pool = ThreadPool::with_thread_count(
                        flow_utils_concurrency::thread_pool::ThreadCount::NumThreads(
                            std::num::NonZeroUsize::new(init_pool_workers)
                                .expect("pool_workers should be positive"),
                        ),
                    );
                    let (env, _first_internal_error) = match type_service::init(
                        &init_options,
                        &pool,
                        &init_committed_heap,
                        None,
                    ) {
                        Ok(result) => result,
                        Err(error) => panic!("init failed: {:?}", error),
                    };
                    let mut env = server_monitor_listener_state::update_env(Arc::new(env));
                    let init_duration = init_start.elapsed().as_secs_f64();
                    let finishing_up_status = server_status::Status::Typechecking(
                        server_status::TypecheckMode::Initializing,
                        server_status::TypecheckStatus::FinishingTypecheck,
                    );
                    env = flow_server_env::server_env::with_connections(
                        env,
                        persistent_connection::all_clients(),
                    );
                    persistent_connection::send_status(
                        finishing_up_status,
                        (
                            file_watcher_status::FileWatcher::NoFileWatcher,
                            file_watcher_status::StatusKind::Ready,
                        ),
                        &env.connections,

View on GitHub (pinned to f88ac94bcf)

Solutions

1. Read the {:?} payload in the panic output — it names the concrete init error; that message is the actual diagnosis.
2. Reproduce outside the daemon: run flow check from the same root with the same flowconfig_name to surface config errors directly.
3. Bisect .flowconfig: comment out [options] entries until init succeeds, then re-add one by one.
4. Clear the flow temp dir to remove stale caches/locks and retry; verify the daemon user can read the root and the flowconfig.

Example fix

# before: daemon started against a root without the named flowconfig
flow start --root /src --flowconfig-name .flowconfig.dev  # panic: init failed: ...

# after: verify the config exists, then start
cd /src && ls .flowconfig.dev && flow start

# before starting the standalone daemon, prove root+flowconfig are sane
test -f "$ROOT/$FLOWCONFIG" || { echo "no $FLOWCONFIG at $ROOT" >&2; exit 1; }
flow check --root "$ROOT" --flowconfig-name "$FLOWCONFIG" >/dev/null \
  || { echo "flowconfig errors; fix before daemonizing" >&2; exit 1; }

let r = std::panic::catch_unwind(|| start_standalone_server(opts));
if r.is_err() {
    // 'init failed: <error>' — the payload names the config problem;
    // report it and keep the service in a restart-backoff loop
    report_and_backoff();
}

When it happens

Trigger: Starting the standalone server with an unreadable or invalid .flowconfig, a root that is not a directory or contains no flowconfig for the configured flowconfig_name, options the build does not accept, lib extraction failures, or heap allocation failures for very large projects.

Common situations: Wrong --root passed to the daemon; .flowconfig with syntax errors or options from a newer Flow release used with an older binary; flowconfig_name pointing at a custom file that is missing; corrupted temp-dir state from a previous crashed run; memory limits (cgroup) too small for init.

Related errors

• failed to spawn server daemon: {}
• Unsupported .flowconfig option `log.file`. The VS Code exten
• flow.js wasm is still loading; await flow.ready first.
• mkdir_no_fail({:?}): {}
• Unsupported CLI socket command: {}

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