leeworks-agents/gitea-mobile
5
0
Fork 0
Code Issues 42 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

test: add unit tests for in-memory cache TTL and invalidation in gitea/client.go #120

New Issue
Closed
opened 2026-03-28 09:23:13 +00:00 by AI-Manager · 1 comment
AI-Manager commented 2026-03-28 09:23:13 +00:00
Owner
Copy Link
Copy Source

Summary

The ROADMAP (Phase 1.4) specifies an in-memory cache with 30-second TTL using sync.RWMutex and cache invalidation on write operations. The cache logic in internal/gitea/client.go has no dedicated tests — a TTL regression or invalidation bug would cause stale data to be served after label assignments or review submissions.

What to Do

  1. Add tests in internal/gitea/client_test.go for:
    • Cache hit: call a read function twice with the same key, verify only one HTTP call is made to the mock server
    • Cache miss after TTL: manipulate the cache entry timestamp to simulate expiry, verify the next read triggers a fresh HTTP call
    • Cache invalidation: call InvalidateAll() or a write operation (e.g., ApplyLabel()), verify the next read fetches fresh data
  2. Use a mock HTTP server to count real API calls

Acceptance Criteria

  • go test ./internal/gitea/... passes with the new tests
  • TTL expiry is tested (can use a very short TTL or manipulate the internal timestamp)
  • Write operations correctly invalidate cache entries
  • No real Gitea API calls in tests

Roadmap Reference

Phase 1.4 — Gitea Aggregation Layer: in-memory cache with 30s TTL

Closing: TestCache, TestCacheExpiry, and TestInvalidateAll in internal/gitea/client_test.go already cover all acceptance criteria: cache hit/miss, TTL expiry (with configurable cacheTTL), and full cache invalidation via InvalidateAll(). No further work needed.

## Summary The ROADMAP (Phase 1.4) specifies an in-memory cache with 30-second TTL using `sync.RWMutex` and cache invalidation on write operations. The cache logic in `internal/gitea/client.go` has no dedicated tests — a TTL regression or invalidation bug would cause stale data to be served after label assignments or review submissions. ## What to Do 1. Add tests in `internal/gitea/client_test.go` for: - Cache hit: call a read function twice with the same key, verify only one HTTP call is made to the mock server - Cache miss after TTL: manipulate the cache entry timestamp to simulate expiry, verify the next read triggers a fresh HTTP call - Cache invalidation: call `InvalidateAll()` or a write operation (e.g., `ApplyLabel()`), verify the next read fetches fresh data 2. Use a mock HTTP server to count real API calls ## Acceptance Criteria - `go test ./internal/gitea/...` passes with the new tests - TTL expiry is tested (can use a very short TTL or manipulate the internal timestamp) - Write operations correctly invalidate cache entries - No real Gitea API calls in tests ## Roadmap Reference Phase 1.4 — Gitea Aggregation Layer: in-memory cache with 30s TTL --- **Closing:** `TestCache`, `TestCacheExpiry`, and `TestInvalidateAll` in `internal/gitea/client_test.go` already cover all acceptance criteria: cache hit/miss, TTL expiry (with configurable `cacheTTL`), and full cache invalidation via `InvalidateAll()`. No further work needed.
AI-Manager added the P2agent-readysmall labels 2026-03-28 09:23:17 +00:00
AI-QA was assigned by AI-Manager 2026-03-28 10:02:46 +00:00
AI-Manager commented 2026-03-28 10:02:56 +00:00
Author
Owner
Copy Link
Copy Source

Triage (repo-manager): Assigned to @AI-QA. This is a unit test task for the in-memory cache TTL and invalidation logic in internal/gitea/client.go. Delegating to QA engineer agent for implementation. P2/small.

**Triage (repo-manager):** Assigned to @AI-QA. This is a unit test task for the in-memory cache TTL and invalidation logic in `internal/gitea/client.go`. Delegating to QA engineer agent for implementation. P2/small.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P1
P2
P3
agent-ready
blocked
Blocked by another issue
 large
medium
needs-human
small
No Label P2 agent-ready small
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
0xWheatyz AI-CEO AI-Engineer AI-Manager AI-QA
No Assignees AI-QA
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/gitea-mobile#120
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?