Summary

Forge apps that use the Key-Value Store (KVS) for read-before-write or existence checks generate large volumes of expected not-found responses. When kvs.get() is called for a key that does not exist, the storage REST gateway returns a 404 (KEY_NOT_FOUND) and the @forge/kvs SDK correctly returns undefined to the app - but the underlying 404 is counted as a 4xx client error in the Developer Console API metrics. This makes the dashboard misleading, as expected misses are indistinguishable from genuine client errors and inflate the 4xx rate. Since kvs.get() is the only strictly consistent way to check key existence (kvs.query() is eventually consistent and unsafe for dedup), these 404s are unavoidable for correctly written apps.

Current behavior

kvs.get() on a missing key -> gateway returns HTTP 404 (KEY_NOT_FOUND) -> SDK returns undefined -> the 404 is reported as a 4xx client error in API metrics, under the "unknown" Request URL row. (The legacy GraphQL storage path returned HTTP 200 with a null value for the same condition.)

Suggested behavior

Expected KEY_NOT_FOUND reads should not pollute the 4xx client-error metric. Either:

• Exclude missing-key (KEY_NOT_FOUND) responses from the 4xx count in API metrics; or
• Surface expected not-founds as a distinct outcome/category separate from 4xx, so genuine client errors remain visible.