gleam-lang/gleam · info

channel buffer write

Error message

channel buffer write

What it means

InMemoryFileSystem::write_bytes writes content into a freshly created Vec<u8> via io::Write::write and expects success ("channel buffer write"). Writing into a Vec is infallible in Rust — the std Write impl for Vec<u8> returns Ok unconditionally (allocation failure aborts the process rather than returning Err) — so this expect cannot fire through any public API. It is a defensive assertion whose appearance in a crash log would indicate memory corruption or a patched std, not a usage error.

Source

Thrown at compiler-core/src/io/memory.rs:224

                err: None,
            });
        }
        let _ = files.remove(path);
        Ok(())
    }

    fn write(&self, path: &Utf8Path, content: &str) -> Result<(), Error> {
        self.write_bytes(path, content.as_bytes())
    }

    fn write_bytes(&self, path: &Utf8Path, content: &[u8]) -> Result<(), Error> {
        // Ensure directories exist
        if let Some(parent) = path.parent() {
            self.mkdir(parent)?;
        }

        let mut file = InMemoryFile::default();
        _ = io::Write::write(&mut file, content).expect("channel buffer write");
        _ = self
            .files
            .deref()
            .borrow_mut()
            .insert(path.to_path_buf(), file);
        Ok(())
    }

    fn exists(&self, path: &Utf8Path) -> bool {
        self.files.deref().borrow().contains_key(path)
    }
}

impl FileSystemReader for InMemoryFileSystem {
    fn canonicalise(&self, path: &Utf8Path) -> Result<Utf8PathBuf, Error> {
        Ok(path.to_path_buf())
    }

View on GitHub (pinned to 7e623aa83d)

Solutions

1. Treat it as unreachable — no filesystem or project change affects it.
2. If you somehow hit it, reproduce under a default allocator (unset MALLOC_ARENA_MAX/LD_PRELOAD overrides) and check for OOM with dmesg.
3. For maintainers: replace `let _ = ... .expect(...)` with `let _ = io::Write::write_all(&mut file, content);` or a debug_assert to document infallibility.

// Unreachable in practice; only relevant to long-running hosts that must
// survive any panic:
let wrote = std::panic::catch_unwind(|| {
    fs.write_bytes(&path, content) // InMemoryFileSystem::write_bytes
});
if wrote.is_err() {
    tracing::error!("in-memory write panicked; memory state suspect — rebuilding fs");
    fs.reset();
}

When it happens

Trigger: None reachable: there is no input to write_bytes that makes Vec's write return Err. OOM at this point aborts the allocator instead of reaching the expect.

Common situations: Realistically never seen; if a stack trace names it, suspect a fork-related allocator state bug or third-party allocator misuse in the same process, not gleam usage.

Related errors

• InMemoryFileSystem::into_files called on a clone
• InMemoryFile::into_content called with multiple references
• JavaScript generator could not identify imported module name
• Custom type must have at least one definition here
• `panic` expression evaluated.

AI-assisted analysis of gleam-lang/gleam@7e623aa83d (2026-08-17). Data as JSON: /api/errors/f169a212a3b6b1c5. Report an issue: GitHub.