Background: We have an automated pipeline that updates I3S Scene Layer services whenever the underlying IFC or Revit source model changes. ArcGIS Server regenerates the I3S service, and the WebScene on Portal reflects the updated model server-side. This works well.
The Problem: The ArcGIS JS SDK caches I3S node data (geometry, textures, JSON) in the browser's IndexedDB. When a model is silently rebuilt on the server, clients continue rendering the stale cached version indefinitely — they have no way to know the model changed.
What we observed:
- I3S SceneServer JSON responses carry ETags in the format 1-e7868c354a2f3009c8d137369d34f3f2 — which appear to be content-based hashes, which is promising
- Cache-Control headers are set to max-age=86400, public — meaning the browser won't even revalidate with the server for 24 hours, making ETags irrelevant at the HTTP layer
- The JS SDK's IndexedDB caching appears to operate independently of the HTTP cache layer anyway
- Changing the property clientCachingAllowed: falsen on the service has not effect
Questions:
- Are the ETags on SceneServer responses content-based? Will they change automatically when an I3S service is rebuilt from an updated source model?
- Is there an official or recommended mechanism in the ArcGIS JS SDK to detect that a Scene Layer has been updated server-side and invalidate the local IndexedDB cache?
- Does the SDK expose any API to selectively clear cached I3S data for a specific layer or service URL — without clearing all IndexedDB data globally?
- Is the max-age=86400 Cache-Control header configurable anywhere in ArcGIS Server / Portal configuration, or does it require IIS-level outbound header rewriting to override?
- Are there any planned or existing SDK events/callbacks that fire when a layer detects a server-side version change?
Our constraints:
- No reverse proxy in front of ArcGIS Server — Portal items point directly to the ArcGIS Server URL
- We would like to avoid to modify the out-of-the-box Scene Viewer application(s)
