Skip to content

feat(logs): add log type for sync variant creation/deletion#6012

Merged
rbwest merged 13 commits into
masterfrom
ryan/nan-5419-add-log-type-for-sync-variant-creationdeletion
May 12, 2026
Merged

feat(logs): add log type for sync variant creation/deletion#6012
rbwest merged 13 commits into
masterfrom
ryan/nan-5419-add-log-type-for-sync-variant-creationdeletion

Conversation

@rbwest
Copy link
Copy Markdown
Contributor

@rbwest rbwest commented Apr 30, 2026

Add log type for sync variant creation/deletion

Screenshot 2026-04-30 at 4 37 57 PM Screenshot 2026-04-30 at 4 38 16 PM Screenshot 2026-04-30 at 4 38 40 PM

NAN-5419: Add log type for sync variant creation/deletion

-Create/delete sync variant via API
-See new logs

@linear
Copy link
Copy Markdown

linear Bot commented Apr 30, 2026

Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread packages/server/lib/controllers/sync/deleteSyncVariant.ts Outdated
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread packages/webapp/src/pages/Logs/constants.tsx
@rbwest rbwest requested a review from a team April 30, 2026 20:35
integration: providerConfig?.unique_key ?? body.provider_config_key,
syncId: sync.id
});
await logCtx.success();
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the log operation/info should reflect the actual result of the deletion (failure or success)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think failed deletion should also be reported. Don't you think?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't something we do for other APIs currently

Which API endpoints are reporting successful operations but not failed ones?

Copy link
Copy Markdown
Contributor Author

@rbwest rbwest May 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread packages/server/lib/controllers/sync/deleteSyncVariant.ts
Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread packages/server/lib/controllers/sync/deleteSyncVariant.ts Outdated
@superagent-security superagent-security Bot added contributor:flagged Contributor flagged for review by trust analysis. pr:verified PR passed security analysis. labels May 6, 2026
@chatgpt-codex-connector
Copy link
Copy Markdown

💡 Codex Review

await orchestrator.scheduleSync({
nangoConnection: connection,
sync,
providerConfig,
syncName: sync.name,
syncVariant: sync.variant,
syncData,
logContextGetter
});

P2 Badge Mark variant operation failed when scheduling throws

logCtx is created at the start of this handler, but scheduleSync is awaited without a surrounding try/catch. If the orchestrator call rejects (for example due to orchestrator downtime), asyncWrapper will route the error to Express and return a 500 while this log operation never calls logCtx.failed(), leaving it stuck in running state. This introduces inaccurate Logs data for the new sync:create_variant operation and makes failed variant creations look in-progress indefinitely.

ℹ️ 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".

Comment thread packages/server/lib/controllers/sync/deleteSyncVariant.ts
Comment thread packages/server/lib/controllers/sync/deleteSyncVariant.ts Outdated
@superagent-security superagent-security Bot added contributor:verified Contributor passed trust analysis. and removed contributor:flagged Contributor flagged for review by trust analysis. labels May 6, 2026
Copy link
Copy Markdown
Collaborator

@TBonnin TBonnin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an overall question around why create/delete variant appears in the Nango logs while most of the other API operations don't but code lgtm

@rbwest rbwest added this pull request to the merge queue May 12, 2026
@rbwest
Copy link
Copy Markdown
Contributor Author

rbwest commented May 12, 2026

There is an overall question around why create/delete variant appears in the Nango logs while most of the other API operations don't but code lgtm

This is mainly to give more visibility for support investigations. Full context from Kelvin here

Merged via the queue into master with commit 3c7000a May 12, 2026
26 checks passed
@rbwest rbwest deleted the ryan/nan-5419-add-log-type-for-sync-variant-creationdeletion branch May 12, 2026 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contributor:verified Contributor passed trust analysis. pr:verified PR passed security analysis.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants