chore: handle unknown commit date in version

[Strift]

Pull Request

This PR improves the handling of the commitDate field from Meilisearch's /version endpoint.

It appears commitDate can be the string "unknown" instead of a timestamp, which can cause parsing errors. This change adds robustness by handling "unknown", null, or other unparsable values, ensuring the application remains stable.

This fixes failing tests that can be seen here: https://github.com/meilisearch/meilisearch-php/actions/runs/19986589382/job/57321426973?pr=835

PR checklist

Please check if your PR fulfills the following requirements:

• Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
• Have you read the contributing guidelines?
• Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Summary by CodeRabbit

• Bug Fixes
  • The commit date field now gracefully handles cases where the date is unavailable or invalid, returning null instead of causing errors.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This change updates the Version contract to make the commitDate parameter and return type nullable, changing from \DateTimeImmutable to ?\DateTimeImmutable. A test case is added to verify handling of invalid commit date values during array-to-object construction.

Changes

Cohort / File(s)	Change Summary
Version contract type signatures src/Contracts/Version.php	Constructor parameter and getCommitDate() return type changed from non-nullable to nullable ?\DateTimeImmutable
Version tests tests/Contracts/VersionTest.php	New test case testFromArrayWithUnknownCommitDate() added to verify null assignment when invalid commit date value ("unknown") is provided

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Review public API signature changes for backward compatibility implications
• Verify test case correctly handles the invalid/unknown commit date scenario

Possibly related PRs

• Add typed Version object #821: Introduced non-nullable DateTimeImmutable commitDate in the Version contract; this PR reverses that by making it nullable

Suggested labels

enhancement, breaking-change

Poem

🐰 A date may vanish, slip away,
Nullable now, no need to fray,
When "unknown" comes to call,
Null gracefully handles it all!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: making commitDate nullable to handle unknown values from the Meilisearch /version endpoint.

✨ 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 chore/fix-version-tests

---

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: 0

🧹 Nitpick comments (1)

src/Contracts/Version.php (1)

45-56: Consider hardening fromArray() against non‑string or malformed commitDate values

Right now, fromArray() gracefully handles the literal 'unknown', but any other unexpected value (e.g. null, empty string, or a badly formatted date) will still be passed to new \DateTimeImmutable(...) and can throw, which seems slightly at odds with the PR goal of being robust to “unknown or unparsable” dates.

If the upstream /version endpoint might ever return null or an invalid string, you could defensively treat such cases as “unknown” and keep $commitDate at null, for example:

     public static function fromArray(array $data): Version
     {
-        $commitDate = null;
-        if ('unknown' !== $data['commitDate']) {
-            $commitDate = new \DateTimeImmutable($data['commitDate']);
-        }
+        $commitDate = null;
+        $rawCommitDate = $data['commitDate'] ?? null;
+
+        if (is_string($rawCommitDate) && $rawCommitDate !== 'unknown' && $rawCommitDate !== '') {
+            try {
+                $commitDate = new \DateTimeImmutable($rawCommitDate);
+            } catch (\Exception) {
+                // Leave $commitDate as null if parsing fails.
+            }
+        }
@@
         return new self(
             $data['commitSha'],
             $commitDate,
             $data['pkgVersion'],
         );

This keeps the happy path unchanged while avoiding hard failures if the API ever sends null or a malformed date. If the Meilisearch contract strictly guarantees only ISO timestamps or 'unknown', the current implementation is fine, but this tweak would make it future‑proof.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 565bca2 and 77e1fe7.

📒 Files selected for processing (2)

• src/Contracts/Version.php (3 hunks)
• tests/Contracts/VersionTest.php (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

tests/Contracts/VersionTest.php (1)

src/Contracts/Version.php (3)

• Version (7-58)
• fromArray (45-57)
• getCommitDate (28-31)

🔇 Additional comments (2)

tests/Contracts/VersionTest.php (1)

38-49: New test correctly exercises the 'unknown' commitDate path

This test cleanly verifies that Version::fromArray() maps a 'unknown' commitDate to null while keeping commitSha and pkgVersion intact; assertion choices and structure look good and consistent with existing tests.

src/Contracts/Version.php (1)

13-31: Nullability change for commitDate looks consistent with intended behavior

Making the commitDate property and getCommitDate() return type nullable aligns with the new "unknown" case and the added test. Existing callers that already treat the commit date as optional will work as-is; others will now get static-analysis hints to handle null, which matches the reality of the upstream API.