Repository navigation
feat: provenance, nonblocking local ingestion and stable entities - #3
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aae34c5d9c
ℹ️ 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".
| correction = next((c for c in data["corrections"] if c["entity_id"] == eid | ||
| and ".".join(re.findall(r"[a-z0-9]+", c["attribute_key"].lower())) == attribute), None) |
There was a problem hiding this comment.
When a correction uses the exact underscore-form attribute emitted by the writer, such as room_location, only the declaration is normalized to room.location; the assertion remains room_location, so the correction is silently ignored. The constrained schema permits underscores and the prompt even demonstrates stable_attribute, making this a normal input that causes correction history to fall back to the source timestamp and omit the declared reason. Normalize the assertion attribute with the same wire-key function before comparing.
Useful? React with 👍 / 👎.
| raise | ||
| status = self.store.scope_status(message["message_id"], scope_id) | ||
| statuses.append(dict(status or {})) | ||
| self.jobs.finish(message['message_id'], 'indexed') |
There was a problem hiding this comment.
When an async job is retryable_failed or permanent_failed, reposting the same immutable message to the synchronous /v1/messages endpoint bypasses retry_job's confirmation and three-attempt limit: ingest_message deletes the failed scope state, issues another model call, and this unconditional update marks the existing job indexed without incrementing its attempt ledger. This can occur after switching an integration from async to sync or when mixed clients submit the same identity, defeating the bounded explicit-retry contract; synchronous replay should reject failed queued identities or route them through the same confirmed retry accounting.
Useful? React with 👍 / 👎.
Summary
Validation
Deployment
No cloud deployment. Local plugin and model remain disabled; installation will be updated from verified merged main without starting services.