Files
PaperClipAI/server/src/modules
馨冉and馨冉 7c6d977929 fix(wake-queue): skip malformed queued comment ids so one bad id cannot block an issue's wakes (#13912)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - The wake queue decides whether a finishing run's `@`-mention
actually wakes the mentioned agent, by checking the liveness of the
comment ids queued in the wake payload
> - `getQueuedCommentLiveness` passes every queued comment id straight
into an SQL `inArray`. Postgres rejects the whole statement on the first
malformed uuid, so one bad id (for example an 8-char short form written
into a wake payload) silently blocks every queued wake for that issue
> - The run that triggers the check still records `succeeded`, so from
the board the agent finished its work and the mentioned agent simply
never responds; the reporter hit this twice on the same long-lived issue
> - This pull request filters the queued ids with the existing
`isUuidLike` helper before the query, and skips the query entirely when
nothing valid remains
> - The benefit is that a malformed id is skipped instead of poisoning
the batch — it can never match a comment row anyway, so the downstream
liveness semantics do not change

Fixes: #13908

Related issue class (malformed ids reaching database queries): #887,
#7639, #8093, #11018, #13504 — this is the first report for the
wake-queue site.

## What Changed

- `server/src/modules/wake-queue/adapters/postgres.ts`: in
`getQueuedCommentLiveness`, filter `queuedCommentIds` through
`isUuidLike` before building the `inArray` predicate; when no valid uuid
remains, skip the query and return an empty row set.
- The post-processing loops now iterate the filtered id list, which is
equivalent because a malformed id can never match a comment row.

## Verification

- New embedded-Postgres regression tests in
`server/src/modules/wake-queue/adapters/postgres.test.ts`:
- a batch mixing one live comment id, one malformed short-form id, and
one valid-but-missing uuid returns only the live comment instead of
throwing;
- an all-malformed batch returns nothing live instead of generating
`inArray ()`.
- `./node_modules/.bin/vitest run
server/src/modules/wake-queue/adapters/postgres.test.ts` — 58/58 pass.

## Risks

Low risk. The only behavioral change is that a wake batch that would
previously fail the whole statement now dispatches the valid entries. A
malformed id previously matched no rows (the statement errored before
any filtering), so treating it as not-live is exactly what the old
downstream filters would have concluded had the query run.

## Model Used

Codex (OpenAI GPT-5, coding agent, tool use, repo-level context) —
assisted with locating the call site, authoring the guard, and the
regression tests; human review before submission.

## 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: 馨冉 <xinxincui239@gmail.com>
2026-10-15 16:04:57 -07:00
..

Feature modules

A feature module under server/src/modules/<name>/ uses three layers. Each layer has one rule: which layer below it, it may import from.

adapters  →  application  →  domain
  • domain/ holds pure business rules. A domain file takes plain data in and returns plain data out. A domain file must not import drizzle-orm, @paperclipai/db, a service under server/src/services/, a route under server/src/routes/, or a Node.js I/O module (node:child_process, node:fs, node:net). A domain function must not read the system clock; the caller passes now as an explicit Date value.
  • application/ holds use cases and the ports they need. A use case takes its ports as constructor arguments and calls domain functions for policy decisions. An application file must not import drizzle-orm, a SQL client, a concrete adapter, or the server's HTTP error helpers. The outer service or route translates application errors into transport responses.
  • adapters/ holds the concrete implementations of the ports: Postgres queries, transactions, and process control. An adapter file may import drizzle-orm, @paperclipai/db, and Node.js I/O modules.

A module exposes its commands through index.ts, which composes the adapters and the use cases behind a factory function. Code outside the module imports that entry point, never a file inside domain/, application/, or adapters/ directly.

pnpm check:module-boundaries enforces these rules for production source files. It also checks access to the company deletion entry point below.

Company deletion

The existing company deletion service owns the database transaction and deletion order. A module can expose a separate company-deletion.ts entry point. Only services/company-deletion.ts can import this entry point. The entry point exports an implementation of CompanyDeletionParticipant from lib/company-deletion.ts. Do not export it through the normal module index.

The service must complete external cleanup before it starts the transaction. It must lock the company before it deletes dependent records or calls a module. Creation commands must use the same company lock. The service removes dependent records before it calls the module. The module checks its deletion conditions and deletes the records it owns. Use the supplied transaction. Do not start another transaction or call external systems. Throw an error if deletion cannot proceed. An error must roll back all database changes in the deletion transaction.

Call each module explicitly in dependency order. No module registry is required.

The agent lifecycle module also has a restricted configuration.ts entry point. It saves configuration and invalidates verification in the caller's transaction. The lifecycle guide lists its permitted callers. Ordinary configuration updates use the root lifecycle command.

The agent lifecycle module owns agent creation, pause, resume, and termination. Use its commands for these changes.