All QDN resource loads return HTTP 500 in Home after Core v1.6.1 update

[QuickMythril]

Summary

A user reports that every QDN resource load in Qortium Home returns HTTP 500 after updating to the newest Core. The problem began only after the Core update.

This is high impact because Home cannot open any QDN content, but the rest of the node is not completely offline: the reporter can still mint, publish apps, and receive a Publish app notification when a new publish becomes live.

Reported sequence

1. The automatic Core update failed.
2. The reporter installed the newest Core using the controls on the Home Settings page.
3. After that installation, Home began returning HTTP 500 when trying to load any QDN resource.
4. Minting still works.
5. Publishing still works.
6. A newly published resource reached live status and triggered its Publish app notification, but Home still could not load QDN content.

Reporter wording:

I cannot use Qortium. I keep getting a 500 when trying to load anything QDN. It only started after updating to the newest Core. The auto update failed, so I installed from the Home Settings page buttons. It looks like I can still mint and publish apps, and I got a notification when the new publish went live, but Home still 500s on everything. It makes me think the new Core is fine but Home cannot talk to it for some reason.

Expected behavior

After a Core update, existing and newly published QDN resources should download and render in Home.

Current evidence

• This has not been reproduced as a network-wide failure. A synced local Core 1.6.1 node can currently render Chat, Help, and a reported QDN image.
• Ordinary unavailable QDN data currently produces HTTP 503 or QDN error 1401 / HTTP 404. The reported HTTP 500 is therefore important and may indicate a different path, such as Core rendering, the post-update runtime/install state, or Home render authorization/proxying.
• Core v1.6.1 and Home v1.6.1 are intended to be updated together: https://github.com/QortiumDev/qortium-home/releases/tag/v1.6.1

Information requested from the reporter

Thanks for helping us narrow this down. Please reproduce one failed Chat load and paste the following information. Do not post an API key, wallet backup, seed phrase, private key, password, or a complete settings file.

1. Platform and versions

• Operating system and version:
• Qortium Home version:
• How Home was installed or updated:
• Exact automatic-update failure message, if still available:
• Output of:

curl http://127.0.0.1:24891/admin/info
curl http://127.0.0.1:24891/admin/status

On Windows PowerShell, use curl.exe instead of curl if needed.

2. Direct Core checks

While Home is displaying the QDN failure, run:

curl -i http://127.0.0.1:24891/arbitrary/resource/status/APP/Chat/Chat
curl -i http://127.0.0.1:24891/render/APP/Chat/Chat

Please paste the HTTP status, headers, and response body from both commands. Also provide one other exact QDN address that fails, if available.

These results identify the failing layer:

Direct Core result	Likely investigation path
/render/APP/Chat/Chat returns 500	Core install/runtime/rendering failure
It returns 503 and status is PUBLISHED or MISSING_DATA	QDN chunk discovery/data-peer failure
It returns 200 while Home displays 500	Home authorization/proxy/API-key integration failure

3. Logs from one failed load

Please attach or paste:

• The exact error displayed by Home, including any response body.
• The qortium.log lines from roughly one minute before through one minute after the failed load.
• If the direct Core render returns 200 but Home still fails, any Home developer-console error for the same attempt.

Please redact usernames or parent directory names from local paths if desired.

4. Relevant runtime facts

Please provide only these settings or observed values, not the full settings file:

• qdnEnabled
• dataPath leaf directory name and whether it is the same directory used before the update
• Size of that QDN data directory
• storagePolicy
• maxStorageCapacity
• allowedTransports
• maxDataPeers
• Whether Home shows the local Core as running and synced

Investigation guardrail

Please do not delete the QDN data directory, reset the database, or reinstall again before collecting the direct responses and logs above. The failed automatic update followed by a manual Settings-page installation is useful evidence, and cleanup could erase the cause.

[7r15]

Qortium Home showed "The last automatic check had a problem: EPERM: operation not permitted, rename 'C:\Users\7r15\AppData\Roaming\qortium-core\install' -> 'C:\Users\7r15\AppData\Roaming\qortium-core_install-backup-1785335101642'" before autoupdate failed. Manually updated user the Qortium Home install core button. After update, core setting in home show "The last automatic check had a problem: <title>Error 500 Internal Server Error</title>

HTTP ERROR 500 Internal Server Error

URI:	/admin/update
STATUS:	500
MESSAGE:	Internal Server Error
SERVLET:	org.glassfish.jersey.servlet.ServletContainer-4c063cb9

---

Powered by Jetty:// 12.1.11

---

"

That error means the request reached Qortium Core's API server, but the server crashed while handling it - it's not a network/connectivity problem, it's a bug or bad state on the core side. Breaking down the pieces:

URI: /admin/update - this is the admin API endpoint Qortium Home calls to trigger a core update (the "manual update" button).
SERVLET: org.glassfish.jersey.servlet.ServletContainer - Jersey is the REST framework Qortium Core uses for its API layer.
Jetty 12.1.11 - the embedded web server core uses to serve that API.
So: Jetty and Jersey are both up and responding (core itself is running), but the Java code behind /admin/update threw an uncaught exception, and Jersey caught it generically and returned a bare 500 instead of the update actually happening. The HTML you got is just Jetty's default error page - it has no details about the actual exception, which is logged server-side, not returned to the client.

Likely causes:

The auto-updater left the update directory/lock in a partial or inconsistent state, and the manual trigger's code path throws when it hits that state (e.g. a missing file it expects, or a lock already held).
A permissions issue on the update working directory.
A version/build mismatch between the currently-installed core and the manual update logic if the auto-update partially overwrote something before failing.

Looking more into core logs and testing now.

[QuickMythril]

Thanks — this confirms two update-path errors, but it does not yet show a QDN render returning HTTP 500.

The first error is from Qortium Home's managed GitHub-package updater on Windows:

EPERM: operation not permitted, rename ...\qortium-core\install -> ...\qortium-core\_install-backup-*

The second error is from Core's on-chain update-status endpoint, GET /admin/update. That endpoint is separate from QDN resource rendering. Also, the HTTP 500 means that request handler failed; it does not by itself mean the Core process crashed.

Please confirm whether Chat and other QDN apps are still failing after the manual installation, and provide the output of:

curl.exe http://127.0.0.1:24891/admin/info
curl.exe -i http://127.0.0.1:24891/arbitrary/resource/status/APP/Chat/Chat
curl.exe -i http://127.0.0.1:24891/render/APP/Chat/Chat

Please also paste the qortium.log exception and stack trace from the time GET /admin/update returned 500. Do not include the API key or any other secrets.

For comparison, the authenticated GET /admin/update endpoint currently returns HTTP 200 with valid JSON on another synced post-v1.6.1 Core, so the stack trace is needed to identify what is specific to this runtime/state.

These results will tell us how to split the follow-up correctly:

• Direct Chat render returns 200: narrow this Core issue to the /admin/update failure and track the Windows EPERM rename separately in Home.
• Direct Chat render returns 500: retain the QDN-render investigation and use its log stack to identify the Core path.
• Direct Chat render returns 503 or error 1401: investigate QDN chunk availability/data peers separately.