So...this is going to be very weird, but first some context.

I develop Modlist UI, and long story short, to facilitate effective mod-thumbnail display in-game, I scrape key bits of metadata of every Factorio 2.0 & 2.1 mod on the mod portal. To deal with the 2.0 end of 2.x spanning mods, I download the zip files and inspect the thumbnails inside, just in case a 2.0 version of a mod does not have a thumbnail or a differently sized one, than its 2.1 counterpart. (The modportal uses the globally latest mod-version for the thumbnail, usually "owned" by a 2.1 version, hence the issue trusting only the 2.1 metadata).

The bug I have found, which crops up only in [Fulgora Orbital Defence] is the following ZIP failure output by the npm package [yauzl] (Yet Another UnZip Library):

[2.x ZIP fail] fulgora-orbital-defence: Invalid comment length. Expected: 1. Found: 0. 
Are there extra bytes at the end of the file? Or is the end of central dir signature `PK☺☻` in the comment?

There are 2775 2.x spanning mods, and only yours has this issue. Is it something worth investigating and pushing a 2.0 fix for? It might just come down to a simple clean re-zip of everything, using something widespread like 7Zip or WinRar or so.

I have an inkling of an idea why that came about, but its from a release 2 months ago so I'll blame that in case I'm wrong. I normally use 7Zip when creating the archives for uploading and as a final playtest to make sure I don't break anything (version number mismatch being a common mistake), and corruption selective enough to break yauzl but not in game play is surprising. I'm guessing I may have tried to edit the changelog or another file within the archive post creation, and that failed the integrity check? Its the only novel archive task I can think of that can affect the zip but not the content.

I loaded up ModlistUI and confirmed with the version check that the 2.0 thumbnail is missing, but not 2.1. I've repackaged the archive under the 1.0.5 release (using 7Zip). No thumbnail changes were made, and the icon remains the same in both 2.0 and 2.1 branches. Hopefully during the next blob update this will clear, as I am not sure how I can gracefully test without updating the public releases.

Thanks for this! Even if you hadn't updated, I took it upon myself to make a few surgical edit tools for my local cache, and manually built a [2.0] entry for Fulgora Orbital Defence. Still, ran the scraper and you'll be happy to know it had no issue this time. Changes should be reflected in the next blob update of Modlist UI.

Feel free to consider the matter resolved. 💯

// factorio-modportal-scrape.js

[2.1 portal] 92/92 ok=86 fail=0
[2.0 portal] 33/33 ok=121 fail=0
[2.x ZIP] 12/12 ok=10 fail=0

[done] portal ok/fail: 125/0
[done] ZIP ok/fail:    12/0
[done] completed in 30s

// factorio_modportal_cache.json

    "fulgora-orbital-defence": {
      "2.1": {
        "title": "Fulgora Orbital Defence",
        "author": "Starchie",
        "category": "content",
        "description": "Fulgora had an ancient civilisation.  Their planetary defence remains in orbit to welcome you.  Conquer their space manufactory to learn how to make your own versions.",
        "latest_version": "1.1.1",
        "has_thumbnail": true,
        "thumbnail_source": "portal",
        "last_scraped": "2026-08-13T16:08:20.312Z",
        "thumbnail_w": 147,
        "thumbnail_h": 143,
        "thumbnail_size": 143,
        "thumbnail_ext": ".png"
      },
      "2.0": {
        "title": "Fulgora Orbital Defence",
        "author": "Starchie",
        "category": "content",
        "description": "Fulgora had an ancient civilisation.  Their planetary defence remains in orbit to welcome you.  Conquer their space manufactory to learn how to make your own versions.",
        "latest_version": "1.0.5",
        "has_thumbnail": true,
        "thumbnail_source": "zip",
        "last_scraped": "2026-08-19T21:00:36.569Z",
        "thumbnail_version": 1,
        "thumbnail_w": 147,
        "thumbnail_h": 143,
        "thumbnail_size": 143,
        "thumbnail_ext": ".png"
      }

Glad to hear it got resolved in the next automated scrape! I appreciate the manual fix, but its nice to know that the automation works as it should now.