Skip to content

fix: flush analytics once a batch's worth of bytes is queued - #986

Merged
turnipdabeets merged 2 commits into
feat/v4-capture-v1from
fix/v4-analytics-byte-flush
Oct 28, 2026
Merged

turnipdabeets merged 2 commits into
feat/v4-capture-v1from
fix/v4-analytics-byte-flush

Conversation

@turnipdabeets

Copy link
Copy Markdown
Contributor

💡 Motivation and Context

Follow-up to #938, from the review bot's comment.

PostHogQueue.flushIfOverThreshold() flushes early once fileQueue.byteCount reaches endpoint.maxBatchBytes (5 MiB for analytics). But PostHogFileBackedQueue only tracked byteCount when it had a disk byte cap (maxBytes, from maxQueueBytes), and only the AI endpoint sets one. For analytics byteCount stayed 0, so the early flush never fired, and large events waited for flushAt or the flush timer.

What changed:

  • PostHogFileBackedQueue takes a new trackBytes flag. It tracks file sizes when trackBytes or maxBytes is set. Eviction still happens only when maxBytes is set, as before.
  • PostHogQueue passes trackBytes: endpoint.maxBatchBytes != nil, so analytics counts bytes but still has no disk byte cap.

No new changeset: this is an unreleased 4.0 fix, and the existing .changeset/v4-capture-v1.md on #938 already describes the 5 MiB analytics batches.

💚 How did you test it?

  • New test flushesAtByteLimit (Capture V1 queue suite): three ~2 MiB analytics events, flushAt = 100, queue not started (no timer), no manual flush. With the fix the queue drains. Without the fix it fails: queue.depth → 3, no requests sent after 10 s.
  • New test tracksBytesWithoutLimit (file-backed queue alignment suite): byteCount is tracked with trackBytes and no maxBytes, survives a reload from disk, decreases on pop, and nothing is evicted.
  • swift test --no-parallel -Xswiftc -DTESTING --filter 'PostHogQueueTest|PostHogCaptureV1|PostHogFileBackedQueue': 109 tests in 9 suites passed twice in a row. A third run had failures in FileBackedQueue Concurrency Tests, but only while another local session was running the same test bundle against the shared Application Support directory. That suite doesn't use byte tracking.
  • make lint: no new warnings. Didn't run make buildSdk because xcpretty isn't installed locally.

📝 Checklist

  • All commits are signed (see Commit signing)
  • I reviewed the submitted code.
  • I added tests to verify the changes.
  • I updated the docs if needed.
  • No breaking change or entry added to the changelog.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Built with Claude Code. I used a separate trackBytes flag instead of giving analytics a maxQueueBytes cap, so analytics doesn't get byte-based eviction it never had.

🤖 Generated with Claude Code

The early flush at maxBatchBytes read the file queue's byteCount, which was
only tracked when a disk byte cap (maxQueueBytes) was set. Analytics has a
batch byte limit but no disk cap, so byteCount stayed 0 and large events
waited for flushAt or the timer. Track file sizes whenever the endpoint has
a batch byte limit, without adding eviction.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@turnipdabeets turnipdabeets self-assigned this Oct 28, 2026
@turnipdabeets
turnipdabeets requested a review from a team as a code owner October 28, 2026 16:07

@dustinbyrne dustinbyrne left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Byte tracking remains separate from eviction, and the added analytics-factory and accounting regression tests cover the intended behavior. No actionable findings.

AI-assisted review.

The base already landed the same byte-tracking fix (9c1565b), so take its
PostHogFileBackedQueue/PostHogQueue versions and keep only this branch's extra tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@turnipdabeets
turnipdabeets merged commit 68c96cb into feat/v4-capture-v1 Oct 28, 2026
41 checks passed
@turnipdabeets
turnipdabeets deleted the fix/v4-analytics-byte-flush branch October 28, 2026 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants