[Gilbert09]

Problem

• Cloudinary syncs of the usage table fail with a raw 400 Client Error: Bad Request for url: …/usage/<date> that tells the customer nothing they can act on.
• The refused date in these failures is the current UTC date, which the sync always requests last. Earlier days in the same run load fine.

Changes

• A 400 on the final (current) day now ends the usage sync cleanly instead of failing it.
• That day is not lost: the next run re-reads the restatement window, which includes it.
• A 400 on any earlier day still fails the sync, so a real request error still surfaces.

How did you test this code?

Test rationale: Added a parameterized case to TestCloudinaryUsage. It fails if a refused current day fails the run again, or if the fix starts swallowing a 400 on an earlier day. It fails on master.

Release status

• No feature flag controls this change

Docs update

• None.

🤖 Agent context

Autonomy: Fully autonomous

Agent: Claude Code, claude-opus-5-5

Skills: /writing-tests, /writing-code-comments, /writing-pr-descriptions

More context for AI agents

• Session: daily warehouse sync failure triage, PostHog Desktop task
• Decisions: skip only the final day on 400 rather than ending the window at yesterday, so today's partial usage still loads when Cloudinary answers.
• Read closely: fix(data-imports): retry cloudinary's non-standard 420 rate limit #126859 also edits iter_usage (420 retry hooks); the two touch adjacent lines and may need a trivial rebase.

---

Created with PostHog Desktop from a PostHog Desktop task

🤖 Generated with Claude Code

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[parameterai]

Risk: No findings

The change makes the Cloudinary usage sync end cleanly when Cloudinary refuses the current UTC date with a 400, instead of failing the whole run; any 400 on an earlier day still raises. I traced the request path (iter_usage → RESTClient.paginate → raise_for_status), the restatement-window math, and the resume-cursor state, and found no security impact: the swallowed branch is limited to day == end with a real 400 response, credentials still surface via 401/403, and the refused day is re-read on the next run because the watermark stays at the last loaded date.

_{Sentinel reviewed ca7f590 · Review settings}

[bill-ph]

Approved. Reviewed the PR description, diff, existing discussion, HTTP error propagation, resume checkpoints, usage restatement window, and regression test coverage at ca7f590. Checked correctness, security, data safety, performance, overengineering, and scope creep. Tests, builds, and linters were not run, as requested.

No issues found.

— Robo Bill v2 (gpt-6.1-sol, high reasoning)

[github-actions]

🤖 CI report

⚠️ Trunk lane — backend Python lane (py:product:warehouse_sources)

This PR is assigned to the backend Python lane (py:product:warehouse_sources). It runs backend Python tests and may merge in parallel with PRs in other lanes.

✅ Duplication (Python) — clean

New Python code duplication introduced by this branch. Fails at 70+ tokens in app code, or 150+ tokens when both copies live in test files. Advisory while the gate proves itself: extract a shared helper instead of copying.

✅ Duplication (TypeScript) — clean

New TypeScript code duplication introduced by this branch. Fails at 70+ tokens in app code, or 150+ tokens when both copies live in test files. Advisory while the gate proves itself: extract a shared helper instead of copying.

[stamphog]

Approved.

The ingestion change has owning-team authorship, STRONG familiarity, and a current-head approval. No substantive review concerns or other refusal grounds are present.

• Author wrote 100% of the modified lines and has 3 merged PRs in these paths (familiarity STRONG).
• PostHog Review (Standard) reviewed the current head: no findings.
• bill-ph reviewed the current head.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	25L, 1F substantive, 48L/2F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (48L, 2F, single-area, fix)
stamphog 2.6.1		.stamphog/policy.yml @ ca7f590 · reviewed head ca7f590

[hosthog]

HostHog preview — posthog-desktop-web

Latest build (ca7f590): https://33cfd6f4a6f0463aabe71ed187af6958.hosthog.dev

Employee-gated; every push gets a fresh URL whose content never changes. All previews stop serving when the PR closes.