FeatureServer returning HTTP/304 when data has changed

[ViktorSafar]

I have a Wab Appbuilder widget (JS v3) that adds some layers to the map from a MapServer. I add them using the FeatureLayer type:

      const newLayer = new FeatureLayer(layerUrl, {
        mode: FeatureLayer.MODE_ONDEMAND,
        outFields: ["*"]
      });

      newLayer.on("load", () => {
        theMap.addLayer(newLayer);
      });

layerUrl is a FeatureServer: https://domain/server/rest/services/folderName/serviceName/FeatureServer/0

The data behind the service as updated several times a day and we had users complain that new features are not visible on some zoom levels. The problem persists over log outs (log out of Portal and back in), and has not resolved over a period of several days (some features added days ago are still not showing for some users on some zoom levels).

I debugged and found out that the reason appears to be a 304 response from the server even though the data have been updated in the background. To explain:

Users 1 and 2 have the application containing the widget open in their browsers.

User 1 uses the widget to add a feature.

User 2 zooms around the map but only sees the new feature in certain zoom levels. This is the part where when the user does not see the feature, it's because the server responded with 304 and the browser took a now-outdated response from browser cache.

The same problem occurs when a feature is updated, eg. its geometry is changed. The old geometry is showing in some zoom levels and the new geometry is showing on other zoom levels.

All of the responses contain Cache-Control: public, must-revalidate, max-age=0

As per https://enterprise.arcgis.com/en/server/10.8/publish-services/linux/feature-services-and-client-appl... , cacheControlMaxAge is not configured on our services and quoting from the link "feature services, the default is zero seconds"

What else can I do or check?

[JoelBennett]

This isn't pretty, but it will force the queries (and therefore the URLs that access the service) to be unique each time they're sent:

newLayer.on("load", () => {
	theMap.addLayer(newLayer);

	var execute = newLayer._task.execute;

	newLayer._task.execute = function(query) {
		var now = Date.now().toString();

		if ((typeof query.where != "string") || (query.where.trim() === ""))
			query.where = now + "=" + now;
		else
			query.where = "(" + query.where + ") AND " + now + "=" + now;

		var args = [];

		for (var x = 0; x < arguments.length; x++)
			args[x] = arguments[x];

		return execute.apply(this, args);
	};
});

[ViktorSafar]

I guess that's a workaround. However that will increase the load on the server hundreds to thousands of times as every query will be drawn from the database. Surely there must be a better way?

[Strahanjen]

I'm experiencing the same issue, though I'm using JS API v4.26 and an ArcGIS server 10.91 service. Did you find a solution?