Skip to content

Fix catalog cache keys for status/count variants#21

Merged
deverman merged 1 commit into
deverman:masterfrom
osamu2001:fix/catalog-cache-key-correctness
Mar 19, 2026
Merged

Fix catalog cache keys for status/count variants#21
deverman merged 1 commit into
deverman:masterfrom
osamu2001:fix/catalog-cache-key-correctness

Conversation

@osamu2001
Copy link
Copy Markdown
Contributor

Summary

The catalog cache keys for list_projects and list_tags only used pagination and fields, so requests with different statusFilter or includeTaskCounts values could reuse the same cached page.

This change separates those cache entries by filter state and adds regression tests that pin the behavior without relying on live OmniFocus data.

Changes

  • add dedicated project/tag cache-key builders
  • include statusFilter and includeTaskCounts in catalog cache keys
  • update OmniFocusBridgeService to use the new key builders
  • add regression tests for key equality and cache entry separation

Testing

  • swift test --filter CatalogCacheTests
  • swift test

intent(catalog-cache): prevent projects and tags with different status or task-count settings from sharing cached pages
decision(catalog-cache): add projects and tags cache-key builders so service call sites generate the same key shape consistently
constraint(catalog-cache): keep the existing cache bypass rules and field ordering behavior unchanged for this correctness fix
learned(catalog-cache): cache regression coverage is more stable as direct CatalogCache tests than as live OmniFocus integration checks
@deverman deverman merged commit 25fa53e into deverman:master Mar 19, 2026
1 check passed
@deverman
Copy link
Copy Markdown
Owner

@osamu2001 thanks for finding this issue I have merged it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants