Mongoose har "scheman" för vilka den gör denna magiska sak som kallas "autocasting" åt dig. Typfallet designerna har i åtanke här är att all input från "webb"-interaktioner som GET och POST finns i princip i en "sträng".
Oavsett om det finns någon hjälpare som gör parametrar till objekt med nycklar och värden, är alla dessa "värden" fortfarande "strängar", eller möjligen gjorda direkt numeriska av samma "hjälpare" där så är lämpligt. Detta är vanlig webbramverksdesign.
Så när du utfärdar en .find() , den här funktionen är helt oförmögen att ändra det returnerade innehållet på annat sätt än genom att utelämna fält/egenskaper, så därför tillämpas "schemat".
.aggregate() metoden är helt annorlunda. Hela dens existens är att modifiera innehåll i dokument och samlingar. Konsekvensen av detta är att det är "omöjligt" för ett schema att tillämpa.
Därför är "autocasting" som finns i metoder som .find() händer inte , och du måste casta element (som "strängen" som ditt "datum" skickas in som ) till rätt typer själv:
Reservation.aggregate([
{ "$match": { "createdAt": { "$lte": new Date(req.endDate) } } }
])
Även om allt du gör är en $match och att du inte har "modifierat" schemat på något sätt, mongoose "förutsätter" inte detta och försöker inte kasta till det matchande fältet i schemat.
Logiken här är att en $match skede eller något liknande som kan vara bundet till en "typ", kan förekomma var som helst inom pipelinen. Som sådan finns det ingen garanti för att de dokument som åtgärdas av ett pipelinesteg har någon likhet med det ursprungliga insamlingsschemat.
Förmodligen "kunde" tänk eventuellt på det faktum att detta är det första steget i pipeline där ingenting möjligen kunde ha förändrats och göra en liknande inspektion. Men det var inte så den nuvarande kodbasen fungerade.
Så kort sagt, när du använder aggregeringspipelinen, måste alla objekt som behöver castas specifikt till en typ (Date, ObjectId, etc ) "manuellt" gjutas i din kod, snarare än att anta att mongoose kommer att göra det åt dig som i andra metoder.