Browser using outdated disk-cache $metadata, even though Cache Buster for Metadata is configured

[thalesvb]

Hi, I recently had the same problem reported previously by someone on this issue on GitHub: I changed an already deployed OData V2 service (SEGW), created new relations and actions on OData model, after publishing this new version to production got a few complaints that things weren't working as it should, and I found the root cause being browser fetching an outdated Metadata from its disk cache, HTTP so Fiori application was unable to use the new relations because (cached) metadata document didn't acknowledge them. Launchpad and browser loaded correctly the new SAPUI5 objects version from server, the issue is with Metadata document. It is a browser caching issue because clearing browser cache or opening it in private mode it works as it should, not to say that testing service with /IWFND/GW_CLIENT also returns the current metadata document.

Help Page for Cache Buster for Odata Metadata doesn't tells any details about how it works in HTTP level, merely saying "cached on the client using cache buster techniques". That doesn't help to check if Cache Buster is properly configured and working or to understand that the problem could be lying somewhere else. The print above shows last-modified with August 2021, the browser-cached version, while executing the same metadata call on /IWFND/GW_CLIENT I get a date from September 2021 (the current version).

Even tough the Help page said it is not necessary for embedded scenario, my FES configuration, the job for report /UI5/UPD_ODATA_METADATA_CACHE was already running hourly yet it doesn't seem to collect any data for that service due not locating collector implementation (message "Method GET_BACKEND_CONTEXT_TOKEN (/IWFND/CL_COF_FACADE) does not exist" followed by "Backend Context Collector on local Gateway hub not called").

The '555555' question is the one on title: how those cache buster techniques exactly works? Is it URL-based, same as UI5 resources? Are HTTP header fields added to responses(and which ones)?

The issue I'm having is a thing that Cache Buster for OData Metadata should prevent. Configuration for Cache Buster looks OK. It was already in place before transporting that service change, but I saw no influence on $metadata requests/responses and no explicit mechanism for $metadata expiration.

Kind regards

_____

Notes and sum-up:

This system is an embedded FES deployment layout with SAP_GWFND 7.40 SP26, the only recommendation for that version is scheduling /UI5/UPD_ODATA_METADATA_CACHE and running /IWFND/CACHE_CLEANUP. I also ran /UI2/INVALIDATE_GLOBAL_CACHES, /UI2/INVALIDATE_CLIENT_CACHES for completeness but that still led to browser use its metadata's disk cache version. The service is SEGW-based OData V2.

The Fiori application is launched from Fiori Launchpad, which itself points to the Cache-buster enabled URL /sap/bc/ui2/flp.

_____

Other informations gathered until now:

That GH issue tells that caching behavior is controlled by the service. Standard service doesn't have any specific code for it, backend is handling by gateway default policy Last-Modified HTTP header field(developer.mozilla.org/docs/Web/HTTP/Headers/Last-Modified) (class/method /IWFND/CL_SODATA_PROCESSOR -> /IWCOR/IF_DS_PROC_METADATA~READ). That is enforced by Help Page for my current SAP_GWFND version. That policy implementation can also handle If-Modified-Since requests, pushing responsibility back to client (UI5 application); this one mine is an UI5 extension (from a standard app), so manually changing the $metadata request, as GH issue opener did, is out of bounds.

The only thing ABAP/Gateway is returning on HTTP header, related in some way with caching, is the Last-Modified field. This alone is a weak validator for caching. Shouldn't be a "Cache-Control" field or other fields be present on response to control metadata freshness or library issuing a conditional-request validation before using browser-cached metadata?