Summary

When testing gemini_generate_image in a real Gemini image-generation flow, the generation appears to proceed, but the final delivery fails at the download step with:

download_timeout

So this does not look like a total image-generation failure. It looks more like:

• generation path is working (or at least progresses far enough),
• but the post-generation download/export step is timing out.

Environment

• Repo: WJZ-P/gemini-skill
• Deployment path: /home/aimcafe/.openclaw/workspace/projects/gemini-skill
• Logged-in Gemini session confirmed via gemini_check_login
• Browser/daemon path had already been set up and was functioning

What I tested

Prompt was a one-page original Korean-webtoon-style comic scene (custom prompt content, no IP dependency required for reproducing the issue).

1) First attempt

Called:

• gemini_generate_image

Observed failure:

Call to gemini.gemini_generate_image timed out after 60000ms

This first failure turned out to be the outer mcporter call timeout, not necessarily the tool itself.

2) Second attempt with longer outer timeout

Retried with:

• MCPORTER_CALL_TIMEOUT=240000
• mcporter call ... --timeout 240000
• tool args still used timeout=180000

This removed the outer 60s call timeout issue.

Observed final result:

生成失败: download_timeout

Current diagnosis

This seems to narrow the problem down to the download stage of:

• gemini_generate_image(fullSize=true)

So the current behavior appears to be:

1. image generation flow starts,
2. tool reaches post-generation retrieval/download logic,
3. full-size image download times out,
4. final file is not delivered back successfully.

Why I think generation itself is likely succeeding

From the user-side observation during testing, the image appeared to have been generated in Gemini UI, but the tool did not complete the final download/save handoff.

Combined with the shifted error mode:

• first: outer call timeout,
• then: internal download_timeout,

it strongly suggests the bottleneck is now in the skill's download/export path rather than initial generation.

Suggested areas to inspect

Possibly worth checking:

1. selector / readiness logic for the generated image download button
2. wait timeout for full-size image availability
3. browser download event handling / download directory monitoring
4. whether fullSize=true is specifically unstable while preview extraction may still work
5. whether the image is already present in the page but the tool is failing specifically in the full-size download branch

Useful follow-up tests

It may help to split the pipeline and compare:

1. generate image
2. gemini_get_images
3. gemini_extract_image
4. gemini_download_full_size_image

That would help determine whether:

• only full-size download is broken,
• or image extraction from the page is also affected.

Repro result (final)

After increasing the outer timeout sufficiently, the stable reproduced failure is:

生成失败: download_timeout

If needed, I can also provide the exact prompt and call form used in testing, but I wanted to report the core issue first since the failure appears unrelated to prompt semantics.