Work was done in SERVER-25723 to avoid crashing a secondary upon replicating a structurally invalid view definition (i.e. one with unknown fields or incorrect types). We should consider whether it's possible and that we're willing to reject user-initiated writes to the system.views collection. One approach would be to return an error in the following functions that were introduced by redbeard0531's work in SERVER-23128. The parsing and validation would be performed prior the catalog operation that actually does the write and should not impact the replication of views.

• parseInsertCommand()
• parseUpdateCommand()
• parseDeleteCommand()
• parseLegacyInsert()
• parseLegacyUpdate()
• parseLegacyDelete()

It is worth mention that issues such as SERVER-25492 and SERVER-25680 were only identified as a result of a user being able to write directly to the system.views collection. Since we may end up changing the document structure of a view definition in a future release (e.g. by adding a new option), we may want to be able to retain the ability to write directly to the system.views collection for testing purposes.