Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2141

Prohibit retryable writes for write commands targeting unreplicated local collection

    • Type: Icon: Spec Change Spec Change
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Component/s: Retryability
    • Labels:
      None
    • Needed

      Attempting to write to the local database results in the following server error from db/repl/oplog.cpp:

      retryable writes is not supported for unreplicated ns: %s
      

      I expect this error relates to this notable restriction in the MongoDB manual. While the restriction refers to multi-document transactions, I assume it overlaps with the common tooling used for retryable writes (e.g. txnNumber).

      I caught this error when upgrading PHPC to a version of libmongoc that had enabled retryable writes by default. The particular test was replicaset/manager-selectserver-001.phpt, which attempts to insert some documents into a local.example collection. I don't recall any particular reason it uses the the local database, and this could easily be changed to use a replicated database, but it did highlight a potential conflict I think may have been overlooked.

      It's possible this conflict could introduce unexpected errors in applications that write to collections in the local database. This is certainly an edge case, but the same could be said for MMAPv1 users in SPEC-1345.

      I can think of two approaches off the top of my head:

      • Document this conflict in drivers. We can also suggest that the DOCS team update their notable restriction.
      • Amend the spec to prohibit retryable writes for write commands targeting the local database. This should be possible without inspecting the command document, since we could inspect the global $db argument (for OP_MSG). This would require code changes in drivers.

      Note: I'm only referring to "local" in this ticket as it's the only unreplicated collection that I'm aware of. If others are possible, that may complicate the suggestion to implement checks.

            Assignee:
            Unassigned Unassigned
            Reporter:
            jmikola@mongodb.com Jeremy Mikola
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: