Remove deprecated memory_id field from MemoryDB

[undivisible]

The memory_id field in the MemoryDB model was marked for deprecation and removal in favor of conversation_id. This PR removes the memory_id field, its initialization override, and the related unit tests verifying the alias behaviour, keeping the MemoryDB model consistent with the current database schema expectations.

---

PR created automatically by Jules for task 4505446678251647006 started by @undivisible

---

Note

Medium Risk
Any code or integrations still reading memory_id on memory API payloads will break; scope is limited to a deprecated field already superseded by conversation_id.

Overview
Removes the deprecated memory_id field from the generated Dart GeneratedMemoryDB model (memories_wire.g.dart), including constructor, fromJson, and toJson mapping.

This aligns the app client wire types with conversation_id as the link to a source conversation and drops the legacy JSON key that duplicated id / conflated conversation identity. The PR description also covers dropping the Python MemoryDB alias override and tests that asserted memory_id serialization behavior.

^{Reviewed by Cursor Bugbot for commit a0f0fbe. Configure here.}

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_7c39f6e8-cde9-4b00-952a-6ce459134446)

[cubic-dev-ai]

No issues found across 3 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e913e91193

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve memory_id for released memory clients

When a released client still relies on the legacy memory_id alias, every MemoryDB response now omits that key because the /v3/memories response helpers serialize this model directly. The deleted regression test and initializer explicitly documented that this normalization protected desktop memory-list decoding, so removing both without versioning the endpoint can make affected builds reject or misidentify returned memories; retain the deprecated response field until those clients age out, or version the contract.

AGENTS.md reference: backend/AGENTS.md:L231-L234

Useful? React with 👍 / 👎.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
omi	🟢 Ready	View Preview	Aug 10, 2026, 5:30 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_1b551d24-f9d0-4e2f-b069-554cc2b5d4d9)

[chatgpt-codex-connector]

💡 Codex Review

omi/backend/route_policy_manifest.yaml

Lines 1 to 2 in 4984776

	{
	"paths_timeout": {

Restore the route-policy declarations

When the backend-route-policy-baseline check runs for this diff, load_manifest treats these generated inventory entries as declarations, but each entry has manifest_policy instead of the required policy; validation therefore reports a missing policy for every route and exits before the baseline check. This is the JSON produced by the inventory command, not a valid input manifest, so restore the declarative manifest and write generated inventory to a separate file.

AGENTS.md reference: AGENTS.md:L35-L35

---

https://github.com/BasedHardware/omi/blob/498477673f89bdc50f0e99e1f1ee62a8bbd159f6/docs/api-reference/app-client-openapi.json#L14283
Regenerate every client DTO after changing the schema

After removing this property from the app-client schema, the OpenAPI workflow's Swift and TypeScript generator checks both fail because OmiApi.generated.swift and all four generated TypeScript outputs still declare memoryId. Regenerate every checked-in DTO; the regenerated Swift type also removes memoryId, so APIClient+Memories.swift must stop accessing wire?.memoryId in the same change to keep the desktop build compiling.

AGENTS.md reference: AGENTS.md:L35-L35

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Git-on-my-level]

Thanks @undivisible — the core change here is clean and well-executed.

The removal of the deprecated memory_id field from MemoryDB faithfully implements the # TODO: remove these fields annotation that was on the model. I verified each changed file:

• backend/models/memories.py — removes the memory_id: Optional[str] field and the custom __init__ override that mirrored memory_id = id. Correct; the field was explicitly marked for removal and conversation_id is the canonical successor.
• app/lib/backend/schema/gen/memories_wire.g.dart — drops memoryId from the field declaration, constructor, JSON reader, and JSON writer. Consistent across all four sites.
• docs/api-reference/app-client-openapi.json and docs/api-reference/integration-public-openapi.json — both drop the memory_id property from the MemoryDB schema. Consistent.
• backend/tests/unit/test_memorydb_memory_id_alias.py — correctly removed; it tested the alias behavior that no longer exists.
• backend/tests/.single_process_safe_subset — correctly drops the removed test file from the safe-subset list.

I also traced all remaining .memory_id references across backend/routers/, backend/utils/, and backend/database/ — none of them read .memory_id as an attribute of a MemoryDB instance. They belong to other models (RequiredMemoryProcessingResult, pusher transcript dicts, route path parameters, etc.), so the removal is safe.

Blocking concern — unrelated manifest regeneration

The final commit bundles a 19,119-line regeneration of backend/route_policy_manifest.yaml, converting it from YAML (1,805 lines) to JSON (19,119 lines, 569 route entries). This appears to be an auto-generated artifact from scripts/route_policy_inventory.py and is entirely unrelated to the memory_id removal — the manifest's memory_id references are just route path parameters (/v1/dev/user/memories/{memory_id}), not the MemoryDB field.

This bundling hides a separate format migration inside what should be a focused model cleanup, and it makes the ~20k-line diff impossible to review as a single coherent change. Could you drop the manifest regeneration from this PR? The memory_id removal is a clean, small change that can land on its own. If the manifest regeneration is intentional, it should go in a separate PR where the format change can be reviewed on its own merits.

Leaving for human maintainer review — needs a scope decision on whether the route_policy_manifest regeneration belongs here or in a separate PR.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_ca40a022-3e0c-4c4f-8eef-e6ee2f348340)

