trunk-merge/pr-87812/dfc21132-c178-4244-a763-9ef4223c6c8e - #89651
Closed
trunk-io[bot] wants to merge 391 commits into
Closed
trunk-merge/pr-87812/dfc21132-c178-4244-a763-9ef4223c6c8e#89651trunk-io[bot] wants to merge 391 commits into
trunk-io[bot] wants to merge 391 commits into
Conversation
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.
Closes the backtick-quoted identifier after the dataset in get_columns's INFORMATION_SCHEMA.COLUMNS query, matching the pattern already used by get_primary_keys and get_leading_index_columns. Generated-By: PostHog Desktop Task-Id: 5863a1af-274e-410a-8f01-dd6947ed6958
…line The ack-progress watchdog used a single per-lane deadline that every OK ack reset. With more than one un-acked sub-batch, a worker that kept acking newer sub-batches but never the oldest pushed that deadline forward on each ack, so the stuck send never timed out and its Kafka batch never completed. Give each ledger entry its own deadline, armed when the sub-batch goes on the wire, and key the watchdog on the oldest (front) entry. A stuck sub-batch now fences on its own deadline even while its siblings keep acking, restoring the per-send bound the HTTP timeout it replaces provided. Adds a regression test: with the un-acked cap at 2 and a worker that acks every sub-batch except the oldest, the stuck send fences on its own deadline while a steady sibling feed continues. Generated-By: PostHog Desktop Task-Id: fd156565-dd05-4c89-8613-e97b82f92d59
The isolation skill told core test fixtures that need product rows to reach the model with apps.get_model at module scope plus a TYPE_CHECKING import, because tach ignores type-only imports. That is the same dependency with the import edge removed, not a testing door: tach, mypy and LSP stop seeing it, and snob does not select the test when the model changes, so the break lands on master instead of on the PR. The crossings scanner skips tests, which the docs read as permission for the pattern. Replace the recipe with the rule the scanner's own reasoning implies: seed product rows through the facade's write function or a product testing door, with a normal import. architecture.md and the scanner docstring say the same thing now. The two existing fixtures that use the pattern (InsightViewed, Account) are cleaned up separately.
The lane held its worker URL as a String and cloned it into the ack, ledger, and fence metric macros on the per-sub-batch and per-ack hot path, allocating a fresh String on every emission. Hold the URL as an Arc<str> so each clone is a single atomic increment, per the rust/CLAUDE.md metrics-label convention. Log macros and the metric labels are unchanged. Generated-By: PostHog Desktop Task-Id: fd156565-dd05-4c89-8613-e97b82f92d59
… acks and late enqueues Two gaps let a routing key's newer messages reach the worker ahead of older ones once a lane fenced, both live at the deployed un-acked cap (INGESTION_WORKER_CONCURRENT_BATCHES above 1). A later sub-batch's OK ack resolved at once, so its caller released the key and never replayed it; when an earlier sub-batch then failed, only the older messages were stashed and replayed, after the newer ones. The lane now records acks in its ledger and resolves only the consecutive acked prefix, so a fence still reaches an acked-but-unresolved tail and replays it in order. A fence resolved its sends before their callers had stashed the messages. In that gap the consumer loop could still enqueue a fenced key's next group, and the next stream sent it ahead of the stashed older group. Each fenced send now carries a FenceGuard that the consumer drops right after defer_failed; the lane keeps fencing every arrival until all guards from the fence are dropped, then reconnects. Adds regression tests for both, and the out-of-order ack test now asserts that a later ack waits for the earlier seq.
Scaffold two user-requested data warehouse sources as hidden stubs (unreleasedSource=True): Lovable (AI app builder) and Zenchef (restaurant reservation and management). Each adds the ExternalDataSourceType enum value, the schema-general.ts entry, a registered stub source class, a generated config, an icon, and SOURCES.md/_load_all registration. No sync logic yet. Generated-By: PostHog Desktop Task-Id: 0bfebe03-9beb-4353-9c84-1a47342d591c
The generated Kea logic type unions in sourceCatalogLogic.ts and sourceWizardLogic.tsx were out of sync with the new source types added to schema-general.ts/schema.json. This regenerates them (kea-typegen output) so the "schema.json up to date" CI check passes.
The story renders null by design, and `#storybook-root` is `display: inline-block` in the snapshot runtime, so the target collapsed to zero size and every screenshot attempt timed out. Wrap the story in a sized frame, so the snapshot still covers the null branch: caption only today, and holding the trigger beside it if the staff gate ever regresses. Also name that cause in the test runner. Playwright reported only "element is not visible" after a full 10s wait, three retries over, for both themes. Generated-By: PostHog Desktop Task-Id: ba5e6ec4-e9f7-4be9-99c9-5be55d33488e
A team that wants their product to work with PostHog AI had no doc to read. `products/posthog_ai/README.md` covered only the skills build, and the one skill about the agent — `implementing-agent-modes` — taught the frozen LangGraph runtime, down to a feature-flag example calling a helper that no longer exists. The product README is now the integration guide: where PostHog AI renders, why there is no backend integration API, and the frontend seams a team actually uses — attaching context, injecting trusted instructions, reacting to the agent's tool calls, and registering tool cards. Every snippet is copied from a real caller. The run primitives are documented as an exit hatch, not a default. `/integrating-with-posthog-ai` is the matching skill, routing to the right seam with a reference per seam for the detail and the gotchas. The skills-build docs move to `products/posthog_ai/skills/README.md`, which also gains the `sync:skill` commands the old text was missing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QN7YNd72fuG58XAwELsENt
Cuts the frontmatter description to the trigger cases, since a long one costs every other skill's chance of firing. Marks the four product seams as recommended in the decision table, and adds the run primitives as a fifth row marked not recommended, so an agent sees the escape hatch and its status in the same place. Leads the instructions row with steering, which is what teams reach for it to do. Names the two things worth putting in trusted context: your MCP tool names, and your skills from `products/*/skills/`. Traces the generator that makes both safe, `services/mcp/scripts/build-scene-tool-context.ts`, and says how to add a product to its config. Corrects the count of run-primitive consumers from two to three, and reframes the split as hosting a run against cooperating with one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QN7YNd72fuG58XAwELsENt
… person processing on
6 updated Run: 7a6adff2-3398-441f-9b41-3c4551f14c50 Co-authored-by: skoob13 <13541795+skoob13@users.noreply.github.com>
Reconciling the click was not enough on its own: a click that resolved to the filters already applied still wrote an equal filter group. In logs that reloaded the list, the patterns pivot and the group-by breakdown; in tracing it armed a deferred re-query that ran when the trace drawer closed. Both listeners now skip the write when nothing moved, and tracing keys its deferred-refresh flag on the write rather than on the action. The confirmation on a span attribute row now reads "Filter applied", which holds whether the click added the filter or found it already there. Also from the review pass: mergeSpanFilter uses the shared uniqueBy helper, builds its result in a plain loop instead of a map with a null sentinel, and points at its logs counterpart so the two stay findable. Generated-By: PostHog Desktop Task-Id: 096a2990-1b20-4160-8e4a-4189db59d479
Author
|
|
Contributor
🤖 CI report
|
trunk-io
Bot
deleted the
trunk-merge/pr-87812/dfc21132-c178-4244-a763-9ef4223c6c8e
branch
August 26, 2026 19:16
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 87812 and 89623 - batching documentation.
Dependencies
This pull request depends on the changes from pull requests 83910, 87138, 88886, 89624, 86299, 88862, 88699, 89410, and 88569.