perf: cache allowed origins set instead of rebuilding per request

[hobostay]

Summary

• Caches the Set of allowed origins after first build instead of creating a new Set on every API request

Problem

buildAllowedOrigins() was called inside the /api middleware on every single request, creating a new Set with ~12-18 entries each time. The allowed origins depend only on resolvedPort and OD_WEB_PORT, which don't change at runtime.

Test plan

• API requests still enforce origin checks correctly
• No behavioral change — the cached set contains the same entries

🤖 Generated with Claude Code

[lefarcen]

Hi @hobostay! 🎉

Thanks for the contribution — this is a smart optimization that eliminates repeated Set construction on every request.

I will run a deep review and get back to you within 24h.

Thanks for making open-design better!
— open-design team

[lefarcen]

Hey @hobostay, thanks for the optimization! This eliminates ~1200-1800 Set constructions per second on a busy daemon (12-18 origins × 100 req/s). I verified the caching is safe — resolvedPort, host, and OD_WEB_PORT are all immutable after startServer() completes.

Two minor suggestions below (non-blocking):

[lefarcen]

P3 Stale comment reference — this line still mentions buildAllowedOrigins after the rename to getAllowedOrigins. Not a functional issue, but in security-sensitive origin-checking code it's worth keeping comments accurate to avoid future confusion.

Suggested fix: update the comment to reference getAllowedOrigins().

[lefarcen]

Additional suggestion — test coverage gap:

The existing origin tests in apps/daemon/tests/origin-validation.test.ts copy the middleware logic instead of exercising the real startServer() and the new cached getAllowedOrigins() closure. That means they would still pass if production caching captured a stale or missing OD_WEB_PORT.

Suggestion: Add a focused integration test against real startServer({ port: 0, returnServer: true }) with process.env.OD_WEB_PORT set before the first browser-origin request, asserting:

• The web port origin is allowed
• An unrelated port is rejected

This would catch any future cache lifetime issues. Not blocking, but worth considering for future robustness.

[mrcfps]

@hobostay I reviewed the daemon origin-cache change and found one merge-blocking TypeScript issue in the new cache variable. Once the cache is explicitly typed, the optimization should preserve the intended origin policy while avoiding the repeated Set allocation. Thanks for the focused performance cleanup 🙂

_{Generated by Looper 0.5.4 · runner=reviewer · agent=opencode}

[mrcfps]

This cache needs an explicit Set<string> | null type before it can merge. With apps/daemon/tsconfig.json enabling strict, a let initialized only with null is not safely typed as the later Set, but the changed code assigns new Set(...) and then returns it for .has(...) checks in the middleware. That makes the daemon typecheck fail (or leaves the cache without the intended Set<string> contract), blocking this otherwise small optimization.

Please type the cache and return value explicitly, for example:

let _cachedAllowedOrigins: Set<string> | null = null;
function getAllowedOrigins(): Set<string> {
  if (_cachedAllowedOrigins) return _cachedAllowedOrigins;
  // ...
}

That keeps the cached origin set type aligned with the middleware usage and avoids a strict-mode compile break. 🙂