fix: replace weather api provider

[Mediano4e]

Fix WeatherAgent: Replace deprecated geocoding API and improve error handling

Summary:
Fixes the WeatherAgent which stopped working due to geocode.maps.co API requiring an API key. Replaced with free Nominatim API and improved error handling, URL encoding, and logging.

Key changes:

• Replace geocode.maps.co with nominatim.openstreetmap.org
• Add required User-Agent header for Nominatim
• Implement URL encoding for city names with spaces/special characters
• Add request timeouts (10s)
• Improve error handling with specific exception types
• Optimize logging (remove redundant logs, fix log levels)

Tested with Russian and English city names, including cities with spaces.

---

Important

Replace deprecated geocoding API in WeatherAgent.py with Nominatim API, improve error handling, and optimize logging.

• API Replacement:
  • Replace geocode.maps.co with nominatim.openstreetmap.org in get_weather().
  • Add User-Agent header for Nominatim requests.
• Error Handling:
  • Add URL encoding for city names in get_weather().
  • Add request timeouts (10s) in get_weather().
  • Improve error handling with specific exceptions in run() and get_weather().
• Logging:
  • Optimize logging by removing redundant logs and fixing log levels in run() and get_weather().

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

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 4a77ba7 in 2 minutes and 4 seconds. Click for details.

• Reviewed 123 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 3 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. problem-solver/py/modules/messageProcessingModule/WeatherAgent.py:57

• Draft comment:
  Consider logging at a debug level (or with additional context) when check_connector fails, rather than silently returning OK. This can aid in troubleshooting why a message was skipped.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 15% vs. threshold = 50% The diff shows that a logging statement was explicitly removed from this location. The comment is suggesting to add logging back, which contradicts the author's intentional removal of the log statement. The author likely removed this log because it was too noisy or not useful - the message not being about weather is a normal control flow case, not an error condition. The comment is asking the author to reconsider a deliberate change they made. According to the rules, I should not make comments that ask the author to confirm their intention or that are speculative. This comment is essentially questioning the author's decision to remove the logging, which seems to violate the principle of not asking the author to double-check things or confirm their intention. However, the comment could be seen as a code quality suggestion about logging practices. If this is a legitimate case where logging would help with debugging, it might be a valid suggestion. The comment is actionable and specific about what to do (add debug-level logging). While it's actionable, the author explicitly removed this logging statement in the diff, which suggests they intentionally decided it wasn't needed. The comment is essentially asking them to reconsider or justify their change. This falls under "asking the author to confirm their intention" or "double-check things", which the rules explicitly prohibit. The fact that the message isn't about weather is a normal control flow case, not an error condition that needs logging. This comment should be deleted. The author intentionally removed the logging statement at this location, and the comment is asking them to reconsider that decision. This violates the rule against asking authors to confirm their intention or double-check their changes. The case where a message isn't about weather is normal control flow, not an error condition.

2. problem-solver/py/modules/messageProcessingModule/WeatherAgent.py:122

• Draft comment:
  Ensure that the values passed to quote() are strings. If entity_idtf or country might ever be non-string, it could lead to unexpected behavior.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. problem-solver/py/modules/messageProcessingModule/WeatherAgent.py:144

• Draft comment:
  The exception handling in get_weather is comprehensive, but re-raising exceptions without additional context might hinder upstream debugging. Consider wrapping errors with contextual information or using custom exceptions.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

Workflow ID: wflow_492gAt3uFkGB4Hxy

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