feat(logs): add log type for sync variant creation/deletion#6012
Conversation
There was a problem hiding this comment.
1 issue found across 7 files
Confidence score: 2/5
- There is a high-confidence, high-severity risk in
packages/server/lib/controllers/sync/deleteSyncVariant.ts: if post-delete logging throws, the endpoint can still return a failure after the sync variant has already been removed. - This creates concrete user-facing inconsistency (client sees an error while data is already deleted), which raises regression and recovery risk enough to avoid calling this a safe merge yet.
- Pay close attention to
packages/server/lib/controllers/sync/deleteSyncVariant.ts- ensure logging errors are isolated so they don’t fail the delete flow after the primary operation succeeds.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/server/lib/controllers/sync/deleteSyncVariant.ts">
<violation number="1" location="packages/server/lib/controllers/sync/deleteSyncVariant.ts:75">
P1: Do not let post-delete logging failures fail this endpoint after the sync variant is already deleted.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f1d7fe2d18
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| integration: providerConfig?.unique_key ?? body.provider_config_key, | ||
| syncId: sync.id | ||
| }); | ||
| await logCtx.success(); |
There was a problem hiding this comment.
the log operation/info should reflect the actual result of the deletion (failure or success)
There was a problem hiding this comment.
Hmm... the operation is always successful at this point since I do the log just at the end. I was originally thinking this was just to show a quick trail of successful operations, not show failed requests since they will see the failure mode in the response body immediately and then retry.
What do you think? Should I render logs for all the failed requests as well with specific context on why the request failed?
There was a problem hiding this comment.
I think failed deletion should also be reported. Don't you think?
There was a problem hiding this comment.
I've been going back and forth here tbh since it seems like extra noise and isn't something we do for other APIs currently, but I suppose you're right. I'll make the update and ping you when it's done.
There was a problem hiding this comment.
isn't something we do for other APIs currently
Which API endpoints are reporting successful operations but not failed ones?
There was a problem hiding this comment.
Sorry, I just meant not all API endpoints are represented in the logs (e.g. GET /records). So I wasn't initially sure if complete coverage of different error codes in the log output made sense, or if it was just noise.
I agree with you though and I've updated to output specific messages and the correct log type based on what happens in the endpoint. Let me know if there's any additional context I should be attaching to the logs here though.
…t-creationdeletion
…t-creationdeletion
…s available to logger
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 46191f2d17
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
1 issue found across 2 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/server/lib/controllers/sync/deleteSyncVariant.ts">
<violation number="1" location="packages/server/lib/controllers/sync/deleteSyncVariant.ts:68">
P1: The guard preventing deletion of the protected `base` variant was removed during this refactoring. Previously, the handler returned `invalid_variant` for `variant=base`; now requests proceed directly to `softDeleteSync`. Add back the check (as done in `postSyncVariant`) before processing the deletion to prevent removing a connection's canonical sync variant.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic.
💡 Codex Reviewnango/packages/server/lib/controllers/sync/postSyncVariant.ts Lines 178 to 186 in 1a4e79d
ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
…t-creationdeletion
This is mainly to give more visibility for support investigations. Full context from Kelvin here |
Add log type for sync variant creation/deletion
NAN-5419: Add log type for sync variant creation/deletion
-Create/delete sync variant via API
-See new logs