Fix model info readiness check and trim text content

[Dazlarus]

Replaces method call with property access for model_info_service readiness check in main.py. Also ensures text content is stripped of whitespace before appending in AntigravityProvider, improving data consistency.

Basically just some bug fixes for minor issues I had getting the proxy to serve Antigravity generally and to produce more than "Thinking" messages

---

Important

Fix readiness check in main.py and trim text content in antigravity_provider.py for improved data consistency.

• Behavior:
  • Replace method call is_ready() with property access is_ready for model_info_service readiness check in main.py.
  • Ensure text content is stripped of whitespace before appending in AntigravityProvider in antigravity_provider.py.
• Misc:
  • Minor bug fixes to improve proxy serving and message generation.

^{This description was created by for bf2439b. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to bf2439b in 1 minute and 49 seconds. Click for details.

• Reviewed 36 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/proxy_app/main.py:954

• Draft comment:
  Changed readiness check to property access. Confirm that 'is_ready' is now a property.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. src/rotator_library/providers/antigravity_provider.py:1015

• Draft comment:
  Trim whitespace before appending text parts to improve consistency. Consider caching the trimmed value to avoid duplicate calls.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is about a code quality improvement - avoiding duplicate .strip() calls. The diff shows that the change introduced .strip() calls in both the condition and the value being appended. This is a valid observation about a minor inefficiency. However, I need to consider: 1) Is this a significant enough issue to warrant a comment? 2) Is it actionable? 3) Does it follow the rules about not making obvious or unimportant comments? The performance impact of calling .strip() twice on short strings is negligible. This feels like a nitpick that doesn't provide substantial value. The code is clear and readable as-is, and the optimization would add a local variable that might reduce readability slightly. While technically correct, this is a micro-optimization that has negligible performance impact. String .strip() operations on typical message content are extremely fast, and the readability cost of introducing intermediate variables might outweigh the benefit. This could be considered an "obvious or unimportant" comment per the rules. The comment does point to a real inefficiency in the code - calling .strip() twice is objectively wasteful. However, the performance impact is so minimal that it doesn't warrant a code change. The current code is more readable and maintainable than introducing cached variables. This falls under "unimportant" comments that should be avoided. This comment should be deleted. While it correctly identifies duplicate .strip() calls, the performance impact is negligible and the suggested optimization would reduce code readability without meaningful benefit. This is an unimportant micro-optimization that doesn't meet the threshold for a useful review comment.

Workflow ID: wflow_s7SZ3HKdN4Zr8bb4

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[mirrobot-agent]

Starting my review of the readiness check fix and text content trimming changes. I'll analyze the property vs method call change and the whitespace handling logic.

[mirrobot-agent]

Overall Assessment

This PR addresses two distinct issues: fixing a property access bug in main.py and improving text content handling in antigravity_provider.py. While the changes made are correct, the fix for the property access bug is incomplete.

What's working:

• The property vs method call fix at line 954 is correct (verified that is_ready is defined as a @property in model_info_service.py:633)
• The whitespace trimming in antigravity_provider.py is appropriate and prevents empty text parts from being created

Critical Issue:
Two additional instances of the same is_ready() bug remain unfixed at lines 978 and 1088 in main.py. These locations have the same error pattern (calling is_ready() as a method instead of accessing it as a property) and will cause identical runtime failures.

• Line 978: In the get_model() endpoint
• Line 1088: In the cost_estimate() endpoint

Architectural Feedback

None - these are localized bug fixes with no architectural impact.

Key Suggestions

1. [BLOCKING] Fix the remaining is_ready() calls: Change lines 978 and 1088 from model_info_service.is_ready() to model_info_service.is_ready
2. After fixing, run a codebase-wide search for the pattern is_ready() to ensure no other instances exist
3. Consider adding a unit test that validates the is_ready property works correctly across all endpoints that use it

Questions for the Author

1. Did you encounter errors at all three locations or just at line 954? Understanding which endpoints triggered the error would help verify completeness.
2. Was there a specific test case or usage scenario that revealed this bug?

This review was generated by an AI assistant.

[Mirrowel]

I weren't notified i got PR's open, so i missed this completely.
I already fixed is_ready() in a hotfix. Gonna need to review the rest.

[Dazlarus]

Opening a NEW PR since I continued working on bugs and things and it has grown beyond the scope of this original PR