The parts array should be correctly handled in Gemini API

[doedel123]

The problem

Of course! Here is a clear and detailed bug report in English, formatted for posting as a GitHub issue. You can just copy and paste the entire text.

---

Bug Report: Add-on crashes with "TypeError: parts is undefined" on safety-filtered API responses

Describe the bug
The add-on stops processing incoming emails after successfully categorizing a few. This happens consistently when using a paid Google Gemini API key. The developer console shows a TypeError that crashes the processing script, preventing further emails from being categorized.

To Reproduce
Steps to reproduce the behavior:

1. Set up the add-on with a valid, Pay-as-you-go Google Gemini API key.
2. Let the add-on run on incoming emails.
3. It will successfully process a few (usually 2-3) of the most recent emails.
4. The process then silently stops.
5. Open the developer console (Tools > Developer Tools > Developer Toolbox) and the following error is visible:

TypeError: can't access property 0, parts is undefined
    at model-worker-google_gemini.js:120:34

Expected behavior
The add-on should process all emails. If an email cannot be processed for any reason (like an API error or content filter), it should gracefully skip that single email and continue with the next ones, possibly logging a warning to the console.

Analysis and Likely Cause
This is not a quota issue. The problem seems to be related to how the add-on handles responses from the Gemini API when its safety filters are triggered.

1. When an email's content is flagged by Google's safety filters (e.g., for harassment, hate speech, spammy content, etc.), the Gemini API does not return the normal response structure containing a parts array.
2. Instead, the API returns a response indicating that the content was blocked, for example, with a finishReason of "SAFETY". This response object will not contain a candidates[0].content.parts array.
3. The add-on's current code appears to assume every API call will be successful and directly attempts to access ...parts[0].
4. When it receives a safety-blocked response, parts is undefined. The attempt to access parts[0] throws the fatal TypeError, which crashes the entire script and stops the email processing loop.

Suggested Solution
The code needs to be made more robust by adding error handling to validate the API response before processing it.

A possible fix would be to check for the existence of response.candidates and its nested properties before trying to access them. Specifically, the add-on should check the finishReason. If the reason is "SAFETY", it should handle it as a valid (but empty) result, skip the email, and move on to the next one.

Example of a check:

// Before trying to access parts...
if (response.candidates && response.candidates.length > 0 && response.candidates[0].finishReason === 'SAFETY') {
  console.warn('Gemini API request was blocked due to safety settings. Skipping email.');
  // Continue to the next email instead of crashing
} else if (response.candidates && /*...the rest of the successful path check */) {
  // Process the response as normal
}

Thank you for your work on this very useful add-on! I hope this report helps in resolving the issue.

Which Operative System are you using?

MacOSX

Which version of Thunderbird are you using?

14.20

Which version of ThunderAI has the issue?

3.7.0

Which integration are you using?

Google Gemini API

Anything in the Thunderbird console logs that might be useful?

See Issue

Additional information

No response

[micz]

Thank you for your report, I'll work on it and release here a fix for you to test.

[micz]

You can find here version 3.7.0_issue_514 that should fix this problem, that I was not able to reproduce.

Please follow this steps:

1. Download the file thunderai-v3.7.0_issue_514.zip
2. Rename it from *.zip to *.xpi
3. Backup your custom prompts and custom data placeholders if you have any
4. Install this version

Let me know, thanks!

[micz]

Fixed in version 3.7.1.