Uploaded image for project: 'Compass '
  1. Compass
  2. COMPASS-5998

Investigate changes in SERVER-57384: Remove serverStatus counters and logging for deleted opcodes

    • Type: Icon: Investigation Investigation
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • No version
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Not Needed

      Original Downstream Change Summary

      in serverStatus.opcounters.deprecated removed counters for getmore, killcursors, delete, insert, update, total. The meaning of the "query" counter has been changed to track OP_QUERY requests for commands that are temporarily still supported (see `checkAllowedOpQueryCommand()` for the full list)

      Description of Linked Ticket

      We are planning to remove support for OP_INSERT, OP_UPDATE, OP_DELETE, OP_QUERY, OP_GET_MORE, OP_KILL_CURSORS, and getLastError in an upcoming version (likely 5.1). However, we are going to leave logic from SERVER-56501 to count attempted uses of the deleted opcodes. This will allow us to determine whether, and how often, applications are attempting to use the no-longer-supported op codes against a particular server. Similarly, the warning logging first introduced in SERVER-55788 will be initially left in place.

      Eventually, once we are sure that users have taken all necessary action to avoid use of the legacy opcodes, we should delete the remaining traces of the legacy opcodes in the server code. Rather than producing a clean error message saying something like "OP_QUERY is no longer supported, please upgrade your driver", logging a warning to the same effect, and bumping a serverStatus() counter, after this change the server will instead produce an error with some obscure error message related to validation of the wire protocol message's structure (something like "unknown opcode 2004").

      The version in which we should make this change is an open question. My initial proposal would be to schedule it for some version greater than 6.0, for example 6.1 or 6.2. That way, the initial deprecation will have happened in 5.0, there will still be useful error messages in 6.0, and post-6.0 all traces of the legacy opcodes will finally be fully removed.

            Assignee:
            Unassigned Unassigned
            Reporter:
            backlog-server-pm Backlog - Core Eng Program Management Team
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: