windmill-labs/windmill · error

Not implemented in Windmill's Open Source repository

Error message

Not implemented in Windmill's Open Source repository

What it means

In the OSS build of windmill-api (compiled without the `private` feature), `get_random_file_name` in job_helpers_oss.rs is a stub whose body calls `unimplemented!`. The real implementation lives in the private/EE repository, so any OSS code path that needs a random S3/object-storage file name aborts with this message.

Source

Thrown at backend/windmill-api/src/job_helpers_oss.rs:65

pub fn workspaced_service() -> Router {
    Router::new()
}

#[cfg(all(feature = "parquet", not(feature = "private")))]
pub async fn get_workspace_s3_resource<'c>(
    _authed: &ApiAuthed,
    _db: &DB,
    _user_db: Option<UserDB>,
    _w_id: &str,
    _storage: Option<String>,
) -> windmill_common::error::Result<(Option<bool>, Option<ObjectStoreResource>)> {
    // implementation is not open source
    Ok((None, None))
}

#[cfg(not(feature = "private"))]
pub fn get_random_file_name(_file_extension: Option<String>) -> String {
    unimplemented!("Not implemented in Windmill's Open Source repository")
}

#[cfg(not(feature = "private"))]
use windmill_common::db::DbWithOptAuthed;

#[cfg(not(feature = "private"))]
pub async fn get_s3_resource<'c>(
    _db_with_opt_authed: &DbWithOptAuthed<'c, ApiAuthed>,
    _w_id: &str,
    _resource_path: &str,
    _resource_type: Option<StorageResourceType>,
    _job_id: Option<Uuid>,
) -> error::Result<ObjectStoreResource> {
    Err(error::Error::internal_err(
        "Not implemented in Windmill's Open Source repository".to_string(),
    ))
}

View on GitHub (pinned to e474e8803c)

Solutions

  1. Use the supported OSS upload path instead: upload to S3 from a script/flow via the S3 resource integration rather than app/multipart endpoints that require EE helpers.
  2. Run a server built with the `private` feature (enterprise edition) if app S3 uploads are required.
  3. If you control the fork, implement `get_random_file_name` in the OSS build (e.g. generate a UUID-based file name honoring the extension).
  4. Check the deployment's edition/feature flags and confirm the endpoint you call is available in your build.

Example fix

// before (OSS stub)
pub fn get_random_file_name(_file_extension: Option<String>) -> String {
    unimplemented!("Not implemented in Windmill's Open Source repository")
}
// after (fork-local implementation)
pub fn get_random_file_name(file_extension: Option<String>) -> String {
    let ext = file_extension.map(|e| format!(".{e}")).unwrap_or_default();
    format!("{}{ext}", uuid::Uuid::new_v4())
}
Defensive patterns

Strategy: fallback

Validate before calling

// detect OSS build before calling app/multipart upload paths
const isEE = window.instanceInfo?.instance_id && window.instanceInfo?.license_key;
if (!isEE) {
  // fall back to script-based S3 upload
}

Type guard

function supportsAppUpload(info: { license_key?: string | null }): boolean {
  return Boolean(info.license_key);
}

Try / catch

try {
  await uploadS3FileFromApp(file);
} catch (e) {
  if (String(e.message).includes("Not implemented in Windmill's Open Source repository")) {
    await uploadViaScript(file); // OSS fallback: wmill script with S3 resource
  } else { throw e; }
}

Prevention

When it happens

Trigger: Calling code paths that depend on `get_random_file_name`, e.g. `upload_s3_file_from_app` (app-driven S3 file uploads) or `process_multipart` (multipart file upload handling), running against an OSS-built server without the `private` feature.

Common situations: Uploading files from a Windmill app to S3 on a community-edition deployment; multipart file upload endpoints hit on an OSS binary; deploying an EE-only feature set (app file upload) with an OSS-licensed server.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/373f5f2dae476f97. Report an issue: GitHub.