fix: Make goff unix socket client thread safe

[AleksandrasMaliuginas-vinted]

This PR

• Makes goff unix socket client thread safe by instantiating thread local UnixSocket instance

Related Issues

Notes

Follow-up Tasks

How to test

[gemini-code-assist]

Summary of Changes

Hello @AleksandrasMaliuginas-vinted, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical thread-safety concern within the goff Unix socket client. Previously, a single HttpUnix socket instance was shared across all threads, which could lead to race conditions and unpredictable behavior in a multi-threaded environment. The solution involves refactoring the client to instantiate a unique HttpUnix socket for each thread, leveraging Ruby's Thread.current mechanism. This change significantly improves the robustness and reliability of the client when used concurrently, without altering its external API for consumers.

Highlights

• Thread Safety Implementation: The UnixApi client has been made thread-safe by ensuring that each thread instantiates and uses its own HttpUnix socket instance. This prevents potential concurrency issues when multiple threads attempt to use the same socket.
• Refactored Socket Initialization: The UnixApi constructor now accepts an optional unix_socket_client_factory lambda, which is used to create thread-local HttpUnix instances on demand. This decouples the socket creation logic and facilitates testing.
• Dependency and Version Updates: The openfeature-go-feature-flag-provider gem version has been updated from 0.1.7 to 0.1.8 across the Gemfile.lock and version.rb files, reflecting the changes introduced in this pull request.
• Updated Test Suite: The unix_api_spec.rb test file has been updated to reflect the new unix_socket_client_factory pattern, ensuring that the thread-safe implementation is correctly tested using mocked socket instances.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to make the goff unix socket client thread-safe by using a thread-local UnixSocket instance. The approach of using a factory and Thread.current to manage per-thread socket instances is well-implemented and correctly addresses the thread-safety of the socket communication. The tests have also been updated accordingly to use the new factory pattern.

However, I've identified a couple of areas for improvement. There is a remaining thread-safety issue related to rate-limit handling, where the @retry_after instance variable is accessed without synchronization, which can lead to race conditions. Additionally, there's a potential memory issue with dynamic symbol creation for thread-local storage keys. I've added specific comments with details and suggestions for these points.

[thomaspoignant]

🚀 LGTM