fix: to handle 429 responses more gracefully.

[chrisdoehring]

This pull request introduces improved handling and testing for API rate limits (HTTP 429) in the Ctrack Crystal integration, as well as several enhancements to the development environment and reliability. The main focus is on robustly managing rate limit responses, ensuring that retries are handled correctly, and that errors are surfaced and logged appropriately. Additionally, more comprehensive tests have been added, and the local development Docker setup has been improved.

API Rate Limit Handling and Error Management:

• Improved the _get_retry_after function in client.py to correctly parse both integer and HTTP-date Retry-After headers, enforce a minimum wait time, and avoid immediate retry storms.
• Updated all relevant action handlers (such as action_auth, action_pull_observations, action_trigger_fetch_vehicle_observations, and action_fetch_vehicle_trips in handlers.py) to catch CTCTooManyRequestsException, log warnings, and return clear error responses or propagate the exception as appropriate. [1] [2] [3] [4]

Testing Enhancements:

• Added and expanded tests in test_client.py and test_handlers.py to cover rate-limiting scenarios, including various Retry-After header formats and error propagation through the handler stack. [1] [2] [3] [4]
• Mocked asyncio.sleep in tests to avoid unnecessary delays when simulating backoff and retry logic. [1] [2]

Development and Docker Improvements:

• Added a web-ui service to docker-compose.yml for easier local frontend development, and improved healthchecks for faster and more reliable startup. [1] [2]

Dependency Updates:

• Added marshmallow to requirements.in to ensure necessary serialization/deserialization support.

Other Minor Improvements:

• Added missing imports and docstrings for clarity and maintainability. [1] [2] [3]

These changes collectively make the integration more robust against rate limits, improve observability and error handling, and enhance the local development experience.

[Copilot]

Pull request overview

This PR improves the Ctrack Crystal integration’s behavior under API rate limiting (HTTP 429), adds tests around those scenarios, and updates local development tooling (Docker + dependency compilation).

Changes:

• Enhance 429 retry behavior by parsing Retry-After (seconds and HTTP-date) and logging backoff attempts.
• Add/extend handler and client tests for 429 scenarios and mock asyncio.sleep to keep tests fast.
• Update local Docker Compose and dependency files (including adding marshmallow to integration deps and regenerating requirements.txt).

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
requirements.txt	Regenerated lockfile via uv, now includes dev/test dependencies.
requirements.in	Adds marshmallow constraint for integration-specific deps.
local/docker-compose.yml	Adds web-ui service, tweaks healthcheck, pins emulator platform.
app/actions/tests/test_handlers.py	Adds 429-focused handler tests.
app/actions/tests/test_client.py	Adds _get_retry_after tests and mocks sleep for 429 backoff.
app/actions/handlers.py	Adds 429 handling in actions, adds crontab schedule decorator, adjusts trigger behavior.
app/actions/client.py	Improves Retry-After parsing and adds 429 backoff logging.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new web-ui service build context points to ./web-ui relative to local/docker-compose.yml, but there is no local/web-ui directory in the repository. This will cause docker compose up to fail when it tries to build the service. Either add the missing directory/Dockerfile, or adjust/remove the service definition to reference an existing path/image.

Suggested change

	context: ./web-ui
	context: ../web-ui

[Copilot]

except Exception as e: ... raise e discards the original traceback context. Use a bare raise here to preserve the stack trace (and consider logger.exception(...) so the exception info is logged automatically).

Suggested change

	logger.error(f"Failed to process vehicles from integration ID {integration.id}, username: {auth_config.username}")
	raise e
	logger.exception(f"Failed to process vehicles from integration ID {integration.id}, username: {auth_config.username}")
	raise