3

Mongo can't bring records which are in far far future like 2394-10-20T16:10:23

now: 2025-11-17


Description:

I have a timeseries collection in mongo and here is the command to created it:

db.createCollection( "tick", { timeseries: { timeField: "created_at", metaField: "id", granularity: "seconds", } } ) 

I figured out that there is some data which is for future (a tiny mistake) like: 2394-10-23T16:10:23.721Z in created_at field, and when I want to run below query:

db.tick.aggregate([ { $sort: {created_at: 1} }, ]) 

I'll get this error:

Command failed with error 6369910 (Location6369910): 'PlanExecutor error during aggregation :: caused by :: BoundedSorter input is too out-of-order: with bound 2394-11- 13T09:16:00.000+00:00, did not expect input 2025-09-29T15:17:27.815+00:00' on server ip:port. The full response is {"ok": 0.0, "errmsg": "PlanExecutor error during aggregation :: caused by :: BoundedSorter input is too out-of-order: with bound 2394-11-13T09:16:00.000+00:00, did not expect input 2025-09-29T15:17:27.815+00:00", "code": 6369910, "codeName": "Location6369910"} 

I also tried descending order for created_at

But it couln't show me the future records.

So how did I find them?

I run my query with natural order (not specifying sort) in my JetBrains IDE.

0

1 Answer 1

4

Create an index on created_at and retry.

db.tick.createIndex( { created_at: 1 } ) 

From the docs about Time Series Collection Limitations:

Extended Date Range

If your time series collection contains documents with timeField timestamps before 1970-01-01T00:00:00.000Z or after 2038-01-19T03:14:07.000Z, create an index on the timeField to optimize queries.

Sign up to request clarification or add additional context in comments.

4 Comments

Thank you @aneroid to answering, that just worked...🙏 I added some fake data and tested that and all thing was OK.
I noticed a strange thing, when I applied / dropped an index to a collection (specially large ones that are time series), I had to restart the mongodb to use it! and also it consumes too much ram. How should debug it and find out is problem? or this is a natural thing in mongodb?
For example this query (sort by timefield which is indexed twice, one for timeseries and one extra due to official documentation) takes for ever: db.tick.find({}).sort({created_at: 1}).limit(1), but this one (that uses natural sort) will work properly: db.tick.find({}).sort({"$natural": 1}).limit(1). Is there any explanation for this? @aneroid
"$natural" order is not reliable. It's fast because it's how the documetss are stored in the DB. From the docs "This ordering is an internal implementation feature, and you should not rely on any particular ordering of the documents."

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.