Story (Required)

As a system processing GitLab events trying to process events efficiently, I
want membership checks to be cached so that I reduce unnecessary calls to the
GitLab API and improve performance.

_This story aims to reduce the number of API calls made to GitLab for project
membership checks. By caching the results, we improve the performance of event
processing and mitigate the risk of hitting GitLab API rate limits, leading to
a more reliable and responsive integration for our customers._

Background (Required)

Currently, the GitLab provider may make repeated calls to the GitLab API's GetInheritedProjectMember endpoint to check the membership status of the same user multiple times within the processing of a single event. This leads to inefficient resource utilization, increased latency, and a higher chance of encountering API rate limiting issues, particularly for complex events or when multiple checks are performed for the same user.

Out of scope

• Cross-instance caching: The cache is designed to be in-memory and specific to a single Provider instance.
• Persistent caching: Cache data will not persist beyond the lifecycle of the Provider instance.
• Advanced cache invalidation strategies: The current scope focuses on caching within a single event processing context.

Approach (Required)

Introduce an in-memory memberCache (a map of int to bool) within the gitlab.Provider struct. This cache will store the results of checkMembership calls, keyed by userid.

Before making a GetInheritedProjectMember API call, the system will check if the result for the specific userid is already present in memberCache. If found, the cached result will be returned immediately, bypassing the API call.

In scenarios where the GetInheritedProjectMember API call fails (e.g., due to transient network issues), the error result will not be cached. This ensures that a subsequent check for the same user can retry the API call, allowing for recovery from temporary failures.

If the API call succeeds, the determined membership status (considering the IsAllowedOwnersFile fallback) will be stored in memberCache for future requests within the same Provider instance.

Dependencies

• Relies on the existing gitlab.Client for API communication.
• Relies on the IsAllowedOwnersFile function for fallback authorization checks.

Acceptance Criteria (Mandatory)

• Given a GitLab Provider instance is processing an event:
  • When checkMembership is called for a specific user ID for the first time, then the GitLab API GetInheritedProjectMember endpoint must be invoked.
  • When checkMembership is called for the same user ID subsequently within the same Provider instance, then the GitLab API GetInheritedProjectMember endpoint must not be invoked, and the cached result must be returned.
• Given a checkMembership call where the GitLab API GetInheritedProjectMember invocation fails:
  • When the API call fails, then the negative result must not be cached.
  • When a subsequent checkMembership call is made for the same user, then the GitLab API GetInheritedProjectMember endpoint must be invoked again (allowing for retry).
• Given a checkMembership call where the GitLab API GetInheritedProjectMember invocation succeeds:
  • When the API call succeeds, then the determined membership status must be cached for that user ID.
• The memberCache field must be lazily initialized when first accessed.

INVEST Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated