CesiumGS
Editor: Skip CesiumIonSession.Tick() when Unity is offline
Problem
If the Unity Editor launches without an Internet connection, CesiumIonServerManager.instance.currentSession.Tick() throws every frame because the DNS lookup for https://api.cesium.com fails. The result is an endless stream of red-error messages:
Exception: Request for `https://api.cesium.com/appData` failed:
Cannot resolve destination host
Exception: Failed to obtain _appData, can't resume connection
The spam clutters the Console and can even interrupt later domain reloads.
Change
Added a single guard clause at the top of Editor/CesiumEditorUtility.UpdateIonSession():
if (Application.internetReachability == NetworkReachability.NotReachable)
return;
When Unity reports that the machine is offline the function now returns immediately, so the session is ticked again only after connectivity is restored.
Thanks for the PR @Heisenberk-Karabay! Could you please sign a Contributor License Agreement (CLA) for us? We need this before we can take a look at your PR's contents. Thanks!
No, that is not the intended behavior. The PR allowed me to see the tileset in Play mode. I’ll try to reproduce the issue with a fresh install. I’ll also look into the matter regarding Application.internetReachability. I’m going to investigate this ASAP and make the necessary changes. I can either submit them as a separate PR or include them in this one—whichever you prefer.
@Heisenberk-Karabay Feel free to keep things going on this PR! Thanks for the quick response :pray:
Hello, I’ve tested it and recorded a video of the process. The tileset loads completely offline without any errors. I also included the Windows taskbar in the recording to confirm that there was no internet connection.
https://github.com/user-attachments/assets/e493c93b-d0fe-4d1f-b13b-b776661592e5
Updated the code to do network checks as referenced in: https://docs.unity3d.com/6000.1/Documentation/ScriptReference/NetworkReachability.html If there's anything missing, please don't hesitate to let me know.
Sorry for the mistake @Heisenberk-Karabay, it turned out to be something on my side while testing. Thanks for incorporating the feedback!
Can I trouble you to update CHANGES.md for this fix? Once the changelog has been updated, I'm happy to merge.
No worries. I'm not sure which part of the CHANGES.md file I should update — should I write it under v1.16.0 - 2025-05-01, or will there be a new version where I should document the changes instead?
@Heisenberk-Karabay you can put it under a new version! We usually just leave it as ? - ? until we make the final release.
Also, sorry to double-back -- but a colleague just pointed out to me that we need to test this out with Cesium ion self-hosted (which is supposed to work on self-contained / offline networks). I need to hold off on the merge until we try this out 😬
No problem at all! I'll be eagerly waiting for the results of the tests. In the meantime, I'll go ahead and update the CHANGES.md file. Hope everything goes smoothly on your end!
I've updated the CHANGES.md file—please let me know if anything looks off or needs to be adjusted.
@j9liu how are you testing this? I tried it out by putting my system in airplane mode shortly after launching Unity (I can't do it beforehand, because then I won't be able to check out the network license). When I do this, I do see the two errors in the top post, but each is only reported once. It's not clear to me what would cause those messages to be spammed repeatedly.
I think the issue was on my side—I reported it a bit inaccurately. The error messages only show up once.
@j9liu how are you testing this? I tried it out by putting my system in airplane mode shortly after launching Unity (I can't do it beforehand, because then I won't be able to check out the network license).
I tested this in the same way -- once I see Unity start up after it's verified our licenses, I disconnect myself from the internet. However, I was only seeing the _appData error once on my side too.
@j9liu @kring I hope I’m not imposing, but may I kindly ask if there have been any updates on the process?
Hi @Heisenberk-Karabay,
Sorry for the delay, and thanks for bumping this! Our team has been busy with the Dev Conference last week, plus the releases this week.
@azrogers previously worked on support for Cesium ion self-hosted, so I think she would be best equipped to test this. I've asked her to take a look so she'll post here with her results. Thanks again for your patience 🙏
I think I see a pretty major problem with this approach.
What this change does is avoid calling CesiumIonSession::Tick if there's no network access. But what does CesiumIonSession::Tick actually do? Just this:
void CesiumIonSessionImpl::Tick(
const DotNet::CesiumForUnity::CesiumIonSession& session) {
this->_asyncSystem.dispatchMainThreadTasks();
}
What this change is doing is actually preventing async tasks from being dispatched on the main thread until network access is restored. Which is an issue for a few reasons:
- There are potentially other parts of Cesium for Unity's editor scripting that have become reliant on these async tasks being dispatched reliably that this would break.
- There are situations where you would have no network access and still want to access Cesium ion. For example, you could be running an instance of Cesium ion Self-Hosted on your local network that's disconnected from the internet. We have users running on locked-down isolated networks where this would be an issue!
- This doesn't actually address the part of the code that's causing this warning to show up, it's just preventing the task that produces that warning from running. The problem with this is that
CesiumIonSession::Tickisn't the only thing that can dispatch main thread tasks - tilesets can do that too.
I think it would be better to take an approach that targets the root of the issue - the log spam. I think a good solution here would be to target calls of CesiumIonSession::Connect and CesiumIonSession::Resume (which are the methods that produce these errors). We should still try to connect to ion even if offline, but if it fails, we shouldn't try to avoid connecting again until some condition is met (perhaps until either the network connectivity changes or until some settings are changed in the CesiumIonServer asset?)
Let me know if I missed anything.
@j9liu No worries at all. @azrogers I agree that the solution you suggested is likely to be more robust. I’ll take a closer look at it in detail as soon as I have some time.
I'm going to close this PR since we concluded that it wasn't the best approach for this problem. We can always reopen if this comes up again. Thank you for your initiative!