How can I safely retry a FeathersJS Mongoose patch with upsert to avoid duplicate writes on transient failures?

Answer the Exact Question First

When a FeathersJS service backed by feathers‑mongoose performs a patch with upsert:true, the driver returns a writeResult that contains an upsertedId if a new document was created. You can safely retry the operation only if you can confirm that the first attempt either succeeded or failed before any acknowledgment was sent to the client. The most reliable way to guarantee this is to wrap the patch in a MongoDB transaction and use writeConcern: { w: 'majority', j: true }. The transaction ensures that either the insert or the update is fully committed before the client sees success, and the upsertedId will be present only for an actual insert.

Confirmed Facts

• The writeResult returned by findOneAndUpdate (used internally by feathers‑mongoose) contains upsertedId when a new document is inserted.
• MongoDB transactions are atomic on replica sets and sharded clusters that support them (MongoDB 4.0+).
• Setting writeConcern: { w: 'majority', j: true } guarantees that the write is acknowledged by a majority of nodes before the driver resolves the promise.
• FeathersJS hooks do not expose a Mongoose session by default; you must create and attach one yourself.

Practical Steps for This Case

1. Create a Mongoose session in a before‑hook:

   async function startSession(hook) {
     const session = await hook.app.get('mongooseClient').startSession();
     hook.session = session;
   }
   

2. Wrap the patch in a transaction with retry logic:

   async function transactionalPatch(hook) {
     const { app, data, params } = hook;
     const session = hook.session;
     const maxRetries = 3;
     let attempt = 0;
     while (attempt < maxRetries) {
       try {
         await session.withTransaction(async () => {
           // feathers‑mongoose internally calls findOneAndUpdate
           const result = await app.service('my-service').patch(null, data, {
             ...params,
             session,
             upsert: true,
             new: true,
             writeConcern: { w: 'majority', j: true }
           });
           hook.result = result;
         });
         break; // success
       } catch (err) {
         if (isTransient(err)) { attempt++; continue; }
         throw err;
       }
     }
     if (attempt === maxRetries) throw new Error('Max retry attempts reached');
   }
   
   function isTransient(err) {
     return err.name === 'MongoNetworkError' || err.name === 'MongoWriteConcernError';
   }
   

3. Check the writeResult for upsertedId:

   const { upsertedId } = hook.result;
   if (upsertedId) {
     // A new document was inserted – safe to log or return the new ID
   }
   

4. Ensure the filter used in the patch is unique:
   Use the document’s _id or a unique index field. This guarantees that even if a retry happens after the first write, the filter will only match the same document and not create a duplicate.
5. Commit the session after the transaction:

   await hook.session.endSession();
   

When to Rely on upsertedId Alone

If your deployment does not support transactions (e.g., a single-node MongoDB, or a cluster without a replica set), you can still use upsertedId to decide whether to retry. However, you must be very careful to use a unique filter and to catch only genuine network failures. In such environments, an exponential‑backoff retry loop with a low maximum count (2–3 retries) is recommended.

Ask for Missing Diagnostic Detail

To fine‑tune the recommendation, could you confirm whether your MongoDB deployment supports transactions (replica set or sharded cluster with replica sets) and what field(s) you use as the patch filter? This will determine if the transaction‑based approach is applicable.