We run a Forge app for Jira (@forge/kvs 1.5.0). Our API metrics dashboard shows a steady stream of 4xx, all 404, on the “unknown” Request URL row under the Atlassian source. No 5xx, app is healthy, sync works fine - but the 4xx count looks alarming and there was no obvious cause.
I spent a while tracking it down and want to confirm the behavior:
Ruled out our own REST calls. I wrapped every requestJira call to log any non-2xx response. Zero hits, including straight through a 404 spike on the dashboard. So it is not our Jira REST traffic.
Confirmed it is KVS. The app only calls two Atlassian APIs: @forge/api (requestJira) and @forge/kvs. I temporarily logged every kvs.get / kvs.getSecret that resolved undefined. The correlation was exact: in one hour the dashboard reported 4xx = 101, and our missing-key read count was 101.
So kvs.get(key) on a key that does not exist returns undefined to our code (as documented), but the underlying storage GET appears to return a 404, and that 404 is counted in API metrics as an “unknown” client error. About 95% of ours are normal read-before-write existence/dedup checks, where a miss is the expected path (first time we see a comment, etc.).
Questions:
- Is it expected that a missing-key kvs.get 404s at the transport layer, and that this is counted as a 4xx in API metrics? The GraphQL storage API returns null for a missing key - does the REST gateway the SDK now uses return 404 instead?
- If so, can missing-key GETs be excluded from the API-metrics 4xx (or surfaced as a distinct, expected outcome)? As it stands they bury genuine 4xx - e.g. a real deleted resource - in noise and make the dashboard look unhealthy when it is not.
- Is there a recommended “does this key exist” pattern that avoids the 404 and is not eventually-consistent like query()? (We need strong consistency for dedup, so query is not a safe substitute.)
Thanks!