Fixed ER_BAD_NULL_ERROR on published_at

[rmgpinto]

ref no-issue

• Seen in: https://ghost-foundation.sentry.io/issues/7272201684/?referrer=slack&notification_uuid=d037b4c9-d06c-421b-9b72-8053ec1affe5&environment=production&alert_rule_id=15548254&alert_type=issue
• When an incoming ActivityPub object (fetched via federation) has no published date, the code at post.service.ts:243 produced new Date('') an Invalid Date object. Since Invalid Date is not null/undefined, it passed through the ?? fallback in post.entity.ts:531 and reached MySQL as '0NaN-NaN-NaN NaN:NaN:NaN.NaN', causing ER_BAD_NULL_ERROR.

[coderabbitai]

Walkthrough

This change introduces validation logic for the publishedAt date field across multiple components. When a publishedAt value is missing or invalid, the code now defaults to the current date instead of potentially creating an Invalid Date object. The same pattern is applied consistently in the DTO mapping, entity creation, and service methods. A corresponding unit test file is added to verify that invalid and undefined publishedAt values are properly handled by creating valid Date instances.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically identifies the bug being fixed: an ER_BAD_NULL_ERROR related to the published_at field, which matches the core issue addressed across multiple files in the changeset.
Description check	✅ Passed	The description is directly related to the changeset, providing context about the root cause (Invalid Date from empty string), the error observed, and how the fix prevents Invalid Date values from reaching MySQL.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch nan-published-at

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/http/api/views/account.posts.view.ts`:
- Around line 744-746: The DTO mapping for publishedAt directly uses new
Date(object.published) when object.published is truthy, which can yield an
Invalid Date for truthy-but-unparseable strings; update the publishedAt
assignment (in the mapping that produces the API response in account.posts.view)
to mirror Post.createFromData's validation: attempt to parse/construct the Date,
check validity with isNaN(date.getTime()) (or Date.parse) and only use the
parsed Date when valid, otherwise fall back to a safe default (e.g., new Date()
or null) so the API never emits an Invalid Date.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Truthy-but-unparseable published values can still produce Invalid Date here.

Unlike Post.createFromData, this DTO mapping doesn't validate the result of new Date(object.published). If object.published is a non-empty but unparseable string (e.g. "not-a-date"), this will produce an Invalid Date in the API response.

Consider applying the same validation pattern used in the entity:

Suggested fix

-            publishedAt: object.published
-                ? new Date(object.published)
-                : new Date(),
+            publishedAt: object.published && !Number.isNaN(new Date(object.published).getTime())
+                ? new Date(object.published)
+                : new Date(),

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	publishedAt: object.published
	? new Date(object.published)
	: new Date(),
	publishedAt: object.published && !Number.isNaN(new Date(object.published).getTime())
	? new Date(object.published)
	: new Date(),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/http/api/views/account.posts.view.ts` around lines 744 - 746, The DTO
mapping for publishedAt directly uses new Date(object.published) when
object.published is truthy, which can yield an Invalid Date for
truthy-but-unparseable strings; update the publishedAt assignment (in the
mapping that produces the API response in account.posts.view) to mirror
Post.createFromData's validation: attempt to parse/construct the Date, check
validity with isNaN(date.getTime()) (or Date.parse) and only use the parsed Date
when valid, otherwise fall back to a safe default (e.g., new Date() or null) so
the API never emits an Invalid Date.