umbrellio/table_sync

TableSync is a Ruby gem designed for bidirectional database table synchronization between microservices. It operates by listening to model events and publishing changes via RabbitMQ, supporting both ActiveRecord and Sequel ORM adapters. The system features configurable publishing and receiving pipelines with options for debouncing, compression, and batch processing.

This change introduces the TableSync gem, a tool for DB table synchronization between microservices using model events and RabbitMQ. It includes the initial gemspec, a comprehensive CHANGELOG documenting versions from 4.1.1 to 6.11.0, and updated README with installation and usage instructions. The project is configured with RSpec settings, Rubocop rules targeting Ruby 3.1, and a .gitignore that excludes logs and gem files. The Travis CI configuration is removed, indicating a shift away from that CI provider.

(repo-wide) · high confidence

This change introduces the TableSync library, enabling synchronization of database tables between different systems. It provides a publishing pipeline (supporting single, batch, and raw message formats with optional debouncing and compression) and a receiving pipeline with a DSL for configuring target models. The implementation includes ORM adapters for both ActiveRecord and Sequel, event validation, instrumentation via ActiveSupport::Notifications, and a plugin ecosystem for extensibility.

_lib/table\sync · high confidence

The core library has been significantly restructured to support a modular architecture. The main entry point now loads a comprehensive set of internal components, including dedicated modules for ORM adapters (ActiveRecord and Sequel), setup configurations, naming resolvers, and instrumentation. New dependencies such as 'memery', 'self\_data', and 'rabbit\_messaging' have been introduced to handle messaging and data handling. The public API now exposes configuration options for publishing jobs, routing keys, and exchanges, while introducing a new 'sync' method that accepts options like 'debounce\_time' and 'compress' to configure synchronization behavior for specific object classes.

lib · high confidence

Added comprehensive RSpec tests covering the TableSync library's event handling, instrumentation, publishing (single, batch, and raw), receiving configuration, and ORM adapters (ActiveRecord and Sequel). These tests validate message construction, routing key resolution, debounce logic, attribute filtering, and notification payloads for both publish and receive flows.

spec · high confidence

The gem now requires Ruby 3.1.0 or higher (previously 2.3.8) and updates its runtime dependencies to include memery, rabbit\_messaging (\>= 1.8.0), rails, and self\_data. Development dependencies such as rspec, rubocop-config-umbrellio, and simplecov have been moved to the Gemfile, and the gemspec summary and description have been updated to reflect the product's purpose.

(dependencies) · high confidence

A .keep file has been added to the log directory to ensure the directory is tracked by version control, preventing it from being ignored or removed by tools that clean up empty directories.

log · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 56 → 57 (+1.0)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (+0.1)
• Architecture 100 → 93 (-6.8)
• Maturity 37 → 41 (+3.7)
• Readiness 58 → 61 (+3.0)
• Security 80 → 73 (-6.7)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (7 lines × 2) (lib/table_sync/publishing/batch.rb)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No exposed public API
• Test reliability not included
• The README links to a GitHub Wiki page for usage, but no API reference is present. (README.md)

• Ambiguous intent of find() method in ORM adapters. In standard Ruby/ActiveRecord conventions, find usually retrieves a record by primary key. However, in the context of a sync library, this method likely performs a lookup to check for existence or fetch data for comparison. Without clear documentation or distinct naming (e.g., lookup_record, fetch_for_sync), it is unclear if this method returns the full object, a boolean, or raises an error if not found. Furthermore, Base defines find() but Sequel and ActiveRecord implementations might have different signatures or behaviors regarding arguments, creating a potential interface mismatch if not strictly typed.
• Critical CVE: [GHSA redacted] (Gemfile.lock)
• Critical CVE: [GHSA redacted] (Gemfile.lock)
• Critical vulnerability: [GHSA redacted] (Gemfile.lock)
• Duplicated block (6 lines × 2) (lib/table_sync/publishing/batch.rb)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Inconsistent naming for synchronous vs asynchronous publishing operations. Batch and Single types expose both publish_later and publish_now, implying a choice between async and sync execution. However, the Raw type only exposes publish_now, lacking a publish_later equivalent despite having similar properties (routing_key, headers, etc.). This forces users to check the type to know if async publishing is supported.
• Low CVE: [GHSA redacted] (Gemfile.lock)
• Low CVE: [GHSA redacted] (Gemfile.lock)
• Low CVE: [GHSA redacted] (Gemfile.lock)
• Medium CVE: [GHSA redacted] (Gemfile.lock)
• Medium CVE: [GHSA redacted] (Gemfile.lock)
• …and 24 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

umbrellio/table_sync was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.