fix: add type guards when rendering env progression dates#1030
fix: add type guards when rendering env progression dates#1030adityachoudhari26 merged 1 commit intomainfrom
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 11 minutes and 44 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 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 |
There was a problem hiding this comment.
Pull request overview
Fixes a UI crash in the deployments view environment dialog by adding guards around rendering “time since” / “time until” strings when date values may be null or invalid.
Changes:
- Added
safeFormatDistanceToNowStrictto safely handleDate | string | null | undefinedvalues before callingdate-fns. - Refactored “Last success” and “re-check in …” rendering into dedicated components that return
nullwhen formatting can’t be performed. - Updated the environment progression row/card rendering to use the guarded formatting paths.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| {formatDistanceToNowStrict(new Date(rule.nextEvaluationAt))} | ||
| </span> | ||
| )} | ||
| {!allPassed && <NextEvaluationLine {...rule} />} |
There was a problem hiding this comment.
<NextEvaluationLine {...rule} /> spreads the entire RuleEvaluation object into a component that only needs nextEvaluationAt. This increases coupling (the component becomes implicitly dependent on RuleEvaluation’s shape) and can mask future prop name collisions. Pass nextEvaluationAt={rule.nextEvaluationAt} explicitly (and consider typing the prop as RuleEvaluation["nextEvaluationAt"] to keep it in sync).
| {!allPassed && <NextEvaluationLine {...rule} />} | |
| {!allPassed && ( | |
| <NextEvaluationLine nextEvaluationAt={rule.nextEvaluationAt} /> | |
| )} |
fixes #1025