fix: update hardcoded year 2024 to 2025 in tests and popup #10210
Conversation
📝 WalkthroughWalkthroughThe changes update hardcoded date strings in two test files. In Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
✨ Finishing Touches
🧪 Generate unit 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
tests/unit/Utopia/Response/Filters/V18Test.php (1)
57-63: Consider generating the date dynamically to prevent future “hard-coded year” regressionsThis test keeps requiring manual updates each year. Instead of hard-coding
2025-07-13…, compute the timestamp relative to “now” so the intent (“some future date”) remains stable and you won’t need another PR next year.- 'scheduledAt' => '2025-07-13T09:00:00.000Z', + // Use a value 1 year in the future to keep the test evergreen + 'scheduledAt' => (new \DateTime('+1 year'))->format('Y-m-d\TH:i:s.v\Z'),This keeps the test behaviour identical while eliminating yearly maintenance noise.
tests/e2e/Services/Databases/DatabasesBase.php (1)
2641-2644: Consider switching to an unambiguous ISO-8601 literal for future‐proofnessThe hard-coded string has been bumped to 2025, which solves the immediate problem.
However thedd/mm/yyyy hh:mm:ssAMformat is locale-dependent and still rejected by the API (the test expects a 400).
Using an ISO-8601 example (1970-01-01T00:00:00Z) keeps the intent (“invalid for this attribute”) while avoiding maintenance churn the next time the year rolls.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
tests/e2e/Services/Databases/DatabasesBase.php(1 hunks)tests/unit/Utopia/Response/Filters/V18Test.php(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: scan
Security Scan Results for PRDocker Image Scan Results
Source Code Scan Results🎉 No vulnerabilities found! |
|
Hi 👋 Maintainers, kindly review my PR when you get time. Thank you! |
👟 Reproduction steps
Visit the https://cloud.appwrite.io/console/ with more than 2 projects.
A pop-up appears saying:
👍 Expected Behavior
It should say:
🔧 Fix Details
views)DatabasesBase.php,V18Test.php)registers.php)✅ Related Issue
Fixes appwrite/console#2157
Please let me know if there’s anything else to improve. 🙂