What / where
CreateShipmentInput.deliveryDeadlineAt in src/shipments/dto/shipment.dto.ts (line 47) is only validated with @IsDate():
@Field()
@IsDate()
deliveryDeadlineAt: Date;
There is no check anywhere — in the DTO or in ShipmentsService.create (src/shipments/shipments.service.ts, lines 13-38) — that this date is in the future relative to now().
Why it's a problem
createShipment(input: { ..., deliveryDeadlineAt: "2020-01-01T00:00:00Z" }) is accepted as a perfectly valid shipment: @IsDate() only checks that the value parses to a Date instance, not that it's a sensible one. A sender can create (and, per the openShipments query, publicly list for any carrier to accept) a shipment whose delivery deadline has already passed, or that's a second in the future, with no server-side rejection. Since ROADMAP.md notes that delivery-deadline-based reminder/expiry jobs are planned (ScheduleModule is already wired into src/app.module.ts for this), a bad-data shipment like this would be immediately "overdue" from the moment those jobs ship, and today it just silently sits in the openShipments list misleading carriers about a job that can't realistically be fulfilled in time.
Suggested fix
Add a class-validator check that deliveryDeadlineAt is after the current time, e.g. a @MinDate(() => new Date()) decorator (or a small custom validator, since MinDate needs a fixed/callable reference), returning a clear BadRequestException-style validation error instead of silently accepting a past or immediate deadline.
What / where
CreateShipmentInput.deliveryDeadlineAtinsrc/shipments/dto/shipment.dto.ts(line 47) is only validated with@IsDate():There is no check anywhere — in the DTO or in
ShipmentsService.create(src/shipments/shipments.service.ts, lines 13-38) — that this date is in the future relative tonow().Why it's a problem
createShipment(input: { ..., deliveryDeadlineAt: "2020-01-01T00:00:00Z" })is accepted as a perfectly valid shipment:@IsDate()only checks that the value parses to aDateinstance, not that it's a sensible one. A sender can create (and, per theopenShipmentsquery, publicly list for any carrier to accept) a shipment whose delivery deadline has already passed, or that's a second in the future, with no server-side rejection. SinceROADMAP.mdnotes that delivery-deadline-based reminder/expiry jobs are planned (ScheduleModuleis already wired intosrc/app.module.tsfor this), a bad-data shipment like this would be immediately "overdue" from the moment those jobs ship, and today it just silently sits in theopenShipmentslist misleading carriers about a job that can't realistically be fulfilled in time.Suggested fix
Add a
class-validatorcheck thatdeliveryDeadlineAtis after the current time, e.g. a@MinDate(() => new Date())decorator (or a small custom validator, sinceMinDateneeds a fixed/callable reference), returning a clearBadRequestException-style validation error instead of silently accepting a past or immediate deadline.