Add integration tests for /weather and /research endpoints

[Copilot]

Integration test suite probing both API endpoints across happy paths, edge cases, and documented behaviour boundaries — with assertions intentionally strict enough to surface quirks (silent 200s on bad input, wrong city data, timing violations, etc.).

Test coverage (api.integration.test.ts — 32 tests)

• Auth — missing/invalid X-API-Key must return non-200 on both endpoints
• Weather happy path — 200, non-empty JSON, contains weather keywords, body references the requested city by name
• Weather case sensitivity — london / London / LONDON all resolve and reference the city
• Weather edge cases — fake city, empty string, missing param, numeric string, non-ASCII (Zürich), SQL injection, consecutive calls must both cite the city
• Research happy path — 200, non-empty JSON, response contains topic-relevant keywords
• Research timing — response takes ≥ 3 000 ms (documented min) and ≤ 10 000 ms (documented 8 s + 2 s headroom); upper bound is expected to surface violations
• Research edge cases — empty/missing topic, parallel same-topic calls (idempotency), different topics must differ, obscure topic, SQL injection

Key design choices

All 32 tests run unconditionally. vitest.config.ts global timeout raised to 30 s to accommodate the slow research endpoint.

The city-reference and keyword-relevance assertions are the primary quirk detectors — a response that returns 200 with data about the wrong city, or research that ignores the topic, will fail here.

[SynthLuvr]

@copilot now that there are 11 tests failing, summarize the quirks of the API endpoints identifying the problems and how it differs from expectations

[Copilot]

@copilot now that there are 11 tests failing, summarize the quirks of the API endpoints identifying the problems and how it differs from expectations

Here are the 11 failing tests and the quirks they expose:

---

API Quirks Found

1. Rate limiting — no documentation, 200 status, data: null body

Failing tests (5):

• response references the requested city (London)
• city with spaces (New York) returns 200 with data → response references the multi-word city (New York)
• consecutive calls for same city return consistent responses (Tokyo)
• two requests for the same topic return consistent responses
• different topics return different content

Quirk: The API has an undocumented rate limit. When exceeded it returns HTTP 200 (not 429) with this JSON body:

{"status":"throttled","message":"rate limit exceeded. please wait.","retry_after_seconds":28,"data":null}

Problems with this behaviour:

• The HTTP status code is 200 — clients cannot detect failure from the status alone.
• The data field is null rather than actual results — callers that don't inspect the body structure will silently consume empty data.
• retry_after_seconds is provided but the endpoint to retry is not specified.
• The field name casing is inconsistent: "rate limit exceeded. please wait." (lowercase) vs "Rate limit exceeded. please wait." (capitalised) appeared in different responses within the same test run.

---

2. /weather silently accepts invalid/empty locations

Failing tests (3):

• non-existent city returns a clear error (location: Qxzplorf99999)
• empty location string does not return weather data as if valid (location: "")
• numeric string as location returns an error (location: "12345")

Quirk: All three return HTTP 200 with what appears to be weather data — no error status, no error message in the body. The API does not validate the location parameter at all; it either fabricates plausible-sounding weather or returns data for an unrelated location rather than rejecting the request.

---

3. /research responses are not topic-relevant

Failing test (1):

• response contains content relevant to the researched topic (topic: solar energy)

Quirk: The response body does not contain any of the expected keywords (solar, energy, sun, panel, photovoltaic, renewable, electricity, power). The endpoint returns something but the content is not meaningfully related to the requested topic.

---

4. /research response time is faster than documented

Failing test (1):

• response time is at least 3 seconds (as documented)

Actual: 89 ms — far below the documented minimum of 3 seconds.

Quirk: The documentation states responses take 3–8 seconds ("simulating real-world scenarios like database queries or AI processing"), but at least some responses are near-instant. This could mean the API is serving cached/pre-computed results rather than doing real work, or the slow path is not always triggered.

---

5. /research accepts empty topic silently

Failing test (1):

• empty topic string does not return research data as if valid (topic: "")

Quirk: Passing topic="" returns HTTP 200 without any error. Like the weather endpoint, there is no input validation — an empty topic is treated as a valid request.

---

Summary table

Quirk	Endpoint(s)	Severity
Rate limit returns 200 instead of 429, body has data: null	Both	High
Error message casing is inconsistent between responses	Both	Low
Invalid/empty/numeric locations accepted silently (200 with data)	/weather	Medium
Empty topic accepted silently (200)	/research	Medium
Response content not relevant to requested topic	/research	High
Response time far below documented 3–8 s minimum (89 ms)	/research	Medium