facebook-ruby-business-sdk

This PR unpins the Countries gem, allowing newer versions of it. This is the same as #213 but with a new version.

Summary On 25.0.2 (Ruby 3.3), the first concurrent reference to the SDK's classes permanently deadlocks the process on Ruby's autoload/require lock. No exception is raised — the threads hang forever — so it's a silent failure that hits any multithreaded host (Sidekiq, Puma, parallel test runners). Reproduction One command — run as plain Ruby, not inside a Rails console (Rails' own autoloader wraps and masks the gem-level behavior): On 25.0.2 + Ruby 3.3 this prints, every run: All 18 threads are wedged in the autoload — backtraces are parked at: Warming the classes single-threaded first — one pass before the threads — prints . So it's the concurrent first load that deadlocks, not the classes themselves: (The is only there so the script terminates instead of hanging on the wedged threads at exit.) Root cause registers every class with Ruby . A class body's / declarations resolve their types at definition time via → (), which triggers the autoload of the referenced class — whose body resolves its fields, autoloading more. The graph is large (~1000 classes) and circularly interdependent. Ruby is not safe for concurrent loading of interdependent files: two threads autoloading constants whose files transitively require each other each hold one in-progress load and block on the other — a circular wait on the global require lock that never resolves. Because a deadlocked thread raises nothing, there's no error or alert; the process just stops making progress on anything touching the SDK. Impact Any multithreaded Ruby host that first-references SDK classes concurrently. It's a cold-start effect — a fresh process is vulnerable only until the graph is fully loaded — so it surfaces right after boots/deploys and looks intermittent (only processes that lose the race wedge). Suggested fix Provide a public (or load the graph at time) so applications can warm it single-threaded at boot; or serialize / autoload resolution behind a mutex. Workaround Eager-load the graph once at boot, single-threaded, before spawning worker threads: Minor, separate:* that sweep also surfaces 6 files that ship with s and appear deprecated: , , , , , .

Description The Ruby SDK codegen produces with an empty edge name for 5 ad object classes. This is not a valid Ruby symbol literal and causes a at load time. The Python codegen handles these same objects correctly, emitting named methods (/) with . Affected classes Expected behavior The codegen should emit a named edge, e.g.: Actual behavior This raises when the file is loaded. Impact Currently low — these files are autoloaded and nothing references them, so the error is silent. However, this becomes a blocker for any consumer that needs to eager-load the gem (e.g., for thread-safety in Rails/Sidekiq environments) or for consumers that end up needing to use these edges. Introduced in Commit ("Auto-generated ruby SDK code update", D95913002). These files have never had valid edge names.