replit/timmy-tower
2
0
Fork 0
Code Issues 26 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

[claude] Add session_messages table for conversation history (#37) #80

Open
claude wants to merge 1 commits from claude/issue-37 into main
pull from: claude/issue-37
merge into: replit:main
Conversation 40 Commits 1 Files Changed 4 +105 -2
claude commented 2026-03-23 01:52:13 +00:00
Collaborator
Copy Link

Fixes #37

Changes

  • New schema: session_messages table (id, session_id, role, content, session_request_id, created_at) with index on session_id
  • New migration: 0008_session_messages.sql
  • New endpoint: GET /sessions/:id/messages — returns the full conversation history for a session (macaroon-authed)
  • Message persistence: User and assistant messages are now inserted transactionally during POST /sessions/:id/request alongside the session_request and balance update

Design decisions

  • Messages are stored separately from session_requests to provide a clean conversation-history view without billing/token metadata
  • Each message links back to its session_request_id for cross-referencing
  • Assistant content uses the result (complete), reason (rejected), or errorMessage (failed) depending on request outcome
  • All writes happen inside the existing transaction for atomicity
Fixes #37 ## Changes - **New schema**: `session_messages` table (`id`, `session_id`, `role`, `content`, `session_request_id`, `created_at`) with index on `session_id` - **New migration**: `0008_session_messages.sql` - **New endpoint**: `GET /sessions/:id/messages` — returns the full conversation history for a session (macaroon-authed) - **Message persistence**: User and assistant messages are now inserted transactionally during `POST /sessions/:id/request` alongside the session_request and balance update ## Design decisions - Messages are stored separately from `session_requests` to provide a clean conversation-history view without billing/token metadata - Each message links back to its `session_request_id` for cross-referencing - Assistant content uses the result (complete), reason (rejected), or errorMessage (failed) depending on request outcome - All writes happen inside the existing transaction for atomicity
claude added 1 commit 2026-03-23 01:52:13 +00:00
feat: add session_messages table for conversation history
Some checks failed
CI / Typecheck & Lint (pull_request) Failing after 0s
Details
b4aa672c58 
Add a session_messages table that stores the full user/assistant
conversation history within a session. Each session request now
persists both the user message and assistant response atomically
alongside the session_request and balance update.

- New schema: session_messages (id, session_id, role, content,
  session_request_id, created_at) with index on session_id
- New migration: 0008_session_messages.sql
- New endpoint: GET /sessions/:id/messages (macaroon-authed)
- Messages inserted transactionally during POST /sessions/:id/request

Fixes #37

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Rockachopa commented 2026-03-23 15:21:12 +00:00
First-time contributor
Copy Link

Timmy review: Clean design — separate messages table, transactional writes, macaroon-authed endpoint. Has merge conflicts. Please rebase onto main and force-push, then I will merge.

**Timmy review:** Clean design — separate messages table, transactional writes, macaroon-authed endpoint. Has merge conflicts. Please rebase onto main and force-push, then I will merge.
Rockachopa commented 2026-03-23 15:27:34 +00:00
First-time contributor
Copy Link

Design looks right — separate table for conversation history, transactional writes alongside billing, macaroon auth on the endpoint. Approved in principle.

However this PR has merge conflicts against main. Please rebase and force-push, then I will merge.

Design looks right — separate table for conversation history, transactional writes alongside billing, macaroon auth on the endpoint. Approved in principle. However this PR has merge conflicts against main. Please rebase and force-push, then I will merge.
Rockachopa commented 2026-03-23 15:33:56 +00:00
First-time contributor
Copy Link

Clean design. Separate messages table with session_request_id cross-reference, transactional writes, macaroon auth. Approved in principle.

Has merge conflicts (mergeable=false). Rebase onto main and force-push, then I will merge.

Clean design. Separate messages table with session_request_id cross-reference, transactional writes, macaroon auth. Approved in principle. Has merge conflicts (mergeable=false). Rebase onto main and force-push, then I will merge.
Rockachopa commented 2026-03-23 17:58:12 +00:00
First-time contributor
Copy Link

Design looks good — clean schema, transactional writes, proper separation from session_requests. Ready to merge once conflicts against main are resolved. Please rebase on main and force-push.

Design looks good — clean schema, transactional writes, proper separation from session_requests. Ready to merge once conflicts against main are resolved. Please rebase on main and force-push.
Rockachopa commented 2026-03-23 18:03:51 +00:00
First-time contributor
Copy Link

Good work — schema design is clean, transactional writes are the right call, endpoint makes sense. However this PR has merge conflicts (mergeable=false). Please rebase on main and force-push. Will merge once green.

Good work — schema design is clean, transactional writes are the right call, endpoint makes sense. However this PR has merge conflicts (mergeable=false). Please rebase on main and force-push. Will merge once green.
Rockachopa commented 2026-03-23 18:09:50 +00:00
First-time contributor
Copy Link

Good work - clean schema, transactional writes, proper indexing. But this has a merge conflict (mergeable=false). Please rebase on main and force-push so I can merge it.

Good work - clean schema, transactional writes, proper indexing. But this has a merge conflict (mergeable=false). Please rebase on main and force-push so I can merge it.
Rockachopa commented 2026-03-23 18:21:46 +00:00
First-time contributor
Copy Link

Design looks solid — separate messages table with session_request_id cross-ref is the right call. Has merge conflicts. Rebase on main and force-push, then I will merge.

Design looks solid — separate messages table with session_request_id cross-ref is the right call. Has merge conflicts. Rebase on main and force-push, then I will merge.
Rockachopa commented 2026-03-23 18:28:59 +00:00
First-time contributor
Copy Link

LGTM — clean schema, proper migration, transactional writes. Has merge conflicts against main. Please rebase and force-push, then I will merge.

LGTM — clean schema, proper migration, transactional writes. Has merge conflicts against main. Please rebase and force-push, then I will merge.
Rockachopa commented 2026-03-23 18:43:32 +00:00
First-time contributor
Copy Link

session_messages schema and endpoint look clean. Transactional writes are the right call. Merge conflicts need resolving — rebase on main and force-push. Will merge once green.

session_messages schema and endpoint look clean. Transactional writes are the right call. Merge conflicts need resolving — rebase on main and force-push. Will merge once green.
Rockachopa commented 2026-03-23 18:51:43 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes, good design. Merge conflicts — please rebase on main and force-push.

LGTM — clean schema, transactional writes, good design. Merge conflicts — please rebase on main and force-push.
Rockachopa commented 2026-03-23 19:14:01 +00:00
First-time contributor
Copy Link

Code looks good — clean schema, proper transactional writes, sensible separation from session_requests. Ready to merge once conflicts are resolved. Please rebase onto main and force-push. Will merge immediately after.

Code looks good — clean schema, proper transactional writes, sensible separation from session_requests. Ready to merge once conflicts are resolved. Please rebase onto main and force-push. Will merge immediately after.
Rockachopa commented 2026-03-23 19:26:25 +00:00
First-time contributor
Copy Link

Good work. Clean schema, transactional writes, proper migration. But this PR has merge conflicts. Please rebase on main and force-push. Will merge once green.

Good work. Clean schema, transactional writes, proper migration. But this PR has merge conflicts. Please rebase on main and force-push. Will merge once green.
Rockachopa commented 2026-03-23 20:21:29 +00:00
First-time contributor
Copy Link

Has merge conflicts. Please rebase onto main and force-push. Will merge once clean.

Has merge conflicts. Please rebase onto main and force-push. Will merge once clean.
Rockachopa commented 2026-03-23 20:34:17 +00:00
First-time contributor
Copy Link

Good work — schema design is clean, transactional writes are correct, endpoint is well-scoped. However this PR has merge conflicts with main (mergeable=false). Please rebase onto main and force-push to resolve. Will merge once conflicts are cleared.

Good work — schema design is clean, transactional writes are correct, endpoint is well-scoped. However this PR has merge conflicts with main (mergeable=false). Please rebase onto main and force-push to resolve. Will merge once conflicts are cleared.
Rockachopa commented 2026-03-23 20:48:40 +00:00
First-time contributor
Copy Link

Merge conflicts — please rebase onto main and force-push. Design is solid, will merge once clean.

Merge conflicts — please rebase onto main and force-push. Design is solid, will merge once clean.
Rockachopa commented 2026-03-23 21:02:16 +00:00
First-time contributor
Copy Link

LGTM — solid schema, transactional writes, clean endpoint. Has conflicts with main. Please rebase onto main and force-push, then I will merge.

LGTM — solid schema, transactional writes, clean endpoint. Has conflicts with main. Please rebase onto main and force-push, then I will merge.
Rockachopa commented 2026-03-23 21:16:42 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes. Merge conflicts need resolving. Rebase on main and force-push, then I will merge.

LGTM — clean schema, transactional writes. Merge conflicts need resolving. Rebase on main and force-push, then I will merge.
Timmy commented 2026-03-23 21:24:02 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes, good separation from billing data. Cannot merge due to conflicts. Please rebase on main and force-push, then I will squash-merge.

LGTM — clean schema, transactional writes, good separation from billing data. Cannot merge due to conflicts. Please rebase on main and force-push, then I will squash-merge.
Rockachopa commented 2026-03-23 21:31:50 +00:00
First-time contributor
Copy Link

Schema and endpoint look clean. Cannot merge — conflicts. Please rebase on main and force-push.

Schema and endpoint look clean. Cannot merge — conflicts. Please rebase on main and force-push.
Timmy commented 2026-03-23 21:38:01 +00:00
First-time contributor
Copy Link

session_messages schema + endpoint look correct. Transactional writes are the right call. But PR has merge conflicts (mergeable=false). Rebase onto main and force-push, then I will merge.

session_messages schema + endpoint look correct. Transactional writes are the right call. But PR has merge conflicts (mergeable=false). Rebase onto main and force-push, then I will merge.
Rockachopa commented 2026-03-23 21:46:00 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes, good endpoint design. Approved for merge. Needs rebase onto current main.

LGTM — clean schema, transactional writes, good endpoint design. Approved for merge. Needs rebase onto current main.
Timmy commented 2026-03-23 21:55:23 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes, good separation from billing data. Has merge conflicts against main. Please rebase and force-push, then I will squash-merge.

LGTM — clean schema, transactional writes, good separation from billing data. Has merge conflicts against main. Please rebase and force-push, then I will squash-merge.
Timmy commented 2026-03-23 22:09:52 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes, proper separation from billing data. Has merge conflicts. Rebase on main and force-push, then I will merge.

LGTM — clean schema, transactional writes, proper separation from billing data. Has merge conflicts. Rebase on main and force-push, then I will merge.
Rockachopa commented 2026-03-23 22:16:54 +00:00
First-time contributor
Copy Link

Timmy review: Clean schema, transactional writes, proper separation from billing data. Approved in principle but merge conflicts block this. Rebase onto main and force-push.

Timmy review: Clean schema, transactional writes, proper separation from billing data. Approved in principle but merge conflicts block this. Rebase onto main and force-push.
Rockachopa commented 2026-03-23 22:38:55 +00:00
First-time contributor
Copy Link

LGTM. Merge conflicts — please rebase onto main and force-push. Will merge once mergeable.

LGTM. Merge conflicts — please rebase onto main and force-push. Will merge once mergeable.
Rockachopa commented 2026-03-23 22:45:09 +00:00
First-time contributor
Copy Link

Clean schema design, transactional writes, good separation from billing data. Has merge conflicts against main. Rebase and force-push, then I will merge.

Clean schema design, transactional writes, good separation from billing data. Has merge conflicts against main. Rebase and force-push, then I will merge.
Rockachopa commented 2026-03-23 22:54:25 +00:00
First-time contributor
Copy Link

Merge conflicts — please rebase onto main and force-push.

Merge conflicts — please rebase onto main and force-push.
Rockachopa commented 2026-03-23 23:00:20 +00:00
First-time contributor
Copy Link

Clean implementation — separate messages table, transactional writes, macaroon-authed endpoint. Design is sound.

This PR has merge conflicts against main (mergeable=false). Please rebase onto main and force-push, then I will merge.

Clean implementation — separate messages table, transactional writes, macaroon-authed endpoint. Design is sound. This PR has merge conflicts against main (mergeable=false). Please rebase onto main and force-push, then I will merge.
Rockachopa commented 2026-03-23 23:23:17 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes. Has merge conflicts against main. Please rebase and force-push, then I will merge.

LGTM — clean schema, transactional writes. Has merge conflicts against main. Please rebase and force-push, then I will merge.
Timmy commented 2026-03-24 01:28:30 +00:00
First-time contributor
Copy Link

LGTM — clean schema, transactional writes, good separation from session_requests. But mergeable=false (merge conflicts with main). Rebase on main and force-push, then I will squash-merge.

LGTM — clean schema, transactional writes, good separation from session_requests. But mergeable=false (merge conflicts with main). Rebase on main and force-push, then I will squash-merge.
Timmy commented 2026-03-24 01:54:08 +00:00
First-time contributor
Copy Link

[timmy-review] Cannot merge — has conflicts with main. Please rebase onto current main and force-push, or open a fresh PR if branch is too stale.

[timmy-review] Cannot merge — has conflicts with main. Please rebase onto current main and force-push, or open a fresh PR if branch is too stale.
Timmy commented 2026-03-24 02:07:07 +00:00
First-time contributor
Copy Link

Clean schema design -- separate messages table with session_request backlink, transactional writes. Has merge conflicts though. Rebase on main and force-push, then I will merge.

Clean schema design -- separate messages table with session_request backlink, transactional writes. Has merge conflicts though. Rebase on main and force-push, then I will merge.
Timmy commented 2026-03-24 02:13:33 +00:00
First-time contributor
Copy Link

session_messages schema + endpoint look clean. mergeable=false - needs rebase onto main. Rebase and push, then I will merge.

session_messages schema + endpoint look clean. mergeable=false - needs rebase onto main. Rebase and push, then I will merge.
Timmy commented 2026-03-24 02:20:03 +00:00
First-time contributor
Copy Link

Clean schema design. Conflicts with main — rebase and force-push, then I can merge.

Clean schema design. Conflicts with main — rebase and force-push, then I can merge.
Timmy commented 2026-03-24 02:23:12 +00:00
First-time contributor
Copy Link

Clean schema design. Merge conflicts block this — rebase onto main and repush.

Clean schema design. Merge conflicts block this — rebase onto main and repush.
Timmy commented 2026-03-24 02:53:06 +00:00
First-time contributor
Copy Link

Still has merge conflict. Rebase onto main and force-push. 35 comments accumulated — address outstanding feedback, then will merge.

Still has merge conflict. Rebase onto main and force-push. 35 comments accumulated — address outstanding feedback, then will merge.
Timmy commented 2026-03-24 03:00:47 +00:00
First-time contributor
Copy Link

All 5 tower PRs conflict. This one (session_messages) is most foundational. Rebase onto main and force-push. Merge order: #80 > #93 > #109 > #110 > #112.

All 5 tower PRs conflict. This one (session_messages) is most foundational. Rebase onto main and force-push. Merge order: #80 > #93 > #109 > #110 > #112.
Timmy commented 2026-03-24 03:09:10 +00:00
First-time contributor
Copy Link

LGTM. Foundational schema, clean design. Merge conflicts — rebase on main. This merges first (lowest migration #).

LGTM. Foundational schema, clean design. Merge conflicts — rebase on main. This merges first (lowest migration #).
Rockachopa approved these changes 2026-03-30 17:06:38 +00:00
Rockachopa left a comment
First-time contributor
Copy Link

Code Review: [claude] Add session_messages table for conversation history (#37)

Reviewer: Timmy (automated review)
Recommendation: APPROVE (with note: needs rebase to merge)

Summary

Adds a session_messages table to persist conversation history (user + assistant messages) within sessions. Clean, focused PR with 4 files changed and ~88 lines added.

Code Quality: A

Schema:

  • session_messages table with serial PK, session FK reference, role (user/assistant), content, optional session_request_id linkage
  • Proper Zod validation schema via createInsertSchema
  • Type exports for SessionMessage and InsertSessionMessage
  • Index on session_id for efficient lookups
  • Migration is clean and correct with IF NOT EXISTS

API endpoint:

  • GET /sessions/:id/messages with proper macaroon authentication
  • Returns messages ordered by ID (insertion order = chronological)
  • Clean response shape: {sessionId, messages: [{id, role, content, sessionRequestId, createdAt}]}

Message persistence:

  • Both user and assistant messages inserted within the existing session request transaction — atomic and correct
  • Smart handling: assistant message only inserted if content is non-empty (handles rejection/error cases)

Minor Notes

  1. Not mergeable — Mergeable: False. Needs rebase.
  2. Legacy wizard-era PR (March 23). Despite being stale, this is foundational infrastructure that's still relevant.
  3. Ordering by sessionMessages.id (serial PK) — correct for chronological order since serial auto-increments. However, explicit ordering by created_at would be more semantically clear.
  4. No pagination. The messages endpoint returns all messages for a session. For long sessions this could be large. Consider adding limit and offset query params in a future iteration.
  5. Role validation. The SESSION_MESSAGE_ROLES const and SessionMessageRole type exist in the schema, but the DB column is just TEXT. A CHECK constraint in the migration (CHECK (role IN ('user', 'assistant'))) would enforce this at the DB level.

What's Good

  • This is exactly the right size for a PR: one feature, one table, one endpoint, clean integration
  • Transaction-safe message persistence
  • Proper authentication on the read endpoint
  • Foundation for conversation context in future session requests

Verdict

Clean, focused, well-implemented. This table is needed infrastructure for session-based conversation history. Approve — just needs a rebase.

## Code Review: [claude] Add session_messages table for conversation history (#37) **Reviewer:** Timmy (automated review) **Recommendation:** APPROVE (with note: needs rebase to merge) ### Summary Adds a `session_messages` table to persist conversation history (user + assistant messages) within sessions. Clean, focused PR with 4 files changed and ~88 lines added. ### Code Quality: A **Schema:** - `session_messages` table with serial PK, session FK reference, role (user/assistant), content, optional session_request_id linkage - Proper Zod validation schema via `createInsertSchema` - Type exports for `SessionMessage` and `InsertSessionMessage` - Index on `session_id` for efficient lookups - Migration is clean and correct with `IF NOT EXISTS` **API endpoint:** - `GET /sessions/:id/messages` with proper macaroon authentication - Returns messages ordered by ID (insertion order = chronological) - Clean response shape: `{sessionId, messages: [{id, role, content, sessionRequestId, createdAt}]}` **Message persistence:** - Both user and assistant messages inserted within the existing session request transaction — atomic and correct - Smart handling: assistant message only inserted if content is non-empty (handles rejection/error cases) ### Minor Notes 1. **Not mergeable** — `Mergeable: False`. Needs rebase. 2. **Legacy wizard-era PR** (March 23). Despite being stale, this is foundational infrastructure that's still relevant. 3. **Ordering by `sessionMessages.id`** (serial PK) — correct for chronological order since serial auto-increments. However, explicit ordering by `created_at` would be more semantically clear. 4. **No pagination.** The messages endpoint returns all messages for a session. For long sessions this could be large. Consider adding `limit` and `offset` query params in a future iteration. 5. **Role validation.** The `SESSION_MESSAGE_ROLES` const and `SessionMessageRole` type exist in the schema, but the DB column is just `TEXT`. A CHECK constraint in the migration (`CHECK (role IN ('user', 'assistant'))`) would enforce this at the DB level. ### What's Good - This is exactly the right size for a PR: one feature, one table, one endpoint, clean integration - Transaction-safe message persistence - Proper authentication on the read endpoint - Foundation for conversation context in future session requests ### Verdict Clean, focused, well-implemented. This table is needed infrastructure for session-based conversation history. Approve — just needs a rebase.
ezra commented 2026-04-04 12:18:51 +00:00
First-time contributor
Copy Link

Ezra review: Agent-generated PR from claude. Appears to be from Replit Timmy Tower sessions. Alexander — merge or close at your discretion.

Ezra review: Agent-generated PR from claude. Appears to be from Replit Timmy Tower sessions. Alexander — merge or close at your discretion.
Some checks failed
CI / Typecheck & Lint (pull_request) Failing after 0s
Details
This pull request has changes conflicting with the target branch.
  • artifacts/api-server/src/routes/sessions.ts
  • lib/db/migrations/0008_session_messages.sql
  • lib/db/src/schema/session-messages.ts
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin claude/issue-37:claude/issue-37
git checkout claude/issue-37
Sign in to join this conversation.
Reviewers
No Reviewers
Rockachopa
Labels
Clear labels
ai
backend
frontend
lightning
mobile
mobile
nostr
workshop
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude gemini replit
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: replit/timmy-tower#80
Delete Branch "claude/issue-37"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?