Fix generic string object update dependencies#12082
Conversation
Ensure all generic string object update queue items depend on prior create/update operations for the same object so updates cannot race ahead before a client ID is mapped to a server UID. Co-Authored-By: Oz <oz-agent@warp.dev>
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR routes additional generic string object update variants through sync queue update dependencies and adds coverage for an AIFact create/update dependency chain.
Concerns
- Queued generic string object updates can now wait behind earlier updates, but their stored revisions are not refreshed after the earlier update succeeds, so a second queued update can still be sent with a stale revision.
Verdict
Found: 0 critical, 1 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
Replace the no-dependency catch-all in add_inferred_dependencies with explicit queue item variants so future QueueItem additions must make an intentional dependency decision. Co-Authored-By: Oz <oz-agent@warp.dev>
Update queued generic string object revisions after create/update successes so chained dependent updates use the latest revision before dequeuing. Co-Authored-By: Oz <oz-agent@warp.dev>
|
/oz-review |
|
I'm re-reviewing this pull request in response to a review request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR makes generic string object update variants participate in sync queue update dependencies and propagates successful revisions to queued updates. The single-create path is covered by the new test.
Concerns
- Bulk generic string object creates still share one queue item dependency for all objects in the batch; routing the newly added update variants through
get_update_dependenciescan unblock updates for later batch objects after the first create success is processed, before those later client IDs have been mapped.
Verdict
Found: 0 critical, 1 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
| | QueueItem::UpdateAIFact { id, .. } | ||
| | QueueItem::UpdateMCPServer { id, .. } | ||
| | QueueItem::UpdateAIExecutionProfile { id, .. } | ||
| | QueueItem::UpdateTemplatableMCPServer { id, .. } |
There was a problem hiding this comment.
BulkCreateGenericStringObjects, but bulk create success reuses one queue item id for the whole batch. handle_dependency_success clears that id after the first created object is processed, so an update for a later object in the same batch can dequeue before its client ID/revision mapping is installed and fail with the same missing-object path this PR is trying to prevent. Please process all bulk create mappings before unblocking/dequeueing dependents, or track bulk dependencies per object.
|
/oz-review |
|
I'm re-reviewing this pull request in response to a review request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR extends sync queue dependency inference so generic string object update variants wait for prior create/update work on the same object, and it adds per-client dependency tracking for bulk generic string object creates so a bulk queue item can unblock only the matching dependent updates as each object resolves.
Concerns
No blocking correctness, security, or spec-alignment concerns found in the annotated diff. No approved or repository spec context was available for this PR.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
Description
Fixes a sync queue dependency gap where several generic string object update variants did not wait for earlier create/update queue items for the same object.
When a local generic string object was created and then updated before the create response mapped its client ID to a server UID, the update could race ahead and call
UpdateGenericStringObjectwith a UID the server could not find. That matches the observed GraphQL error:graphql response for Some("UpdateGenericStringObject") had errors ... "Not found: Object UID not found"This change routes all generic string object update variants through
get_update_dependencies, including AIFact, MCPServer, AIExecutionProfile, and TemplatableMCPServer.Linked Issue
Slack thread: feedback-app
1780425090.994989ready-to-specorready-to-implement.Testing
cargo test --manifest-path /workspace/warp/Cargo.toml -p warp test_sync_queue_generic_string_object_update_depends_on_pending_createcargo test --manifest-path /workspace/warp/Cargo.toml -p warp sync_queue_dependencygit -C /workspace/warp --no-pager diff --checkcargo fmt --manifest-path /workspace/warp/app/Cargo.toml -- --checkI have manually tested my changes locally with
./script/runAgent Mode