mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-11-03 01:27:09 +01:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Human messages start agent work through task, chat, and external-channel intake. > - Agent startup can delay the first visible response. > - A small direct model call can acknowledge the request while normal work starts. > - This response must remain separate from evidence that the agent answered or completed work. > - This pull request adds optional company-wide fast responses with durable receipts, access checks, and cost accounting. > - Users receive prompt acknowledgement without changing the agent execution path. ## Linked Issues or Issue Description **Subsystem affected** Cross-cutting: database, shared contracts, server orchestration, connections, and UI. **Problem or motivation** Users can wait for an agent to start before they receive a contextual response. Generic progress messages do not confirm what the user asked. An acknowledgement must not falsely complete work or satisfy an unanswered turn. **Proposed solution** Add a disabled-by-default experimental fast-response model using an existing shared API connection. Generate one short acknowledgement for each accepted human turn. Use the existing agent identity and external publication outboxes. Retain platform provenance and account for the inference independently. **Alternatives considered** Running the acknowledgement through the agent runtime adds startup latency. Restricting implementation to OpenRouter leaves other existing API connections unsupported. This change supports all existing API connections and uses OpenRouter for live verification. **Roadmap alignment** This extends existing agent communication and connection settings. ROADMAP.md and open pull requests were checked. No duplicate fast-response implementation was found. The maintainer supplied the feature plan directly. ## What Changed - Add Experimental fast responses to instance settings. Keep the feature off by default. Enforce the flag at intake, dispatch, and publication. - Move Decision model and Fast response setup to company Settings → Connections when the experiment is enabled. Place Connections below Environments. Separate the model sections with clear headings and a divider. Keep Decision model in General when the experiment is off. Route Costs setup links to the available settings page. - Make the acknowledgement prompt a multiline template string. Ask for a brief, positive response in the user’s language. - Add settings, connection/model selection, sponsorship, fixed-sample testing, and Costs history. - Add a Vercel AI SDK text service for existing native, routed, Bedrock, and local API connections. - Add durable per-turn requests, a bounded worker, a three-second admission deadline, and one inference attempt. - Integrate task creation, task and agent chat, steering, queued follow-ups, experimental board chat, shared chat intake, and email. - Preserve receipt provenance and exclude receipts from completion, recovery, interaction resolution, and agent wakeups. - Recheck authorization, source validity, real replies, budgets, and destination binding before publication. Preserve accounting for suppressed or uncertain outcomes. - Add provider contracts, database race tests, channel outbox tests, UI tests, Stories, and documentation. Keep decision-model execution unchanged. ## Verification - Local `pnpm -r typecheck`, `pnpm build`, and UI token gates pass after rebase. The UI typecheck and build also pass after the final navigation fixes. All 37 focused navigation tests pass. The first full local `pnpm test:run` invocation reported seven chat failures. All seven passed in isolated reruns after fixture updates and host cleanup. This invocation was stopped after the full final-head CI suite passed. - Initial local database tests hit macOS shared-memory exhaustion. A diagnostic confirmed `shmget: No space left on device` with the system limit of 32 IDs. Three abandoned, unattached PostgreSQL IPC headers were reclaimed. The isolated rerun passed all 31 fast-response and channel tests. The two additional Slack regression cases also passed in a separate rerun. No active database was stopped. - UI token gates pass. Provider contract tests cover all supported API connection types. Fast-response tests cover uniqueness, authorization, budgets, expiry, cancellation, restart, real-reply races, and the experimental flag. - The test drive verified that disabling the experiment hides Connections and redirects its direct URL. Enabling it restores the saved OpenRouter setup. After restart on the final commit, the OpenRouter settings sample returned “Sure, I’ll take care of fixing the border around the settings panel.” in 428 ms. It used 260 input and 31 output tokens and recorded $0.0000576 in reported cost. - Earlier live OpenRouter verification produced a receipt in 1.013 seconds for a new task. The real agent then supplied its substantive answer. A separate settings test took 1.34 seconds, used 246 input and 23 output tokens, and recorded $0.0000361. - Live Slack verification on final commit `24016fa525961ebc7a4acffdc5019ce123970549` passed for a fresh initial task and a follow-up in a disposable bot DM. The initial acknowledgement appeared 2.405 seconds after the Slack message and 1.413 seconds after durable acceptance; the follow-up appeared in 2.322 seconds and 1.160 seconds respectively. The recorded generation/settlement durations were 898 ms and 697 ms. The initial call used 291 input / 39 output tokens and cost $0.00006705; the follow-up used 281 / 47 and cost $0.00007035. - The Slack acknowledgements retained the assigned agent identity and `origin: fast_response`, source-turn references, and no fabricated run ID. A status snapshot after the initial receipt showed the task still `in_progress` with its real execution run. The agent then read the CSV fixture and correctly reported two ready items, two blockers, and their owners. Both replies stayed in the originating DM, and no duplicate generic working message followed the delivered contextual acknowledgements. The `new` command started a fresh conversation session without generating a fast response. - An earlier eligible Slack turn generated a response but suppressed publication. Its reported cost was retained, generic progress remained, and the real agent completed the requested result. This is recorded separately from the two delivered acknowledgements; the history did not expose a precise suppression reason. - Slack verification used real signed provider events, the existing intake/publication paths, and a user-approved temporary webhook-only HTTPS tunnel. Subscriptions were limited to direct-message events. The test bot was paused and the tunnel stopped afterward. Live channel/group-thread and GitHub journeys remain unverified; their mocked tests cover intake, destination binding, publication, and continued underlying work. - Greptile reviewed final commit `24016fa525961ebc7a4acffdc5019ce123970549` at 5/5. Both new review findings are fixed and all threads are resolved. [Final-head CI run](https://github.com/paperclipai/paperclip/actions/runs/38060015730) passed. This includes grouped server/chat/workspace tests, serialized suites, runner checks, browser journeys, typecheck, build, release registry, policy, and the canary dry run. - Manual check: enable Experimental fast responses. Open company Settings → Connections. Select a shared API connection and model. Save and use Test response. Submit a task message and confirm that its receipt does not complete the task. ## Risks - The migration adds receipt and configuration tables plus accounting references. It uses idempotent statements and follows the current migration sequence. - A slow provider, authorization change, or real-agent reply can suppress an acknowledgement. Existing progress feedback remains available. - Unknown provider billing retains a reservation until reconciliation. External deliveries with uncertain outcomes must not be blindly repeated. - Live Slack initial-task and follow-up DM journeys pass. Live Slack channel/group-thread and GitHub journeys remain unverified. The PR remains a draft and records these gaps. Final-head repository CI and automated review pass. ## Model Used OpenAI Codex, based on GPT-6, with reasoning, repository tools, code execution, and browser interaction. The runtime does not expose an exact model snapshot ID or context-window size; these are not asserted. ## 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 (e.g. `docs/...`, `fix/...`) 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>
182 lines
5.7 KiB
TypeScript
182 lines
5.7 KiB
TypeScript
import type { LiveEvent } from "@paperclipai/shared";
|
|
import { publishLiveEvent } from "./live-events.js";
|
|
import { isSafeNativeChatProgressEventType } from "./safe-native-chat-progress.js";
|
|
|
|
const CHAT_PUBLICATION_PRESENTATION_COMMIT_EVENT = "run.presentation.resolved";
|
|
|
|
function isChatPublicationCommitEventType(eventType: string): boolean {
|
|
return eventType === CHAT_PUBLICATION_PRESENTATION_COMMIT_EVENT ||
|
|
isSafeNativeChatProgressEventType(eventType);
|
|
}
|
|
|
|
/**
|
|
* Only events emitted after durable run evidence is visible may wake the
|
|
* publication reconciler. Earlier lifecycle/status events can precede the
|
|
* transaction that creates the corresponding chat publication, so polling
|
|
* remains their recovery path.
|
|
*/
|
|
export function isChatPublicationCommitSignal(
|
|
event: Pick<LiveEvent, "type" | "payload">,
|
|
): boolean {
|
|
if (event.type === "activity.logged" && event.payload.action === "issue.comment_added" && (event.payload.details as Record<string, unknown> | undefined)?.origin === "fast_response") return true;
|
|
if (event.type !== "heartbeat.run.event") return false;
|
|
const eventType = event.payload.eventType;
|
|
if (typeof eventType !== "string") return false;
|
|
return isChatPublicationCommitEventType(eventType);
|
|
}
|
|
|
|
/**
|
|
* Emit a company-scoped publication wake only after its durable source row is
|
|
* visible. The narrow primitive input prevents a PRP payload, message, tool
|
|
* name, target, result, or error from crossing into the public live stream.
|
|
*/
|
|
export function publishChatPublicationCommitSignal(input: {
|
|
companyId: string;
|
|
issueId: string;
|
|
runId: string;
|
|
agentId: string;
|
|
eventType: string;
|
|
seq?: number;
|
|
}): boolean {
|
|
if (!isChatPublicationCommitEventType(input.eventType)) return false;
|
|
try {
|
|
publishLiveEvent({
|
|
companyId: input.companyId,
|
|
type: "heartbeat.run.event",
|
|
payload: {
|
|
runId: input.runId,
|
|
agentId: input.agentId,
|
|
issueId: input.issueId,
|
|
...(input.seq === undefined ? {} : { seq: input.seq }),
|
|
eventType: input.eventType,
|
|
},
|
|
});
|
|
return true;
|
|
} catch {
|
|
// This notification is an optional latency optimization. A subscriber
|
|
// failure must not reject an already-committed event/comment or skip its
|
|
// durable side effects; the periodic reconciliation poll remains recovery.
|
|
return false;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* A bounded, single-flight wakeup for a level-triggered durable worker.
|
|
* Same-turn notifications coalesce before work starts. One notification that
|
|
* arrives after work starts records a dirty bit and schedules exactly one
|
|
* follow-up pass, so a commit cannot be stranded behind an in-flight scan.
|
|
* Periodic recovery polls never set that dirty bit.
|
|
*/
|
|
export function createCoalescedAsyncTrigger(input: {
|
|
run: () => Promise<unknown>;
|
|
onError: (error: unknown) => void;
|
|
minimumSpacingMs?: number;
|
|
}) {
|
|
const minimumSpacingMs = Math.max(0, input.minimumSpacingMs ?? 100);
|
|
let stopped = false;
|
|
let dirty = false;
|
|
let lastStartedAt: number | null = null;
|
|
let scheduled: Promise<void> | null = null;
|
|
let scheduledTimer: ReturnType<typeof setTimeout> | null = null;
|
|
let resolveScheduled: (() => void) | null = null;
|
|
let running: Promise<void> | null = null;
|
|
|
|
const reportError = (error: unknown) => {
|
|
try {
|
|
input.onError(error);
|
|
} catch {
|
|
// The worker error is already contained. A diagnostic callback must not
|
|
// create an unhandled rejection or prevent the durable recovery poll.
|
|
}
|
|
};
|
|
|
|
const start = () => {
|
|
if (stopped || running) return;
|
|
lastStartedAt = Date.now();
|
|
const current = Promise.resolve()
|
|
.then(async () => {
|
|
await input.run();
|
|
})
|
|
.catch(reportError)
|
|
.finally(() => {
|
|
if (running !== current) return;
|
|
running = null;
|
|
const shouldRunAgain = dirty && !stopped;
|
|
dirty = false;
|
|
if (shouldRunAgain) schedule();
|
|
});
|
|
running = current;
|
|
};
|
|
|
|
const schedule = () => {
|
|
if (stopped || scheduled || running) return;
|
|
const delay =
|
|
lastStartedAt === null
|
|
? 0
|
|
: Math.max(0, lastStartedAt + minimumSpacingMs - Date.now());
|
|
if (delay === 0) {
|
|
const current = Promise.resolve().then(() => {
|
|
if (scheduled !== current) return;
|
|
scheduled = null;
|
|
if (!stopped) start();
|
|
});
|
|
scheduled = current;
|
|
return;
|
|
}
|
|
const current = new Promise<void>((resolve) => {
|
|
resolveScheduled = resolve;
|
|
scheduledTimer = setTimeout(() => {
|
|
if (scheduled !== current) return;
|
|
scheduled = null;
|
|
scheduledTimer = null;
|
|
resolveScheduled = null;
|
|
resolve();
|
|
if (!stopped) start();
|
|
}, delay);
|
|
scheduledTimer.unref?.();
|
|
});
|
|
scheduled = current;
|
|
};
|
|
|
|
return {
|
|
/** An event-backed wake records one bounded follow-up while work runs. */
|
|
notify() {
|
|
if (stopped) return;
|
|
if (running) {
|
|
dirty = true;
|
|
return;
|
|
}
|
|
if (scheduled) return;
|
|
schedule();
|
|
},
|
|
|
|
/** A recovery poll starts an idle worker but never creates extra work. */
|
|
poll() {
|
|
if (stopped || running || scheduled) return;
|
|
schedule();
|
|
},
|
|
|
|
stop() {
|
|
stopped = true;
|
|
dirty = false;
|
|
if (scheduledTimer) clearTimeout(scheduledTimer);
|
|
scheduledTimer = null;
|
|
scheduled = null;
|
|
resolveScheduled?.();
|
|
resolveScheduled = null;
|
|
},
|
|
|
|
async drain() {
|
|
// A dirty follow-up is assigned from the prior promise's finally block.
|
|
// Loop so callers that have not stopped the trigger also join that pass.
|
|
while (scheduled || running) {
|
|
await Promise.allSettled(
|
|
[scheduled, running].filter(
|
|
(promise): promise is Promise<void> => promise !== null,
|
|
),
|
|
);
|
|
}
|
|
},
|
|
};
|
|
}
|