DottaandPaperclip
9e8a9f28d5
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Agents publish GitHub reviews through governed tools. > - GitHub can accept a publication before the caller receives its result. > - Exact retries must return the existing publication receipt. > - The gateway compared a shortened audit hash with a complete request hash. > - Long reviews therefore failed the retry check even when their content was unchanged. > - This pull request checks the complete saved publication and returns its current receipt. > - Agents can confirm their work without another provider write. ## Linked Issues or Issue Description Refs #16284, which added durable publication recovery. Refs #16275, which extended the GitHub tool deadline. **What happened?** An exact review retry returned an idempotency conflict after GitHub had published the review. The invocation hash uses an audit preview that shortens strings to 500 characters and arrays to 50 entries. The gateway compared that hash with the complete request hash. The earlier retry tests used short assessments. **Expected behavior** An unchanged request returns its durable receipt. Changed content, changed authority, or a missing publication must not cause another write. **Steps to reproduce** 1. Submit a review with a summary and rationale longer than 500 characters. 2. Let publication finish after a short caller deadline. 3. Repeat the exact request. Before this fix, the gateway returns an idempotency conflict. **Paperclip version or commit** Reproduced on master at `c5226daf7a37559ddc007446681717791d80a223`. ## What Changed - Use the durable publication's complete request check for GitHub retries. Keep run, agent, task, connection, tool, and current authority checks. - Return the saved receipt through normal gateway validation and bookkeeping. Leave pending provider work to the durable worker. - Refuse retries without a saved publication. Keep existing invocation keys and audit previews unchanged. - Cover long reviews, comments, progress updates, text suffix changes, nested coverage changes, pending receipts, missing publications, and revoked access. - Document the recovery contract and verification recipes. ## Verification - Red: both long-review receipt cases failed on unchanged production code with the expected idempotency conflict. - Green: all 144 GitHub review workflow tests passed on the final source. This includes long reviews, comments, progress updates, pending and missing receipts, revoked policy, and the native assigned-tool entry point. - Server and workspace typechecks passed. The production build passed. - Map checks passed. These are structural checks. - The first broad run found an incorrect new fixture assumption: its discovery query returned two review tools. The fixture now selects the exact submission tool. An existing description-edit polling test also timed out; it passed separately without a production change, then passed in the complete 144-test rerun. Both earlier failures remain recorded. - Final commit `7cdcdc3a1ac79cb4ed77510a32d795228e3315e8` passed all 55 CI checks. Two optional Storybook jobs were skipped. [Complete CI run](https://github.com/paperclipai/paperclip/actions/runs/39304187397). Greptile is 5/5 on this exact commit, with zero unresolved review threads. - The earlier local full-suite attempt was stopped after the fixture correction. The final local full-suite attempt was stopped after complete final-head CI passed. No complete local full-suite pass is claimed; full-suite acceptance uses the current-head CI matrix. - Provider responses are controlled fixtures. Native assigned-tool coverage uses the production gateway and disposable PostgreSQL. No live GitHub fault injection, deployment, or historical task recovery is claimed. ## Risks A pending receipt remains pending. It does not complete the task. Caller retries no longer dispatch provider work; the durable worker retains that responsibility. A missing durable publication returns a conflict because the gateway cannot establish the original write's outcome. Existing approval and revocation checks remain effective. No database migration or audit hash change is required. ## Model Used OpenAI GPT-6 through Codex, with reasoning, tool use, and code execution. The session does not expose a more specific serving model ID or context-window limit. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
11 KiB
navigation
| navigation | ||||||
|---|---|---|---|---|---|---|
|
External chat and email
People can talk to an assigned agent through configured external channels, bind their identity, exchange files, and inspect delivery state. Each provider has a different identity, threading, and attachment contract.
Implementation: endpoint setup, endpoint detail, email setup.
Agent access: companion.
Sub-features
providers: configure the available Slack, Discord, Microsoft Teams, Telegram, GitHub, AgentMail, and experimental iMessage Photon and Speko paths; availability still depends on gates and provider support.identity: link the external sender to the intended authorized Paperclip identity.conversation: route inbound messages to the selected agent and send replies to the correct thread.attachments: transfer supported files with inspectable delivery and failure states.lifecycle: inspect endpoint activity, repair auth, and disable delivery when required.
How to get to it (user POV)
external-thread
Message the configured bot/address from its external provider and follow the corresponding Paperclip conversation/task.
endpoint-management
Open /apps/chat/:endpointId/settings and the endpoint’s other available tabs; identity confirmation uses /chat-identity/confirm.
Driving it with Playwright and provider clients
Preconditions: follow the baseline. Use a
test provider account/channel with permission to send messages. Gates differ:
AgentMail bypasses the chat-connectors UI gate, GitHub uses
enableGitHubReviewBots, and other chat providers use enableChatConnectors.
Setup is covered in connection setup.
external-thread
Automated: channel integration uses provider fixtures; it does not prove a live Slack, Discord, Teams, Telegram, GitHub, email, or Photon delivery.
Manual: For each supported provider being changed, send a unique message, verify the intended agent/company receives it, and inspect the actual external reply in the original thread. Repeat with an unlinked/unauthorized sender, duplicate inbound delivery, and one supported attachment. Record provider-specific results separately.
For Slack, enable Require at-mention and Allow direct messages. Send a plain DM and follow up without a mention: both should reach the agent, with top-level replies to top-level DMs. Channel messages and thread replies still require a mention when that setting is enabled. Disable direct messages and confirm a plain DM is rejected. Use a private channel for threaded conversations.
For Slack acknowledgement latency, mention the bot with and without an attachment.
Eyes should appear after authorized task/comment persistence, independently of
file preparation, subscription and agent startup. Duplicate delivery must keep
one receipt; the final reply must remove only its source message's eyes. Record
live mention-to-reaction timing separately from the PostgreSQL fixture tests and
the chat.slack.receipt transport span described in Observability.
During a top-level DM run, verify that the bot adds eyes to the source message and removes them when the final reply arrives. The pinned Slack SDK encodes a linear DM with an empty thread timestamp; receipt transport accepts that address while still validating the channel and the source message timestamp.
For an agent with two linked Slack endpoints, compare assignment preparation and tool discovery in the run trace. Endpoint checks may overlap in pairs. Confirm that both permitted tool sets remain available, then revoke one linked identity and confirm that the next preparation excludes it. The database regression uses real PostgreSQL with one connection and controlled credential resolution; it does not prove live provider latency or an end-to-end response target.
Catalog discovery rechecks live authority and current credentials without computing the unused compatibility fingerprint. Assignment snapshots and governed calls retain full revision resolution. The same regression verifies identical catalog membership, absence of digest SQL during discovery, and revocation on the next preparation. A faster component is not proof of a faster Slack reaction or final reply; measure those separately on the deployed revision.
For GitHub and Slack tool continuity, start a task from the channel, then admit a later monitor or retry run for the same task. Check that the later run can discover and call its channel tools without a new inbound message. For GitHub, also continue from a board message by the same accepted requester and complete the review in the original conversation, including when the original source is recorded only in legacy wake metadata. Revoke the linked identity and check that the next call fails. Repeat the boundary checks with another task, agent, company, and requester. The channel and provenance fixtures above cover these contracts with synthetic providers; record a live journey separately. For a long-lived task, repeat more than 100 continuations and check that tool access remains available. Fail a later GitHub run after a final answer and check that the earlier answer remains intact.
endpoint-management
Automated: channel integration covers shared endpoint/delivery behavior; live credential repair and provider ownership remain manual checks.
Manual: Inspect the bound agent and identity, recent activity, and delivery failure details. Repair a disposable credential, retry a safe message when offered, and verify exactly one external reply. Disable the endpoint and confirm new traffic is not silently processed.
For publication failures, reject one operation with a provider 403 and verify that its failure remains visible while unrelated tools and publications continue. Repeat with an authentication failure: the endpoint must require attention and stop provider traffic, while the connection's enabled setting remains unchanged. Reconcile persistent receivers and restart the service; authentication failures must remain stopped while transient disconnections can still recover. The PostgreSQL suite uses controlled provider failures for these cases; live provider credential repair remains a separate acceptance check.
GitHub connections in attention or revoked state show a repair notice above the settings. Reconnect GitHub → Reconnect saved App checks the same App with stored credentials and repairs delivery. Replace App credentials is the fallback, with the saved App ID, a link to its GitHub settings, and PEM upload or paste instructions. The production management Storybook's 04 Recovery group covers these views, pending/failure/success, mobile, and light theme with simulated provider responses. Verify actual credential validity and restored delivery separately against GitHub; a Storybook success does not establish live recovery.
For GitHub, submit a disposable PR and verify the summary heading uses the bot's display name and the check remains Paperclip Review. For two separate bots on one PR, verify their App-scoped checks and comments remain independent.
For GitHub publication recovery, interrupt a response after GitHub accepts a write and verify one summary, finding, and App-scoped check. Retry the same tool call and verify it returns the saved receipt. Include text longer than 500 characters and coverage with more than 50 entries. Change only the text suffix or final coverage entry and verify rejection without another write. Remove the durable publication and verify that a retry cannot dispatch a new write. Leave a transient failure queued, restart the instance, and verify publication resumes at its saved deadline without another inbound message. Revoked access and permanent rejections must stop retries. These recipes are separate from live provider proof.
Configure optional project and workspace defaults at the connection and destination levels. Start a new conversation and inspect its task workspace. Verify that inheritance, an explicit selection, and clearing a default remain distinct. Changing defaults must not move an existing conversation or interrupt its run.
For experimental Speko, enable chat connectors, choose an agent during setup, and verify the provider credentials. On an assigned task, use Talk to agent to open browser voice controls. Check microphone denial, mute, end/restart, navigation during a call, and access revocation. Inspect transcripts and the connection's call history. Callback preferences, incoming phone configuration, and incoming-call approval are separate settings and authorization journeys. The voice components and fixture tests cover presentation; they do not establish live answer retrieval or telephone playback. Those provider outcomes remain explicit release gates.
Gotchas
-
Visibility flags do not pause existing delivery. Disable the disposable endpoint itself to test stopped traffic.
-
One provider’s passing fixture does not qualify another provider or live delivery.
-
An accepted send request does not prove the recipient received the message or file.
-
Use steering and questions for their channel-specific interaction checks.
Storybook verification
attachments
Scope: ui Storybook: Mount TaskChatBubble attachments and ChatEndpointDetail provider-specific consent/upload/delivery failure and unknown-outcome states. Local email attachment dialog remains a prototype. Production: Transfer a disposable supported file through each affected provider; verify recipient delivery, read scope, duplicate/replay handling and failure/unknown state without treating notification as file-upload proof. Sources: Source: TaskChatBubble.tsx, ChatEndpointDetail.tsx, chatEndpoints.ts, chat-channels.ts. Tests: TaskChatBubble.test.tsx, task-chat-attachments.test.ts, chat-channels.integration.test.ts, issue-attachment-routes.test.ts
Documentation scope: Chat and email channel setup
Shared recipes name provider checks; each provider transport/thread/identity/file-size/type combination needs separate live evidence and deeper instructions.