test(e2e): bound date-only *_before filters at next-day start

[ilya-bogin-keenable]

Problem

test_acquired_before broke in the 2026-07-25 nightly on all three OS jobs, having passed the day before against the same CLI binary (v0.1.24). It wasn't a regression — the assertion was wrong all along.

A date-only cutoff on /v1/search is inclusive of that whole day, while a full timestamp cuts at the exact instant:

acquired_before=2026-05-01           → max acquired_at = 2026-05-01T14:31:13Z   (whole day kept)
acquired_before=2026-05-01T00:00:00Z → max acquired_at = 2026-04-30T02:44:51Z   (exact instant)
acquired_before=2026-03-15           → max acquired_at = 2026-03-15T08:52:01Z   (whole day kept)

The test asserted the exact-instant reading (<= utc(2026, 5, 1)), so it only passed while no same-day result happened to rank into the top 10. On 2026-07-25 https://ghacks.net/category/ai did, at 2026-05-01T14:31:13Z, and the assertion tripped.

Fix

Bound both *_before tests at the start of the next day, with a comment recording the whole-day semantics so the next reader doesn't tighten it back.

test_published_before had the identical flaw and would have failed on any result published during 2024-01-01 — fixed here too rather than left as a landmine.

Verification

Run 30158473043 on this branch: 2 failed, 88 passed, 3 skipped. Both test_acquired_before and test_published_before pass on ubuntu, macOS and Windows.

The two remaining failures are live API bugs, untouched by this PR and tracked separately:

• test_fetch_live — live=true returns 422 for every URL tried, while the cached path returns 200 for the same URL. The --live flag shipped in v0.1.24 is unusable.
• test_dead_page — the API returns 422 where 404 belongs. The same 422, with the message "The page was reached but content could not be extracted", also comes back for a domain that doesn't resolve, so callers can't distinguish a dead link from a transient extraction failure.

Nightly e2e stays red until the live-fetch bug is fixed on the backend.

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Fix e2e date-only *_before filter assertions to bound at next-day start

🧪 Tests 🕐 Less than 10 minutes

AI Description

• Fix e2e assertions for date-only *_before filters to match whole-day inclusive API semantics.
• Bound acquired/published cutoffs at start of next UTC day to avoid same-day false failures.
• Document date-only vs timestamp cutoff behavior inline to prevent future regressions.

Diagram

graph TD
  T["e2e tests"] --> C["keenable-cli"] --> A{{"/v1/search"}} --> S["date-only cutoff semantics"]
  S --> B["assert < next-day 00:00Z"]

  subgraph Legend
    direction LR
    _t["Test"] ~~~ _svc["Client"] ~~~ _api{{"API"}} ~~~ _rule["Rule/Assertion"]
  end

Loading

High-Level Assessment

The approach is appropriate: these tests explicitly exercise date-only inputs, so the correct fix is to assert against the API’s whole-day-inclusive behavior (bound at next-day start) and document the semantics. Passing full timestamps would change the test’s intent (instant cutoff) rather than validating date-only behavior.

Files changed (1) +6 / -2

Tests (1) +6 / -2

test_search.pyFix date-only *_before assertions to use next-day exclusive bound +6/-2

Fix date-only *_before assertions to use next-day exclusive bound

• Updates acquired_before and published_before e2e assertions to bound results strictly before the next UTC day (e.g., < 2026-05-02) to match the API’s whole-day-inclusive semantics for date-only cutoffs. Adds comments explaining the date-only vs full-timestamp behavior to prevent reintroducing the incorrect instant-based assertion.

tests/e2e/test_search.py

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review