Backend: Add public_trips models and migration

[nabramow]

Describe briefly what this PR is doing and why

Closes #7718

This is only the backend models and migration. But here is an overview of the plan so you can see the vision and discuss.

Public trips will be a way for travelers to publicly announce they're visiting a city and looking for a host, so potential hosts in that community can discover and reach out to them.

Overview of how it will work:

For Travelers:

• Go to a city community page (e.g., Paris)
• Post a "public trip" with: Travel dates (from/to), Short message (why visiting, what they're looking for)
• Trip appears in the community's Public Trips tab
• Receive host offers via the normal host request system
• Mark trip as "found host" when done

For Potential Hosts:

• Browse Public Trips tab in their community (plan to also have feed on dashboard)
• See travelers visiting their city
• Click to view traveler's profile (increases profile_click_count for metrics)
• Click "Offer to Host" → creates a standard host request (we need to to trigger reference flow etc)
• Normal messaging and acceptance flow follows

Design Decisions:

• Uses existing host request system (no new acceptance flow)
• Linked via public_trip_id on host requests (tracks origin)
• Restricted to city-level communities only (not global/country)

Where It Appears

• Community page: New "Public Trips" tab
• Dashboard (future): "Public trips in my communities" section
• Messages: Indicator showing request came from a public trip
• User will have a "My Public trips" page linked via Public Trips tab and Account Settings to manage their trips and mark complete or delete.

Please give clear steps for how the reviewer can best test this PR

Please include any necessary dev environment, .env, etc. adjustments.

• docker compose up --build
• cd app/backend
• make downgrade
• Make sure no more public_trips table and no more public_trip_id in host_requests
• make upgrade
• Now should have public trips table and public_trip_id in host_requests

Backend checklist

• Formatted my code by running make format in app/backend
• Added tests for any new code or added a regression test if fixing a bug
• All tests pass
• Run the backend locally and it works
• Added migrations if there are any database changes, rebased onto develop if necessary for linear migration history

Other
Untick the following if you'd prefer that maintainers don't push commits/merge your branch.

• A maintainer can push commits to my branch
• A maintainer can merge my PR (you can also merge after approval)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
couchers	Ready	Preview	Feb 22, 2026 3:33am

[nabramow]

Not sure I like the "found host" status but naming is hard.

[nabramow]

The idea is after the date of the public_trip we will shop a dropdown or some select to mark the outcome. And maybe send a notification "let us know how it went?" or something for metrics.

[nabramow]

People who clicked on the profile via the public_trip. This is the best measurable metric I could think of for metrics. But maybe we also want to show a view count on the UI? In any case good data for us?

[nabramow]

Maybe overkill as we could do a join table but would be good to judge the success of the feature.

[nabramow]

We'll need a way to determine if a host_request came from a public_trip.

[aapeliv]

Receive host offers via the normal host request system
Click "Offer to Host" → creates a standard host request (we need to to trigger reference flow etc)
Uses existing host request system (no new acceptance flow)

How exactly will this work?

Restricted to city-level communities only (not global/country)

What about places without city-level communities?

[couchersbot]

Claude finished @nabramow's task in 2m 43s —— View job

---

Migration Safety Review

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: MEDIUM RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with enums, indexes, and check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Migration Chain (HIGH): down_revision is set to f8b4ef6e3819, but migration a1b2c3d4e5f6 (add group chat archive status) is already on develop with the same down_revision. This creates a branch conflict in the Alembic migration chain. The down_revision must be updated to a1b2c3d4e5f6 before merging. See inline comment.

• Enum Operations (LOW): Two new enums (publictripstatus, publictripoutcome) are created via CREATE TYPE inside the table creation. This is fine for new enums. The downgrade correctly drops them with checkfirst=True. Note that if the migration is partially applied and fails mid-way, the enums may exist without the table — but checkfirst=True handles this gracefully.

• Index on host_requests (LOW): An index is created on host_requests.public_trip_id. Since host_requests could be a moderately large table in production, this will acquire a brief lock. However, indexing a new nullable column (all NULLs initially) is fast and unlikely to cause issues in practice.

Previously Flagged Review Items (from other reviewers, still unaddressed)

• backref deprecation (@WouldYouKindly): backref= is used in public_trips.py:67-68 and host_requests.py:99. Should use back_populates instead. See inline comment.
• Composite index column order (@WouldYouKindly): The index ix_public_trips_node_status_from_date has column order (node_id, status, from_date). Reviewer suggested (node_id, from_date, status) since status has lower cardinality, or using a partial index with postgresql_where to filter on status.
• Redundant __repr__ (@WouldYouKindly): Base (via MappedAsDataclass) already auto-generates __repr__. See inline comment.

Summary

The migration itself is structurally safe for existing production data — it creates a new table and adds a nullable column, so no existing rows are affected. The blocking issue is the down_revision conflict: it must be rebased to point to a1b2c3d4e5f6 to maintain a linear migration history on develop.

[couchersbot]

Claude finished @nabramow's task in 3m 28s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: MEDIUM RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with enums, indexes, and check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Migration Chain (HIGH): down_revision is set to f8b4ef6e3819, but migration a1b2c3d4e5f6 (add group chat archive status) already exists on develop with the same down_revision. This creates a branch conflict in the Alembic migration chain. The current develop head is 738c3c9f922e (implement UMS for events). The down_revision must be updated to 738c3c9f922e before merging. See inline comment.

• Enum Operations (LOW): Two new enums (publictripstatus, publictripoutcome) are created via CREATE TYPE inside the table creation. This is fine for new enums. The downgrade correctly drops them with checkfirst=True. Note that if the migration is partially applied and fails mid-way, the enums may exist without the table — but checkfirst=True handles this gracefully.

• Index on host_requests (LOW): An index is created on host_requests.public_trip_id. Since host_requests could be a moderately large table in production, this will acquire a brief lock. However, indexing a new nullable column (all NULLs initially) is fast and unlikely to cause issues in practice.

Previously Flagged Review Items (from other reviewers, still unaddressed)

• backref deprecation (@WouldYouKindly): backref= is used in public_trips.py:67-68 and host_requests.py:99. Should use back_populates instead. See inline comment.
• Composite index column order (@WouldYouKindly): The index ix_public_trips_node_status_from_date has column order (node_id, status, from_date). Reviewer suggested (node_id, from_date, status) since status has lower cardinality, or using a partial index with postgresql_where to filter on status.
• Redundant __repr__ (@WouldYouKindly): Base (via MappedAsDataclass) already auto-generates __repr__. See inline comment.

Summary

The migration itself is structurally safe for existing production data — it creates a new table and adds a nullable column, so no existing rows are affected. The blocking issue is the down_revision conflict: it must be rebased to point to 738c3c9f922e (the current develop head) to maintain a linear migration history on develop.

[couchersbot]

Claude finished @nabramow's task in 2m 13s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: MEDIUM RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with enums, indexes, and check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Migration Chain (HIGH): down_revision is set to a1b2c3d4e5f6, but six migrations already exist after it on develop: a1b2c3d4e5f6 → 6862ecf6494d → f016e6defa9d → 5c0e25460ac2 → 8191f466c673 → d3189338b8c1 → 738c3c9f922e. The current develop head is 738c3c9f922e (implement UMS for events). This creates a branch conflict — the down_revision must be updated to 738c3c9f922e before merging. Fix this →

• Enum Operations (LOW): Two new enums (publictripstatus, publictripoutcome) are created via CREATE TYPE inside the table creation. This is fine for new enums. The downgrade correctly drops them with checkfirst=True.

• Index on host_requests (LOW): An index is created on host_requests.public_trip_id. Since host_requests could be a moderately large table in production, this will acquire a brief lock. However, indexing a new nullable column (all NULLs initially) is fast and unlikely to cause issues in practice.

Previously Flagged Review Items (from other reviewers, still unaddressed)

• backref deprecation (@WouldYouKindly): host_requests.py:99 uses backref="host_requests" on the public_trip relationship. Should use back_populates on both sides instead. The PublicTrip model already correctly uses back_populates for user and node, but has no explicit host_requests relationship — it relies on the backref from HostRequest.
• Composite index column order (@WouldYouKindly): The partial index ix_public_trips_node_from_date_active was updated to use (node_id, from_date) with a postgresql_where filter on status — this addresses the original suggestion and looks good.
• Redundant __repr__ (@WouldYouKindly): The custom __repr__ was removed from PublicTrip — this is addressed.

Summary

The migration itself is structurally safe for existing production data — it creates a new table and adds a nullable column, so no existing rows are affected. The blocking issue is the down_revision conflict: it must be rebased to point to 738c3c9f922e (the current develop head) to maintain a linear migration history on develop.

---

[couchersbot]

Claude finished @nabramow's task in 1m 32s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: MEDIUM RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with publictripstatus enum, indexes (including a partial index on active trips), and a check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Migration Chain (HIGH): down_revision is set to e9190b051324, but migration 0137_add_value_and_source_to_eventlog.py (revision 8eab3434914d) already exists on develop with the same down_revision. This creates a branch conflict in the Alembic migration chain. The current develop head is 0138 (add admin actions and tags, which depends on 8eab3434914d). The down_revision must be updated to 0138 before merging. Fix this →

• Unresolved merge conflict (HIGH): app/backend/src/couchers/models/users.py contains unresolved merge conflict markers (<<<<<<<, =======, >>>>>>>) at lines 48-52. Both the PublicTrip import and the UserAdminTag import are needed — the conflict must be resolved to include both imports.

Summary

The migration itself is structurally safe for existing production data — it creates a new table (no existing rows affected) and adds a nullable column to host_requests (all existing rows get NULL, no constraint violations). Enum creation, check constraint, FK constraints, partial index, and downgrade logic all look correct. The public_trips table and publictripstatus enum do not exist in the production schema, confirming no conflicts. However, there are two blocking issues: (1) the down_revision branch conflict must be resolved by rebasing onto 0138, and (2) the merge conflict in users.py must be resolved.

[couchersbot]

Migration chain conflict (HIGH): This down_revision points to e9190b051324, but migration 0137_add_value_and_source_to_eventlog.py (revision 8eab3434914d) already exists on develop with the same down_revision, and 0138_add_admin_actions_and_tags.py (revision 0138) depends on it. This creates a branch in the migration chain.

The current develop head is 0138. This migration's down_revision must be updated to maintain a linear migration history.

Suggested change

	down_revision = "e9190b051324"
	down_revision = "0138"

[couchersbot]

Unresolved merge conflict: Both imports are needed. Resolve by keeping both:

Suggested change

	<<<<<<< na/backend/public-trips-table
	from couchers.models.public_trips import PublicTrip
	=======
	from couchers.models.admin import UserAdminTag
	>>>>>>> develop
	from couchers.models.public_trips import PublicTrip
	from couchers.models.admin import UserAdminTag

[couchersbot]

Claude finished @nabramow's task in 2m 16s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: MEDIUM RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with publictripstatus enum, indexes (including a partial index on active trips), and a check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Migration Chain (HIGH): down_revision is set to e9190b051324, but migration 0137_add_value_and_source_to_eventlog.py (revision 8eab3434914d) already exists on develop with the same down_revision, and 0138_add_admin_actions_and_tags.py (revision 0138) depends on it. This creates a branch conflict in the Alembic migration chain. The current develop head is 0138. The down_revision must be updated to 0138 before merging. See inline comment.

Summary

The migration itself is structurally safe for existing production data — it creates a new table (no existing rows affected) and adds a nullable column to host_requests (all existing rows get NULL, no constraint violations). The public_trips table and publictripstatus enum do not exist in the production schema, confirming no conflicts. Enum creation, check constraint, FK constraints, partial index, and downgrade logic all look correct. The blocking issue is the down_revision branch conflict: it must be rebased to point to 0138 (the current develop head) to maintain a linear migration history on develop.

[couchersbot]

Claude finished @nabramow's task in 2m 15s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: LOW RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with publictripstatus enum, indexes (including a partial index on active trips), and a check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Docstring mismatch (LOW): Line 4 says Revises: e9190b051324 but the actual down_revision variable on line 14 correctly points to 0138. Alembic uses the variable, not the docstring, so this is not a functional issue — but it's confusing for anyone reading the file header. See inline comment.

• Non-ordinal revision ID (LOW): The project uses ordinal numbering for migrations (e.g. 0138, 0139). This migration uses a hex revision ID 981fb62b20ce and filename. The env.py _next_ordinal() function scans filenames for ordinal prefixes, so this non-ordinal file won't be counted — the next auto-generated migration would also get 0139, potentially causing a conflict. Consider renaming to 0139_add_public_trips.py with revision = "0139". See inline comment.

Summary

This migration is safe for production data. It creates a brand-new table (public_trips) and adds a nullable column (public_trip_id) to host_requests — neither operation affects existing rows. The down_revision correctly points to 0138 (the current develop head). The public_trips table and publictripstatus enum do not exist in the production schema, confirming no conflicts. The downgrade correctly reverses all operations including enum cleanup with checkfirst=True. The only items to address are cosmetic: the stale docstring revision reference and the non-ordinal filename/revision ID.

[couchersbot]

Docstring mismatch (LOW): This says Revises: e9190b051324 but the actual down_revision on line 14 is "0138". Cosmetic only — Alembic uses the variable — but should be corrected for clarity.

Suggested change

	Revises: e9190b051324
	Revises: 0138

[couchersbot]

Claude finished @nabramow's task in 2m 2s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: LOW RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with publictripstatus enum, indexes (including a partial index on active trips), and a check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Docstring mismatch (LOW): Line 4 says Revises: e9190b051324 but the actual down_revision variable on line 14 correctly points to "0138". Alembic uses the variable, not the docstring, so this is not a functional issue — but it should be corrected for clarity. See inline comment.

• Non-ordinal filename (LOW): The project convention (enforced by env.py:_next_ordinal()) is ordinal filenames like 0139_add_public_trips.py. The current filename 981fb62b20ce_add_public_trips.py won't be found by the ordinal scanner, so the next auto-generated migration would also get 0139, creating a revision ID conflict. The file should be renamed to 0139_add_public_trips.py. See inline comment.

Summary

This migration is safe for production data. It creates a brand-new table (public_trips) and adds a nullable column (public_trip_id) to host_requests — neither operation affects existing rows. The down_revision correctly points to 0138 (the current develop head). The public_trips table and publictripstatus enum do not exist in the production schema, confirming no conflicts. The downgrade correctly reverses all operations including enum cleanup with checkfirst=True. The only items to address are cosmetic: the stale docstring revision reference and the non-ordinal filename.

[couchersbot]

Non-ordinal filename (LOW): The project convention (enforced by env.py:_next_ordinal()) is ordinal filenames like 0139_add_public_trips.py. The current filename 981fb62b20ce_add_public_trips.py won't be found by the ordinal scanner — the next auto-generated migration would also get 0139, creating a conflict. Consider renaming this file to 0139_add_public_trips.py.

[nabramow]

@claude can you do this

[claude]

Claude finished @nabramow's task in 1m 30s —— View job

---

Renaming migration to ordinal convention

• Read current migration file
• Rename file from 981fb62b20ce_add_public_trips.py to 0139_add_public_trips.py
• Fix docstring (Revision ID: 981fb62b20ce → Revision ID: 0139)
• Commit and push

Done. Renamed the migration file to 0139_add_public_trips.py and updated the docstring Revision ID to match. The revision variable and Revises line were already correct.

Commit: c1d34cb

[couchersbot]

Claude finished @nabramow's task in 1m 37s —— View job

---

• Gather PR diff and identify migration files
• Read migration files and model files
• Check current production schema
• Evaluate against safety checklist
• Post review findings

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: LOW RISK

Files Reviewed

• 981fb62b20ce_add_public_trips.py — Creates new public_trips table with publictripstatus enum, indexes (including a partial index on active trips), and a check constraint; adds nullable public_trip_id FK column to host_requests

Findings

• Non-ordinal filename (LOW): The project convention (enforced by env.py:_next_ordinal()) is ordinal filenames like 0139_add_public_trips.py. The current filename 981fb62b20ce_add_public_trips.py won't be matched by the ordinal scanner (the regex ^(\d+)_ sees 981 but the next char is f, not _). This means the next auto-generated migration would also get revision 0139, creating a conflict. The file should be renamed to 0139_add_public_trips.py and the docstring Revision ID on line 3 updated to 0139. See inline comment.

Summary

This migration is safe for production data. It creates a brand-new table (public_trips) and adds a nullable column (public_trip_id) to host_requests — neither operation affects existing rows. The down_revision correctly points to 0138 (the current develop head). The public_trips table and publictripstatus enum do not exist in the production schema, confirming no conflicts. The downgrade correctly reverses all operations including enum cleanup with checkfirst=True. The only item to address is the non-ordinal filename.

[couchersbot]

Non-ordinal filename (LOW): The project convention (enforced by env.py:_next_ordinal()) is ordinal filenames like 0139_add_public_trips.py. The current filename 981fb62b20ce_add_public_trips.py won't be matched by the ordinal scanner — the regex ^(\d+)_ sees 981 but the next char is f, not _, so it doesn't match. The next auto-generated migration would also get 0139, creating a revision ID conflict. Consider renaming this file to 0139_add_public_trips.py.

Also, the docstring on line 3 says Revision ID: 981fb62b20ce but the actual revision here is "0139" — should be updated for consistency.

[nabramow]

@aapeliv I am ignoring the migration review failure in this case as it seems to fail if Claude made the change via CouchersBot. When I check the migration itself it works fine.

[github-actions]

📝 Release Notes

This PR does not need to be included in release notes.

Reason: This PR only adds backend database models and a migration for a 'public trips' feature. No frontend implementation, no API endpoints, and no user-facing functionality is included. The PR description explicitly states 'This is only the backend models and migration' and describes a detailed plan for how the feature will work in the future. According to the guidelines, backend infrastructure changes should only be included if they are 'major technical infrastructure' or 'particularly important technical work.' This is preparatory work for a future feature, not a complete implementation. Users cannot see or use anything from this PR.

🤖 Bot Debug Information

Model: anthropic.claude-4.5-sonnet
Decision: exclude
Reasoning: This PR only adds backend database models and a migration for a 'public trips' feature. No frontend implementation, no API endpoints, and no user-facing functionality is included. The PR description explicitly states 'This is only the backend models and migration' and describes a detailed plan for how the feature will work in the future. According to the guidelines, backend infrastructure changes should only be included if they are 'major technical infrastructure' or 'particularly important technical work.' This is preparatory work for a future feature, not a complete implementation. Users cannot see or use anything from this PR.