The 30-day KV expiry exists, but only on the observability/error store. The feedback store never got it.
Current state
| Write |
File |
TTL |
error:<id> |
src/observability.ts:115 |
✅ expirationTtl: TTL_30_DAYS |
miss:<type>/<namespace> |
src/feedback.ts:88 |
❌ none |
feedback:<id> |
src/feedback.ts:120 |
❌ none |
Confirmed live on 2026-08-09: secid_FEEDBACK held 21 miss: records, the oldest from 2026-06-15 — well past 30 days, still present.
The fix is probably not "add the same TTL to both"
The two prefixes are different kinds of data and a single policy would be wrong for one of them:
miss: is machine-generated, unbounded, and low-value once triaged. A TTL is clearly right. But note the records carry count, first_seen, and last_seen for aggregation — a naive TTL would reset repeat-request tracking every 30 days and hide a namespace being asked for persistently. Worth deciding whether TTL should refresh on each hit.feedback: is an inbox. Explicit submissions expiring on a timer means unprocessed user feedback is silently deleted. That is a data-loss bug wearing a retention-policy costume. If anything it needs the opposite — a resolved/unresolved marker, as feedback_entries already has on the CSA MCP server (resolved_at, resolved_by, github_issue_url).
Related: unbounded key growth
miss: key names are built from caller-supplied namespace text, so the number of distinct keys is attacker-controlled. src/feedback.ts notes that writes are bounded by distinct requests — but distinctness is exactly what a caller chooses. A real probe was observed on 2026-06-15 (entity/adobe.com plus quote/backslash/backtick characters). The resolver handled it correctly and it degraded to an ordinary miss, so this is not an incident — but with no TTL and no cap, repeated distinct junk namespaces grow the namespace without bound. A TTL on miss: mitigates this as a side effect.
Docs are stale either way
OPERATIONAL-RESOURCES.md describes secid_OBSERVABILITY as "No retention policy yet; KV has no TTL set" — the code contradicts this (TTL_30_DAYS is set). It also does not mention secid_FEEDBACK at all, despite it being the namespace that holds the service’s feedback and miss data.
Filed from CINO-mcp-processing sweep #1 (2026-08-09).
The 30-day KV expiry exists, but only on the observability/error store. The feedback store never got it.
Current state
error:<id>src/observability.ts:115expirationTtl: TTL_30_DAYSmiss:<type>/<namespace>src/feedback.ts:88feedback:<id>src/feedback.ts:120Confirmed live on 2026-08-09:
secid_FEEDBACKheld 21miss:records, the oldest from 2026-06-15 — well past 30 days, still present.The fix is probably not "add the same TTL to both"
The two prefixes are different kinds of data and a single policy would be wrong for one of them:
miss:is machine-generated, unbounded, and low-value once triaged. A TTL is clearly right. But note the records carrycount,first_seen, andlast_seenfor aggregation — a naive TTL would reset repeat-request tracking every 30 days and hide a namespace being asked for persistently. Worth deciding whether TTL should refresh on each hit.feedback:is an inbox. Explicit submissions expiring on a timer means unprocessed user feedback is silently deleted. That is a data-loss bug wearing a retention-policy costume. If anything it needs the opposite — a resolved/unresolved marker, asfeedback_entriesalready has on the CSA MCP server (resolved_at,resolved_by,github_issue_url).Related: unbounded key growth
miss:key names are built from caller-supplied namespace text, so the number of distinct keys is attacker-controlled.src/feedback.tsnotes that writes are bounded by distinct requests — but distinctness is exactly what a caller chooses. A real probe was observed on 2026-06-15 (entity/adobe.complus quote/backslash/backtick characters). The resolver handled it correctly and it degraded to an ordinary miss, so this is not an incident — but with no TTL and no cap, repeated distinct junk namespaces grow the namespace without bound. A TTL onmiss:mitigates this as a side effect.Docs are stale either way
OPERATIONAL-RESOURCES.mddescribessecid_OBSERVABILITYas "No retention policy yet; KV has no TTL set" — the code contradicts this (TTL_30_DAYSis set). It also does not mentionsecid_FEEDBACKat all, despite it being the namespace that holds the service’s feedback and miss data.Filed from CINO-mcp-processing sweep #1 (2026-08-09).