Skip to content

Conversation

@ciyer
Copy link
Contributor

@ciyer ciyer commented Nov 6, 2025

No description provided.

@ciyer ciyer marked this pull request as ready for review November 18, 2025 10:24
@ciyer ciyer requested a review from a team as a code owner November 18, 2025 10:24
}
}

func queryRenkuApi(renkuCredentials ServerCredentials, endpoint string) ([]byte, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE: we should open an issue to replace this with code generated from the API spec.

@ciyer ciyer force-pushed the build/gitlab-redirects branch from 70ebf3e to 7f430da Compare November 19, 2025 17:10
type RedirectStore struct {
Config config.RedirectsStoreConfig
EntryTtl time.Duration
RedirectMap map[string]RedirectStoreRedirectEntry
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The redirect map should not be public:

Suggested change
RedirectMap map[string]RedirectStoreRedirectEntry
redirectMap map[string]RedirectStoreRedirectEntry

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 959944f

Comment on lines 122 to 131
entry, ok := rs.RedirectMap[key]
if ok && entry.UpdatedAt.Add(rs.EntryTtl).After(time.Now()) {
return &entry, nil
}

rs.redirectMapMutex.Lock()
defer rs.redirectMapMutex.Unlock()
// Re-check after acquiring the lock, since it might have been updated meanwhile
entry, ok = rs.RedirectMap[key]
if !ok || entry.UpdatedAt.Add(rs.EntryTtl).Before(time.Now()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current code does not protect bad reads of the RedirectMap from happening.

Since the RedirectMap is only ever accessed in this method, we can use the simple sync.Mutex and we should lock the read+update access:

Suggested change
entry, ok := rs.RedirectMap[key]
if ok && entry.UpdatedAt.Add(rs.EntryTtl).After(time.Now()) {
return &entry, nil
}
rs.redirectMapMutex.Lock()
defer rs.redirectMapMutex.Unlock()
// Re-check after acquiring the lock, since it might have been updated meanwhile
entry, ok = rs.RedirectMap[key]
if !ok || entry.UpdatedAt.Add(rs.EntryTtl).Before(time.Now()) {
rs.redirectMapMutex.Lock()
defer rs.redirectMapMutex.Unlock()
entry, ok := rs.RedirectMap[key]
if ok && entry.UpdatedAt.Add(rs.EntryTtl).After(time.Now()) {
return &entry, nil
}
if !ok || entry.UpdatedAt.Add(rs.EntryTtl).Before(time.Now()) {

Doing so will make sure that:

  • Reads do not happen while the map is being updated
  • This map will not be updated multiple times at once

The downside of this simple approach is that it will have poor read performance (full lock when just reading the map).

To enable better read performance, you can use a sync.RWMutex and protect reads and writes separately:

Suggested change
entry, ok := rs.RedirectMap[key]
if ok && entry.UpdatedAt.Add(rs.EntryTtl).After(time.Now()) {
return &entry, nil
}
rs.redirectMapMutex.Lock()
defer rs.redirectMapMutex.Unlock()
// Re-check after acquiring the lock, since it might have been updated meanwhile
entry, ok = rs.RedirectMap[key]
if !ok || entry.UpdatedAt.Add(rs.EntryTtl).Before(time.Now()) {
rs.redirectMapMutex.RLock()
entry, ok := rs.RedirectMap[key]
rs.redirectMapMutex.RUnlock()
if ok && entry.UpdatedAt.Add(rs.EntryTtl).After(time.Now()) {
return &entry, nil
}
rs.redirectMapMutex.Lock()
defer rs.redirectMapMutex.Unlock()
// Re-check after acquiring the lock, since it might have been updated meanwhile
entry, ok = rs.RedirectMap[key]
if !ok || entry.UpdatedAt.Add(rs.EntryTtl).Before(time.Now()) {

Here, we can have as many read locks as we want, which corresponds to the read-heavy model of this map.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in e98ef85

@ciyer ciyer force-pushed the build/gitlab-redirects branch from 866938d to e98ef85 Compare November 20, 2025 13:52
Copy link
Member

@leafty leafty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ciyer ciyer merged commit ab07da1 into master Nov 20, 2025
12 checks passed
@ciyer ciyer deleted the build/gitlab-redirects branch November 20, 2025 13:59
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.

3 participants