When compacting a collection that is actively being written it is possible that the collection is larger at the completion of compaction than when it started; I assume that this is an expected outcome. In this case the operation returns a negative number for bytesFreed:
{ "bytesFreed" : -339968, "ok" : 1, "$clusterTime" : { "clusterTime" : Timestamp(1614690587, 925), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } }, "operationTime" : Timestamp(1614690587, 898) }
Whereas an absurdly large value is logged for freedBytes:
{"t":{"$date":"2021-03-02T08:09:47.634-05:00"},"s":"I", "c":"STORAGE", "id":20286, "ctx":"conn24","msg":"Compact end","attr":{"namespace":"test.c","freedBytes":18446744073709211648}}
It looks like compactCollection is incorrectly treating the negative signed value as unsigned when it logs it.
Possibly both values should be logged as 0, since logging a negative value may make it appear that compact is malfunctioning.
Also, it would be good to make the command result and the log statement consistent; suggest changing the log statement to use "bytesFreed" as it seems less likely that users will be affected by changing the log statement than by changing the command return.