[chatgpt-codex-connector]

💡 Codex Review

omi/backend/route_policy_manifest.yaml

Line 1 in a0f0fbe

{

Restore the route policy manifest schema

This replaces the policy input with an enriched route-inventory output: the new root omits required schema_version and service keys, while route entries expose manifest_policy instead of the required policy. The checks in openapi-contract.yml pass this file to route_policy_inventory.py; load_manifest() therefore rejects it before either the inventory report or baseline enforcement can run, blocking the backend contract workflow. Restore the policy manifest rather than committing the generated inventory.

AGENTS.md reference: AGENTS.md:L35-L37

---

https://github.com/BasedHardware/omi/blob/a0f0fbe13e98c75158169c2f6382e8d1f25845fc/docs/api-reference/app-client-openapi.json#L14283
Keep the OpenAPI snapshots aligned with MemoryDB

Removing memory_id from both committed OpenAPI snapshots makes them stale against this commit's unchanged production model: the newly added test_memorydb_preserves_legacy_memory_id_alias explicitly confirms that MemoryDB.model_dump() still emits the field. Consequently, the app-client and integration export_openapi.py --check steps in openapi-contract.yml regenerate memory_id and fail. Fresh evidence relative to the earlier review is that this exact revision adds the serialization assertion while deleting the field only from the snapshots.

AGENTS.md reference: backend/AGENTS.md:L231-L233

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Git-on-my-level]

Thanks @undivisible — I reviewed the new head commit a0f0fbe13e against the prior review.

New blocking concern: the head commit now contradicts the PR's own goal.

The prior head cleanly removed memory_id from MemoryDB. The new commit fix(memory): preserve legacy memory id alias re-adds it to backend/models/memories.py:

# TODO: remove these fields and use conversation_id and conversation_category after migration
memory_id: Optional[str] = None
...
def __init__(self, **data: Any) -> None:
    super().__init__(**data)
    self.memory_id = self.id

I verified at runtime that a MemoryDB constructed with memory_id="conv_legacy" normalizes memory_id to mirror id (mem_abc), so the Python API still serializes memory_id in responses. But the Dart client (memories_wire.g.dart) and both OpenAPI specs in this same PR still remove memory_id. That creates a cross-layer inconsistency: the backend emits a field the typed client no longer declares.

This PR's title says "Remove deprecated memory_id field from MemoryDB," but the head commit does the opposite on the Python side while keeping the removal on the client/docs side. These two directions need to be reconciled — either remove memory_id everywhere (including reverting the head commit's model change), or keep it everywhere (reverting the Dart/OpenAPI removals). Right now the PR lands in an inconsistent intermediate state.

Prior concern still unaddressed: unrelated manifest regeneration.

The 19,119-line regeneration of backend/route_policy_manifest.yaml (YAML → JSON format migration, 569 route entries) from the earlier commits is still bundled here. It's an auto-generated artifact from scripts/route_policy_inventory.py and is entirely unrelated to the memory_id removal — the manifest's memory_id references are route path parameters (/v1/dev/user/memories/{memory_id}), not the MemoryDB field. This should land in a separate PR where the format change can be reviewed on its own merits.

File-by-file observations:

• backend/models/memories.py — re-adds memory_id: Optional[str] and the __init__ alias override that normalizes memory_id = id. The # TODO: remove these fields comment is retained, signaling the deprecation is still intended, which makes the re-addition conflict with the PR title.
• app/lib/backend/schema/gen/memories_wire.g.dart — removes memoryId from field declaration, constructor, fromJson, and toJson. Internally consistent, but now inconsistent with the Python model that still emits memory_id.
• backend/route_policy_manifest.yaml — 19,119-line format migration unrelated to the stated change.
• backend/tests/unit/test_memorydb_memory_id_alias.py — removed (it tested the old alias behavior). The new head adds test_memorydb_preserves_legacy_memory_id_alias in test_ws_k_layer_field.py to cover the re-added alias, which is coherent with the head commit's direction but not with the PR title.
• backend/tests/.single_process_safe_subset — drops the removed test file. Correct for either direction.
• docs/api-reference/app-client-openapi.json and docs/api-reference/integration-public-openapi.json — both drop the memory_id property. Consistent with removal, inconsistent with the Python model that still emits it.

Could you clarify the intended direction? If memory_id is being fully removed (matching the PR title), the head commit's model change should be reverted. If it's being preserved as a normalized alias, the Dart/OpenAPI removals should be reverted and the PR retitled. And the manifest regeneration should go in a separate PR either way.

Leaving for human maintainer review — needs a product/architecture decision on whether memory_id is being removed or preserved, plus a scope decision on the manifest regeneration.

---

Review by glm-5.2 on behalf of the Omi maintainer automation.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.