Shared instance install falsely reports public version IDs as not found and rolls back

[snapss-dev]

Please confirm the following

• I checked existing issues for this specific shared-instance install failure.
• I searched the support portal for this error and found no applicable resolution.
• The recipient is using Modrinth App 0.21.5, the latest release at the time of this report.

Modrinth App version

0.21.5

Operating system

Windows 11 Home, x86_64, build 26200.

Describe the bug

A recipient cannot install a large native shared instance. create_shared_instance fails during downloading_content with content_error and rolls back the new instance:

Invalid input: Unable to install version id TuD0Zvi3. Not found.

TuD0Zvi3 is a public, listed Deeper and Darker NeoForge 1.21.1 version. Both GET /v2/version/TuD0Zvi3 and GET /v2/versions?ids=["TuD0Zvi3"] return HTTP 200 with that version's metadata from a separate machine. An earlier attempt by this recipient failed on another valid, listed version, Polytone 7XQzQ6wF. The owner removed that version ID from the shared manifest and supplied the same jar as an uploaded external file; the next attempt then failed on TuD0Zvi3. Other recipients have seen the same error on public versions Ez3cx7Yd and d0DQw3ik.

The failed install leaves no pack instance because rollback completes. Purging the App cache between attempts did not resolve this recipient's problem. The owner has verified that all 448 currently referenced Modrinth version IDs resolve through the public batch API, with no duplicate project IDs. The live shared version reports ready: true.

Steps to reproduce

1. Publish a private native shared instance with approximately 450 Modrinth-managed versions and about 50 uploaded files.
2. On Modrinth App 0.21.5 for Windows, accept the invite and create a new shared instance.
3. The install begins downloading Minecraft 1.21.1 with NeoForge, then fails during content download with the message above and rolls back.
4. Purge the App cache and retry; the error persists or moves to another valid version ID.

The invite is private and includes licensed third-party content, so I have not posted it publicly. I can provide it privately to maintainers if needed.

Expected behavior

The app installs publicly resolvable listed versions and finishes creating the instance. If a metadata request fails transiently, the app should retry or surface the actual upstream error rather than report a valid version as absent.

Additional context

One documented failed job was 96e3405f-e5ae-49c9-b635-2063a67f7170 at 2026-09-25 01:41 UTC. It failed on 7XQzQ6wF and completed rollback. A later attempt against the updated share failed on TuD0Zvi3. The full recipient session log is being requested; I can add sanitized excerpts when available.

This appears to be the initial shared-instance install path, not a Minecraft launch or mod compatibility error. The exact cause of the false lookup is not yet established.

[snapss-dev]

Additional retry on the same recipient and shared revision failed on a third public version ID:

2026-09-25 02:14:32–02:14:52 UTC
content_error / downloading_content
Invalid input: Unable to install version id 1sdJl7J1. Not found.
Rollback completed.

1sdJl7J1 is Bookshelf NeoForge 1.21.1 (uy4Cnpcm). It is present in the ready shared manifest and both the public single-version and batch-version v2 endpoints return HTTP 200 with its metadata. It is at position 60 of the 448 managed IDs, while the prior failures occurred on other positions. This further supports an intermittent lookup/installer problem rather than a particular unavailable mod version.

[snapss-dev]

More recipient reports on App 0.21.5 / Windows 11 Home x86_64 build 26200, September 26. Two fresh create_shared_instance attempts against a ready private share failed on different public versions:

UTC interval	Version ID	Mod	Failure
21:48:34–21:49:34	gKqw2akx	Create: Prismatic Shine 1.2.2, NeoForge 1.21.1	content_error / downloading_content
21:52:51–21:53:59	5P5tLHSh	Cut Through 21.1.0, NeoForge 1.21.1	content_error / downloading_content

Both reports end in Invalid input: Unable to install version id <ID>. Not found. followed by successful rollback. Jobs: 0dc3b11a-a0a0-4f8b-829f-91d63dfd1da1 and ee642ffe-9223-4eff-b0ea-bfee8203b2dd.

From the owner's machine, both single-version requests and the public batch endpoint returned HTTP 200 for these IDs. Both direct CDN downloads also returned HTTP 200 and matched their published SHA-512 hashes. These checks are from a separate machine; they do not establish what the affected recipient's API/cache received. The available recipient session excerpts contain only launcher initialization, so we still cannot identify the internal lookup/cache failure.

There is also a distinct existing-instance blocker on the same App version:

2026-09-26 21:43:00–21:43:03 UTC
update_shared_instance / instance_error / preparing_instance
Invalid input: Restore or repair mods/DistantHorizons-3.3.2-1.21.1.jar
before updating this instance; its current content cannot be backed up safely
Rollback completed.

Job bf3fdd07-490b-4445-96ec-74c350aaeaa2. On the publisher's earlier local copy, a customized jar could match instance_files.sha1 while still having an obsolete store_instance_files binding; Verify/repair also restored previously removed jars from old content records. The new recipient report does not prove that exact mismatch, since we do not have their database. It does show the update is blocked before applying the new shared revision. The affected jar is currently distributed as an external file; its archive entries are unchanged and only a ZIP comment differs from upstream.

We have reproduced that stale-binding case on an isolated copy and can repair the single file/record without touching DH LOD databases. A local patcher is being tested as a fallback. We are also testing a native share containing direct external uploads instead of managed version IDs to avoid the failing per-version install path; recipient success for that workaround is not yet confirmed.

Could the installer log the actual failing lookup response/cache state and distinguish an absent version from a transient/cache lookup failure? A per-file repair action for the backup guard would also help avoid global Verify/repair altering unrelated removed mods. I can supply the private share to maintainers privately; no licensed content or recipient usernames/paths are attached here.

Update: attempting a native revision with all 505 content/config entries as external uploads was accepted initially, but subsequent uploads returned HTTP 400: Bad Request: Files exceed limit for instance version. Try again with less files. That revision never became ready; GET latest still returns the previous ready revision. This means all-external uploading is not a workable general fallback for this pack. We are keeping a direct mrpack/install-update fallback while the version lookup issue is investigated.