feat(tasks): post agent thread updates for canvas creation and turn completion#70371
Conversation
|
Hey @k11kirky! 👋 It looks like your git author email on this PR isn't your
You can fix it for this repo with: git config user.email "you@posthog.com"Or set it globally with |
The canvas-created and turn-complete thread posts now come from the PostHog backend (PostHog/posthog#70371) so they land even when no client is open. This PR keeps only the rendering side: markdown [label](url) links in thread messages, and authorless messages shown as "Agent" with a robot avatar. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
…ompletion Canvas generation runs in the cloud, so thread announcements must come from the server, not a client that may be closed. On a canvas's first publish (attributed via the X-PostHog-Task-Id header the sandbox stamps on MCP calls), the generating task's thread gets an authorless "[name](link) has been created" message. On every end-of-turn the sandbox relay observes for a background channel-task run, the thread gets a turn-complete note @-mentioning the task creator. Both are gated on the project-bluebird flag and are best-effort. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
…ests The endpoint test lives outside the isolated tasks product, so it now loads Task/TaskThreadMessage via apps.get_model (the pattern test_folder_context_generation uses) instead of importing product internals. Renamed self.run to self.task_run since it shadowed TestCase.run. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
The turn-complete thread post now carries the agent's closing message instead of a static "Turn complete." The relay accumulates agent_message_chunk text and resets on a new tool call or user message, so end-of-turn holds the prose after the last tool call. Falls back to "Turn complete." when no text was captured (e.g. after a reconnect), and the facade caps oversized messages. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
k11kirky
force-pushed
the
posthog-code/agent-thread-updates
branch
from
c958286 to
dab7dc9
Compare
…tions Stacked on the ChannelFeedMessage PR: TaskThreadMessage gains author_kind/event/payload mirroring its shape. Agent rows are now author_kind=agent with a stable event key (canvas_created, turn_complete) and structured payload; turn_complete carries run_id so clients rendering live session-derived agent turns can dedupe against the durable row. Content keeps the rendered text so older clients degrade cleanly. Additive migration 0057 on posthog_task_thread_message (no external writers). Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
Types the new TaskThreadMessage fields from PostHog/posthog#70371 (stacked on #70320) and keys agent rendering on author_kind, keeping the authorless fallback for older backends. payload.run_id on turn_complete rows is the dedupe key for live session-derived agent turn views. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
The IDOR model-coverage repo check requires every team-scoped model to appear in the semgrep rule list; ChannelFeedMessage (introduced on the base branch this PR stacks on) was missing, failing repo checks and cancelling the rest of backend CI. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
…ntity The X-PostHog-Task-Id header only proved same-team membership, so a caller able to publish one canvas could name any same-team task and plant an agent-authored canvas_created message in its thread (flagged by review). The sandbox publishes with the task creator's credentials, so the facade now requires the attributed task to be created by the requesting user and drops the announcement otherwise. Generated-By: PostHog Code Task-Id: ea09a661-1f6d-4bd8-a046-24be60909d28
|
⏭️ Skipped snapshot commit because branch advanced to The new commit will trigger its own snapshot update workflow. If you expected this workflow to succeed: This can happen due to concurrent commits. To get a fresh workflow run, either:
|
🦔 Hogbox preview · ✅ ready▶ Open the preview
commit |
🤖 CI report✅ Bundle size — no changeUncompressed size of every built Total: 63.04 MiB · no change No file changed by more than 1000 B. Posted automatically by build-bundle-size-report · uncompressed bytes from dist-report ✅ Eager graph — within budgetHow much code each root ships on the eager path — downloaded and parsed before the surface is interactive. Measured from the esbuild output chunks (post-tree-shake, static imports only); lazy
🟢 Largest files eagerly shipped from
|
| Size | File |
|---|---|
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 24.6 KiB | ../node_modules/.pnpm/buffer@6.0.3/node_modules/buffer/index.js |
| 6.3 KiB | ../node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react.production.min.js |
| 4.5 KiB | ../node_modules/.pnpm/@jspm+core@2.1.0/node_modules/@jspm/core/nodelibs/browser/process.js |
| 3.9 KiB | ../node_modules/.pnpm/scheduler@0.23.2/node_modules/scheduler/cjs/scheduler.production.min.js |
| 1.4 KiB | ../node_modules/.pnpm/base64-js@1.5.1/node_modules/base64-js/index.js |
| 1.3 KiB | src/RootErrorBoundary.tsx |
| 912 B | ../node_modules/.pnpm/ieee754@1.2.1/node_modules/ieee754/index.js |
| 789 B | src/scenes/ChunkLoadErrorBoundary.tsx |
| 668 B | src/index.tsx |
Largest files eagerly shipped from src/scenes/AuthenticatedShell.tsx
| Size | File |
|---|---|
| 278.6 KiB | ../node_modules/.pnpm/posthog-js@1.399.2/node_modules/posthog-js/dist/rrweb.js |
| 266.9 KiB | ../node_modules/.pnpm/@posthog+icons@0.37.4_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js |
| 234.9 KiB | src/taxonomy/core-filter-definitions-by-group.json |
| 221.5 KiB | ../node_modules/.pnpm/posthog-js@1.399.2/node_modules/posthog-js/dist/module.js |
| 164.0 KiB | src/queries/validators.js |
| 154.3 KiB | ../node_modules/.pnpm/re2js@0.4.1/node_modules/re2js/build/index.esm.js |
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 105.9 KiB | src/lib/api.ts |
| 93.3 KiB | ../node_modules/.pnpm/prosemirror-view@1.40.1/node_modules/prosemirror-view/dist/index.js |
| 90.6 KiB | ../node_modules/.pnpm/@tiptap+core@3.20.6_@tiptap+pm@3.20.6/node_modules/@tiptap/core/dist/index.js |
Posted automatically by check-eager-graph · sizes are eager output bytes (shipped, post-tree-shake) from the esbuild metafile · part of #32479
⚠️ Dist folder size — 🔺 +10.5 KiB (+0.0%)
Total size of the built frontend/dist folder (all assets), compared against the base branch.
Total: 1267.34 MiB · 🔺 +10.5 KiB (+0.0%)
ℹ️ MCP UI apps size — 31 app(s), 15651.9 KB JS
Built size of each MCP UI app (main.js + styles.css).
| App | JS | CSS |
|---|---|---|
| debug | 577.8 KB | 177.4 KB |
| action | 429.2 KB | 177.4 KB |
| action-list | 542.6 KB | 177.4 KB |
| cohort | 428.2 KB | 177.4 KB |
| cohort-list | 541.6 KB | 177.4 KB |
| email-template | 428.1 KB | 177.4 KB |
| error-details | 443.9 KB | 177.4 KB |
| error-issue | 428.9 KB | 177.4 KB |
| error-issue-list | 542.5 KB | 177.4 KB |
| experiment | 539.9 KB | 177.4 KB |
| experiment-list | 543.4 KB | 177.4 KB |
| experiment-results | 541.6 KB | 177.4 KB |
| feature-flag | 545.4 KB | 177.4 KB |
| feature-flag-list | 549.1 KB | 177.4 KB |
| feature-flag-testing | 432.1 KB | 177.4 KB |
| insight-actors | 540.6 KB | 177.4 KB |
| invite-email-preview | 427.5 KB | 177.4 KB |
| llm-costs | 537.9 KB | 177.4 KB |
| session-recording | 429.9 KB | 177.4 KB |
| session-summary | 435.3 KB | 177.4 KB |
| survey | 429.7 KB | 177.4 KB |
| survey-global-stats | 540.7 KB | 177.4 KB |
| survey-list | 543.3 KB | 177.4 KB |
| survey-stats | 540.6 KB | 177.4 KB |
| trace-span | 428.6 KB | 177.4 KB |
| trace-span-list | 542.6 KB | 177.4 KB |
| workflow | 428.6 KB | 177.4 KB |
| workflow-list | 542.0 KB | 177.4 KB |
| query-results | 723.5 KB | 177.4 KB |
| render-ui | 613.8 KB | 177.4 KB |
| visual-review-snapshots | 433.0 KB | 177.4 KB |
![veria-ai[bot]](https://avatars.githubusercontent.com/in/1723776?s=60&v=4){kind=small}
| by the requesting user — the header can't point the announcement at someone | ||
| else's task thread. No header (a human or app save) means no announcement. | ||
| """ | ||
| raw_task_id = (request.headers.get("X-PostHog-Task-Id") or "").strip() |
There was a problem hiding this comment.
Medium: Agent announcements can be forged
X-PostHog-Task-Id is an ordinary caller-controlled header. Checking that the authenticated user created the task prevents writes to another user's task, but any team member can create a public-channel task and directly publish a canvas with this header, causing the server to insert an author_kind=agent announcement without any agent involvement. Require sandbox-authenticated context, such as a signed task claim or dedicated internal credential, before creating an agent-authored row.
PR overviewThis PR adds task-related agent thread updates, including posting announcements when a canvas is created and when a turn completes. The touched file-system publishing path now participates in creating these agent-authored task thread messages. There is one open security issue: the agent announcement path can currently be triggered with a caller-controlled task header, allowing a team member to forge an agent-authored canvas announcement in a task they created. This is an integrity and trust-boundary problem with a limited blast radius, since it affects task/thread messaging rather than direct data access or code execution. No issues have been addressed yet, so this should be tightened before merge by requiring a server-trusted agent or sandbox credential for agent-authored rows. Open issues (1)
Fixed/addressed: 0 · PR risk: 5/10 |
2 participants
Problem
When an agent builds a canvas from a channel's canvas mode, the task's thread stays empty. Teammates following the thread don't see that the canvas exists or that the agent finished. Canvas generation runs as a cloud task, so these updates have to come from the server side. Any client-side implementation only fires while the kicking-off laptop is open.
Note
Stacked on #70320 (channel feed messages) and aligned with its conventions:
TaskThreadMessagegainsauthor_kind/event/payload(same shape asChannelFeedMessage), so agent rows are explicit (author_kind: "agent") instead of implied by a null author, and structured.turn_completerows carrypayload.run_id— the dedupe key that lets a client already rendering a run's live session-derived agent turns suppress the durable row (or vice versa), fixing the double-display overlap with the live thread panel work. Human messages keepauthor_kind: "human"defaults;contentremains the rendered text so older clients degrade cleanly. Additive migration0057(no external writers of the table).Changes
Two authorless (agent) thread messages, both server-side, both gated on the
project-bluebirdflag evaluated for the task creator:publish_canvas(the endpoint behind thedesktop-file-system-canvas-partial-updateMCP tool) detects a first publish (no prior versions/code) and posts[Canvas name](canvas link) has been createdinto the publishing task's thread. The task is attributed via theX-PostHog-Task-Idheader the sandbox already stamps on every MCP call, validated against the team (same trust model as the signals product's task attribution). The link is the/code/canvas/<channel>/<id>web interstitial, usingmeta.channelIdwith a parent-folder fallback.relay_sandbox_events, which already detects end-of-turn server-side) posts@[Creator](email) <the agent's final turn message>into the thread for background runs of channel tasks. The relay accumulates the agent's message chunks and resets the buffer on each new tool call or user message, so what's posted is the closing prose after the last tool call (capped in length, with a plain "Turn complete." fallback when no text was captured). Interactive runs are excluded (they already dispatch awaiting-input pushes, and chat turns would spam the thread). A short Redis cooldown per run absorbs duplicate end-of-turn events from SSE reconnects, mirroring the push dispatcher.Supporting pieces: a
create agent thread messagewrite path in the tasks facade (author=None, mentions still indexed so the creator gets a mentions-feed entry), andformat_mention_tokeninmentions.pyas the serializer counterpart of the existing parser.Note
TaskThreadMessage.authorwas already nullable and the serializers already handle a null author, but nothing wrote authorless messages until now. The PostHog Code client renders these as agent messages (PostHog/code#3380).How did you test this code?
Automated tests only, I couldn't run them in this environment (no Postgres/Redis available), so CI is the arbiter:
products/tasks/backend/tests/test_thread_updates.py: turn-complete writes an authorless message with the exact mention token and indexes the creator's mention (catches breaking the token format or author attribution, which the client parses); the cooldown collapses duplicate end-of-turn events (catches removing the guard that prevents double posts on relay reconnect); flag-off / channel-less / creator-less tasks stay silent (catches thread spam for non-flagged users); canvas message content incl. bracket sanitization that would break the link token.posthog/api/file_system/test/test_canvas_publish.py: first publish with the task header announces once and a second publish doesn't (catches losing the first-publish detection); the parent-folder link fallback; a publish without task attribution stays silent (catches announcing human/app saves).ruff checkandruff formatpass on all touched files.Automatic notifications
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Created with PostHog Code