fix: handle 404 for missing Gmail labels in thread sync

[Shekhar0109]

Description

This PR fixes Issue #28 where the Gmail incremental sync was failing with a 404 error whenever a label no longer existed. Previously, this caused the sync to stop completely, even if other labels were still valid.

Changes Made

• Wrapped the Gmail History API call in a try-except block to catch googleapiclient.errors.HttpError.
• Specifically handle the notFound reason when a label is missing.
• Remove the missing label from gmail_account.label_ids and commit the change.
• Continue syncing other labels instead of stopping the process.
• Other HTTP errors are still raised normally to avoid hiding real issues.

Why

This ensures that the sync process is robust: missing labels are handled gracefully without interrupting the sync of other valid labels.

Relevant Technical Choices

• Used a flag to safely skip missing labels without breaking the outer loop.
• Maintained existing behavior for unexpected errors by re-raising them.

Testing Instructions

1. Set up a Gmail account with at least one label missing from the database.
2. Run the gmail_thread.sync method.
3. Verify that:
   • The missing label is removed from gmail_account.label_ids.
   • Sync continues for all other labels without raising exceptions.
4. Confirm that no other labels are affected.

Additional Information

• This fix ensures that the Gmail incremental sync does not stop entirely if a label is deleted or missing.
• Related issue: Issue #28

Checklist

• I have carefully reviewed the code before submitting it for review.
• This code is adequately covered by unit tests to validate its functionality.
• I have conducted thorough testing to ensure it functions as intended.
• A member of the QA team has reviewed and tested this PR (To be checked by QA or code reviewer)

Fixes #28

[Copilot]

Pull request overview

This PR addresses Issue #28 where Gmail incremental sync fails with a 404 error when a label no longer exists. The fix wraps the Gmail History API call in a try-except block to catch and handle missing labels gracefully, allowing the sync to continue with other valid labels.

Changes:

• Added exception handling for HttpError with "notFound" reason in the Gmail history API call
• Introduced logic to remove missing labels from the Gmail account and continue syncing other labels
• Replaced the previous behavior of resetting history ID and stopping sync entirely

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[shivamsn97]

@Shekhar0109

Thanks for contributing.

See this issue: #37 (comment)

The exception handling assumes all "notFound" errors are due to missing labels, but a 404 could also occur if the startHistoryId is invalid or too old. The previous code handled this by resetting last_historyid to 0. Consider checking if the label actually exists first (e.g., by calling the labels().get() API) before assuming the label is missing, or add additional logic to distinguish between label-not-found vs history-not-found scenarios.

This is a valid argument. There may be errors beside just Label not found, and cannot remove a label just because sync throw an error. Also, can you please also confirm if having a incorrect label actually throws the notFound error. The error shown in the issue does not explicitly mentions that the error was due to a incorrect label, this conclusion was just assumed. So it would be better to confirm once if having a wrong label actually throws an error currently.

[Shekhar0109]

Thanks for the review.

I have updated the 404 handling logic to properly distinguish between an expired startHistoryId and a genuinely missing label.

On receiving a 404:

• The code now verifies label existence via the Gmail Labels API.
• If the label exists, last_historyid is reset (preserving previous behavior).
• If the label does not exist, it is removed and sync continues for other labels.

Regarding confirmation: I tested the behavior and confirmed that an invalid/expired startHistoryId also results in a 404. Therefore, explicit label verification was added to avoid incorrect removal.

Please let me know if any additional changes are needed.

[shivamsn97]

@Shekhar0109 Thanks for the prompt resolution. I'll test it on my local in a few days and if everything goes well, we'll merge it.