Future-consideration follow-up from review of PR #264.
Each webhook delivery currently builds a fresh GitHubAppClient via Factory.create_push_event_processor() → Factory.create_github_app_client(). JWT minting is lazy so this is fine at the current low webhook volume, but as traffic grows it becomes worth caching the client (or just the installation token, keyed by installation ID) at the ContextDependency or process-cache layer.
No action required today — dashboard_sync is the slow path and dashboard_template_contents ETag short-circuits redundant fetches. Track here so the optimization isn't lost when PR #264 merges.
Possible shapes when the time comes:
- Memoize the
GitHubAppClient on ContextDependency and have the Factory return the cached instance when the secrets match.
- Cache only the GitHub installation token (the expensive part), keyed by
installation_id, with a TTL well under 1 hour.
See PR #264 review thread for the original observation.
Future-consideration follow-up from review of PR #264.
Each webhook delivery currently builds a fresh
GitHubAppClientviaFactory.create_push_event_processor()→Factory.create_github_app_client(). JWT minting is lazy so this is fine at the current low webhook volume, but as traffic grows it becomes worth caching the client (or just the installation token, keyed by installation ID) at theContextDependencyor process-cache layer.No action required today —
dashboard_syncis the slow path anddashboard_template_contentsETag short-circuits redundant fetches. Track here so the optimization isn't lost when PR #264 merges.Possible shapes when the time comes:
GitHubAppClientonContextDependencyand have the Factory return the cached instance when the secrets match.installation_id, with a TTL well under 1 hour.See PR #264 review thread for the original observation.