trunk-merge/pr-86299/6c87fc3d-a97f-4f83-bc79-0d5a26ed4c46 - #89649
Closed
trunk-io[bot] wants to merge 364 commits into
Closed
trunk-merge/pr-86299/6c87fc3d-a97f-4f83-bc79-0d5a26ed4c46#89649trunk-io[bot] wants to merge 364 commits into
trunk-io[bot] wants to merge 364 commits into
Conversation
Generated-By: PostHog Desktop Task-Id: 9e64274c-da99-4157-a0d9-336898627012
Generated-By: PostHog Desktop Task-Id: 9e64274c-da99-4157-a0d9-336898627012
Generated-By: PostHog Desktop Task-Id: 9e64274c-da99-4157-a0d9-336898627012
Generated-By: PostHog Desktop Task-Id: 9e64274c-da99-4157-a0d9-336898627012
`$mcp_tool_call` recorded that a skill was read but never which one, so per-skill usage was unanswerable and the skills product fell back on publish-recency and version churn as a proxy. Stamps `$mcp_skill_name` on `skill-get` and `skill-file-get` (and their `llma-skill-*` aliases), plus `$mcp_skill_body_offset` on the paginated body read so a paged continuation is not counted as a fresh load. Scoped to reads: writes already emit `llma skill *` from the skills API, and stamping them here would give two sources that disagree. Names are recorded only when they match the shape the store enforces at creation, following the value-free rule `execCommandAnalyticsProperties` already states, so agent-supplied text is dropped rather than echoed. Covers both dispatch modes. Single-exec carries arguments as JSON inside the command string, so `parseExecCallInnerArgs` reads them with the dispatcher's own parsers. Generated-By: PostHog Desktop Task-Id: 7a1545c3-8fc2-49bf-bf78-d2cfa6908a35
Generated-By: PostHog Desktop Task-Id: 9e64274c-da99-4157-a0d9-336898627012
Generated-By: PostHog Desktop Task-Id: 9e64274c-da99-4157-a0d9-336898627012
Opening /metrics showed a single centred spinner on an otherwise blank page until both rollup queries came back, so the wait read as a stall with no hint of what was coming. The status strip, the three stat cards, and the services table now render as placeholders sized to the real thing, so the page has its shape immediately and nothing moves when the numbers arrive. `OverviewStat` renders both states, and the card labels and column headers come from one list, so the loading layout cannot drift from the loaded one. Generated-By: PostHog Desktop Task-Id: 32c760da-5be2-4ce4-b74e-56309aa1a594
is_mcp_request only recognized personal API keys and OAuth tokens. ID-JAG (XAA) tokens are served from the same OAuth endpoint, carry scopes, and can reach the API through the MCP server, so a write on that pathway skipped the read-only cap. Adds them to the classifier, with a unit test over all three token types. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LEer2y9uGMkADPjMfWG8WK
Generated-By: PostHog Desktop Task-Id: ab2f1c37-3023-4f06-ab9d-d5ba99ac5b16
Every django shard in ci-backend.yml pays roughly 10 s of pytest collection building hypothesis's constants pool: hypothesis AST-parses every local module in sys.modules and caches the result under .hypothesis/constants, keyed by a hash of each source file. That directory is gitignored and was never cached, so each shard rebuilt the pool on every run. Restore the constants directory in every django shard and save it from one master Core shard per run. The key includes the installed hypothesis version and rotates weekly, and a prefix restore-key carries PRs until the first master save of a new week. Entries are content-addressed, so a stale restore is only ever a miss for changed sources, never stale data. Only .hypothesis/constants is cached: the example database under .hypothesis/examples picks which inputs property tests replay and must not travel across runs. The .depot shadow of ci-backend.yml mirrors both steps and notes the one delta: its master runs skip the test matrices, so its save stays dormant until a master dispatch. Measured on the Core collect targets ci-backend uses: cold 31.9 s vs warm 22.4 s collect-only over 31,707 tests. Created with Autoresearch. Generated-By: PostHog Desktop Task-Id: 4f0a3130-0f08-4a15-b57e-15be4e71bca8
The button summarized recordings by counting them per variant and letting the LLM reason over metadata. It never watched a recording. The player now offers an inline Replay vision scan, which does. Removes the button, its Max tool, and the never-created feature flag branch that gated a second unreachable code path. Generated-By: PostHog Desktop Task-Id: 2125706e-58c5-4d31-8c6a-db5015f40291
Removing the session replay tool left the experiment summary flag as the only thing that varies this toolkit, and neither branch was asserted. Generated-By: PostHog Desktop Task-Id: 2125706e-58c5-4d31-8c6a-db5015f40291
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Person-property and account-property projection lookups now retry once on a transient app-DB connection drop (OperationalError/InterfaceError), reusing the existing aretry_on_db_connection_drop helper. Previously a stale pooled connection propagated straight to materialize_view.py's catch-all, which reported it to error tracking and silently skipped that run's property sync. Generated-By: PostHog Desktop Task-Id: f08526a4-2e19-4806-940c-1c228471fac4
Generated-By: PostHog Desktop Task-Id: f1ac2634-4ae4-4683-92b3-54e332b641bc
Generated-By: PostHog Desktop Task-Id: f1ac2634-4ae4-4683-92b3-54e332b641bc
Adds INGESTION_TRANSPORT=http|grpc. On grpc, each worker gets one ordered WorkerIngest stream: enqueue order is wire order is the worker's feed order, closing the reordering window concurrent HTTP requests leave open. Sends become two-phase on both transports: begin_send establishes send order synchronously where order is decided (the consumer loop after assignment, the serialized flush paths, the eager loop) and wait resolves like an HTTP response. HTTP implements begin_send lazily, so its behavior is unchanged. A nack, stream break, or connect failure fences the lane: every un-acked and queued sub-batch resolves as failed in enqueue order with its messages, so the existing deferral path stashes them, holds all newer work for those keys, and retries the failed group first. Lanes reconnect with backoff and a bumped stream_epoch; rebalances bump assignment_epoch — both scope the worker's feed-order sentinel.
The stream has no per-send timeout, so a worker that stops acking (saturated, wedged, half-dead network) left un-acked sub-batches waiting forever and wedged the whole consumer — the failure mode HTTP surfaced as a request timeout. A watchdog now fences the lane when un-acked work sees no ack for INGESTION_LANE_ACK_TIMEOUT_MS (default 60s): everything outstanding fails back into the deferral path in order and re-routes. The deadline advances on every ack, so a slow-but-progressing worker is never fenced.
… mode Adds GrpcPort::OffsetFromHttp (each worker's stream address is its HTTP port plus an offset, INGESTION_WORKER_GRPC_PORT_OFFSET) so single-host setups — the e2e harness and local dev — can address many workers on one IP. The e2e FakeWorker now serves WorkerIngest on its HTTP port + 1, and two e2e scenarios run the full Kafka → lane → ack → commit loop over gRPC: per-distinct_id ordering, and a nacking worker fencing its lane and rerouting in order.
…m setup The worker now greets each stream with a reserved seq-0 ack to flush response headers (see the worker-side fix); the lane ignores it instead of fencing on an unknown seq. Connect and stream-open are now bounded by the lane ack timeout — a worker that never greets (or a non-h2 endpoint that accepts TCP) fences and re-routes instead of hanging the lane forever, which is how production wedged. Lane logs carry the dialed grpc_url so a wrong address is a one-line diagnosis.
Add SUB_BATCH_STATUS_BUSY so a worker can signal transient backpressure distinctly from a failure. Adding an enum value is backward compatible; a consumer that predates it treats the value as unknown. Regenerate the Node stub, which CI requires to stay in sync with the proto.
Two lane-failure fixes on the gRPC transport: Reaping a worker aborted its lane task, dropping any in-flight sends unresolved. The reaper removes workers on the drain timeout whether or not they still have work, so this lost sub-batches and forced the consumer to crash and replay. Drop the lane instead: closing the queue makes the runner fence the tail in order with the messages intact, the same recovery path every other fence uses. A busy ack (SUB_BATCH_STATUS_BUSY, or any status this consumer predates) now fences as retriable backpressure rather than a fault, so the work re-routes without counting the worker unhealthy and the metric records busy instead of error. A FAILED ack still fences as a hard fault.
The worker greets each stream with a StreamReady frame and acks with SubBatchAck inside a oneof, so lanes unwrap the frame before matching on status.
…nds fail Only busy signals (HTTP 503, busy lane) are backpressure. Connection errors and 5xx are retriable too, but they are worker faults and must still count against passive health.
Share one readiness helper between the HTTP and gRPC transports. Probes carry a 5s timeout, run concurrently, and shutdown wins over a round in progress, so a worker that accepts but never answers cannot stall startup or SIGTERM.
A worker that fails sends while its readiness probe passes must degrade through passive health; the retriable-vs-fault classification at the consumer's send sites had no test.
ingestion-consumer now depends on ingestion-worker-proto, whose build script runs protoc.
Contributor
🤖 CI report
|
trunk-io
Bot
deleted the
trunk-merge/pr-86299/6c87fc3d-a97f-4f83-bc79-0d5a26ed4c46
branch
August 26, 2026 19:11
Author
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request was created and is being managed by Trunk Merge.
This pull request is based on the master branch at SHA c86295e66bcb7a647de548d8ff2765f62a5f1dd0.
See more details about each PR in the batch here:
When CI completes, this pull request will be closed automatically.
Pull Requests Being Tested
This pull request is testing a batch with the changes from pull requests 86299 and 88699 - batching documentation.
Dependencies
This pull request depends on the changes from pull requests 83910, 87138, 88886, 89624, and 88862.