The abstract Stream class defines Flush and FlushAsync methods that must be implemented by subclasses of Stream.

The normal semantics of Flush and FlushAsync are that any pending data is written to the underlying store immediately. The usual intent when calling Flush is to prevent any data loss in the event the process is aborted.

Clearly we should throw a NotSupportedException when Flush is called on a GridFS download stream (because download streams are read-only and Flush is a method for writable streams). But what should we do when Flush is called on a GridFS upload stream?

In the case of GridFS we can't actually write pending data to the underlying data store (i.e. the GridFS bucket) because GridFS data is written in chunks and we don't have the data for the rest of the chunk yet. Furthermore, a GridFS file isn't actually considered to exist until it is 100% uploaded and the files collection metadata document is written, so even if we decided to flush a partial chunk to the chunks collection (and overwrite it later when the rest of the data for the chunk becomes available), it sill wouldn't serve the purpose of preventing data loss.

The two options for implementing Flush on an upload stream are:

1. Throw a NotSupportedException (because Flush is not supported)
2. Implement Flush as a no-op

The first is arguably more correct, but runs the risk of breaking any code (some of which might be out of the user's control) that calls Flush assuming that it is supported.

The second is more compatible with existing code because it simply does nothing instead of throwing an exception, at the expense of providing the false illusion that the Flush was actually done.

Our current thinking is that compatibility with existing code that might call Flush is more important than accurately reporting that Flush isn't actually supported.

So Flush and FlushAsync for GridFS upload streams will be implemented as no-ops (a download stream will still throw a NotSupportedException).