What causes "Unable to make a writeConcern from fsync=${value}" in mongodb/node-mongodb-native?

Replace `fsync` with `journal: true` (the supported, non-deprecated equivalent).

mongodb/node-mongodb-native · warning · MongoParseError

Unable to make a writeConcern from fsync=

Error message

Unable to make a writeConcern from fsync=${value}

What it means

`fsync` is a deprecated write-concern option (the descriptor carries `deprecated: 'Please use journal instead'`). The transform at src/connection_string.ts:839 builds a WriteConcern via `WriteConcern.fromOptions`; if that returns a falsy value, the driver throws MongoParseError at src/connection_string.ts:846. The boolean coercion itself happens earlier via getBoolean, so a non-boolean fsync surfaces as a separate 'must be either true or false' error.

Solutions

Replace `fsync` with `journal: true` (the supported, non-deprecated equivalent).
Prefer a single `writeConcern: { w: 'majority', journal: true }` object instead of spreading concerns across options.
If you must use fsync, ensure the surrounding writeConcern fields are consistent and not stripped by config merging.

Example fix

// before
new MongoClient(uri, { fsync: true });

// after
new MongoClient(uri, { journal: true });

Defensive patterns

Strategy: validation

Validate before calling

if ('fsync' in opts) {
  console.warn('fsync is deprecated; use journal instead');
  opts.journal = Boolean(opts.fsync);
  delete opts.fsync;
}

Type guard

null

Try / catch

try { client = new MongoClient(uri, opts); } catch (e) { if (e instanceof MongoParseError && /fsync/.test(e.message)) { opts.journal = (opts as any).fsync; delete (opts as any).fsync; client = new MongoClient(uri, opts); } else throw e; }

Prevention

Stop using fsync; prefer journal.
Consolidate write-concern fields into one `writeConcern` object.
Run an ESLint custom rule or grep for `fsync:` in your config layer.

When it happens

Trigger: Passing `fsync: true` together with other writeConcern fields in a combination that WriteConcern.fromOptions refuses to materialize; or wiring fsync through a config layer that strips sibling writeConcern fields. In practice this branch is rare because the boolean itself is already validated.

Common situations: Carrying forward v3-era option names; mixing `fsync` with a hand-built `writeConcern` object whose keys collide or cancel out; tooling that drops empty fields when merging config.

Related errors

AI-assisted analysis of mongodb/node-mongodb-native@dce7939f86 (2026-08-11). Data as JSON: /api/errors/054f51e1c38aad2a. Report an issue: GitHub.

Appendix: source

Thrown at src/connection_string.ts:846

  },
  fieldsAsRaw: {
    type: 'record'
  },
  forceServerObjectId: {
    default: false,
    type: 'boolean'
  },
  fsync: {
    deprecated: 'Please use journal instead',
    target: 'writeConcern',
    transform({ name, options, values: [value] }): WriteConcern {
      const wc = WriteConcern.fromOptions({
        writeConcern: {
          ...options.writeConcern,
          fsync: getBoolean(name, value)
        }
      });
      if (!wc) throw new MongoParseError(`Unable to make a writeConcern from fsync=${value}`);
      return wc;
    }
  } as OptionDescriptor,
  heartbeatFrequencyMS: {
    default: 10000,
    type: 'uint'
  },
  ignoreUndefined: {
    type: 'boolean'
  },
  j: {
    deprecated: 'Please use journal instead',
    target: 'writeConcern',
    transform({ name, options, values: [value] }): WriteConcern {
      const wc = WriteConcern.fromOptions({
        writeConcern: {
          ...options.writeConcern,
          journal: getBoolean(name, value)

View on GitHub (pinned to dce7939f86)