Clients estimate the staleness of each secondary, and select for reads only those secondaries whose estimated staleness is less than or equal to maxStalenessSeconds. The default is -1, meaning no maximum staleness.

Is there a particular reason that NO_MAX_STALENESS is private, unlike MONGOC_WRITE_CONCERN_W_DEFAULT? As-is, this pushes developers to rely on a magic number in their application to detect a default or simply determine if a read preference has a maxStalenessSeconds option applied to it.

Should developers simply assume that any invalid value (i.e. <= 0) is effectively unset?