Fixed flaky comments test by pinning created_at#27434
Conversation
- `Returns flat list including replies by default` occasionally failed on CI because the parent and reply created by `dbFns.addCommentWithReplies` relied on the model's default `created_at` (`new Date()`). - The admin `browseAll` controller orders by `created_at desc` with no secondary tiebreak, so when both rows landed in the same millisecond MySQL returned them in insertion order (matching the snapshot), but when the reply spilled into a newer millisecond it came first and the snapshot broke. - Pinned explicit `created_at` values so the reply is deterministically newer than the parent, swapped the expected matcher array, and updated the snapshot to match the natural desc order.
WalkthroughThe test file for the comments API endpoint is updated to include explicit 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
created_at
|
no ref This is a test-only change. I think Claude Opus 4.7's explanation is reasonably good: > The test at `comments.test.js:1362` uses `dbFns.addCommentWithReplies` to create a parent comment and a reply back-to-back without explicit `created_at` values. Both rows rely on the model's default timestamp (`new Date()` at save time). > > The admin browseAll controller at `comments-controller.js:166` sorts by `created_at desc` and the SQL has no secondary tiebreak. When the two inserts land in the same millisecond, MySQL happens to return rows in insertion order (parent first, reply second), which matches the stored snapshot `[commentMatcher, commentMatcherWithParent]`. When the reply spills into a newer millisecond, `desc` puts the reply first — the snapshot then sees `parent` (reply's parent object) missing from index 1 and the assertion fails exactly as in the CI log.



no ref
This is a test-only change.
I think Claude Opus 4.7's explanation is reasonably good: