Project Overview

Title

Enhance Seata-Go Multi-Registry Support and seata-ctl Diagnostic Tool Capability

Abstract

Apache Seata (incubating) is a popular distributed transaction solution for ensuring data consistency in microservice architectures. Seata-Go, as its Go language SDK, is responsible for implementing core TM/RM functionalities in the Go ecosystem.

Currently, Seata-Go lags behind the Java version in terms of registry support richness at the infrastructure layer, and its production-level transaction troubleshooting and operational toolchain (seata-ctl) is still in its early stages. This results in limited options for users in non-Etcd/Raft scenarios and high troubleshooting costs when transaction anomalies occur.

This project aims to align with Seata's infrastructure ecosystem by introducing support for four mainstream registries: Nacos, ZooKeeper, Consul, and Redis to Seata-Go. Additionally, it will significantly enhance seata-ctl's diagnostic capabilities through full-chain environment checks, transaction state insights, and an interactive terminal interface, reducing the operational threshold for distributed transactions.

Detailed Description / Objectives

• Infrastructure Alignment: Ensure Seata-Go can seamlessly integrate into existing enterprise-level microservice governance systems by implementing adapters for various mainstream registries.
• Operational Efficiency Improvement: Build a complete diagnostic command set enabling developers to quickly locate network, database, and transaction state anomalies, and simplify operation workflows through an interactive interface.
• Community Ecosystem Contribution: Produce high-quality design documents and technical blogs to help community users understand Seata-Go's underlying governance logic and operational best practices.

Deliverables

1. Multi-Registry Cluster Support (Priority P0)

• Mainstream Registry Adapter Implementation:

• • Implement Nacos and ZooKeeper registry adapters with support for service instance subscription, real-time listening, and multi-tenant isolation configuration.
  • Implement Consul and Redis adapters with support for service registration/discovery and heartbeat monitoring mechanisms.
  • Bug fixes for Seata NamingServer Golang SDK.
  • Ensure service registration path formats for all registries are fully compatible with Java version Seata.
• Configuration and Initialization System Integration:

• • Extend configuration structure to standardize registry-specific configuration parameters.
  • Optimize factory initialization logic to support smooth registry type switching via configuration files.

2. seata-ctl Diagnostic Tool Enhancement (Priority P1)

• Full-Chain Self-Check Functionality:

• • Implement automated environment checks covering network connectivity verification with the server.
  • Implement database-level health checks including connection availability and validation of transaction core system table structures.
  • Implement configuration file format and required field legality validation.
• Transaction State Insight Capability:

• • Implement real-time query functionality for active transaction lists.
  • Implement query functionality for resource lock records corresponding to specific transaction identifiers (XID).
  • Support structured output formats (e.g., table, JSON, YAML).
• Interactive Terminal Interface (TUI):

• • Introduce a visual interactive mode for the tool, simplifying complex command input through interface guidance to enhance operational experience.

3. Testing, Samples, and Community Output (Priority P2)

• Testing and Validation:

• • Write unit tests and integration tests for each registry adapter to verify node change awareness capabilities.
  • Validate diagnostic tool accuracy across different database dialects.
• Samples and Documentation:

• • Add complete multi-registry integration examples in seata-go-samples.
  • Write technical articles: "Seata-Go Registry Extension Design and Practice Guide" and "Distributed Transaction Troubleshooting in Practice: Quickly Locating Anomalies with Diagnostic Tools".

Implementation Plan

• Phase 1: Research and Architecture Design

• • Research existing Seata-Go registry implementations and study Seata NamingServer implementation logic.
  • Design diagnostic tool's interaction logic and command set architecture, ensuring tool extensibility.
• Phase 2: Registry Adapter Development (P0)

• • Prioritize completion of core functionality implementation and compatibility testing for Nacos and ZooKeeper.
  • Perform bug fixes for Seata NamingServer to optimize its stability in the Go SDK.
  • Integrate Consul and Redis support and unify configuration initialization entry points.
• Phase 3: Diagnostic Tool and Interactive Interface Development (P1)

• • Develop core logic for environment checks and transaction state queries.
  • Build interactive terminal interface (TUI), encapsulating underlying commands into intuitive visual operations.
• Phase 4: Testing Validation and Community Promotion (P2)

• • Improve test cases to ensure stability across different registry environments.
  • Complete community technical article output and submit related sample code.

Required Skills

• Have Go language development experience, familiar with concurrent programming and network communication.
• Understand service discovery principles, familiar with mainstream registries (e.g., Nacos, ZooKeeper).
• Understand basic distributed transaction principles, familiar with Seata's interaction architecture (TM/RM/TC).
• Familiar with command-line tool development, possess good code standards awareness and documentation writing skills.

Benefits to Apache Seata

• Expand Infrastructure Boundaries: Enable Seata-Go to adapt to more diverse enterprise production environments, eliminating selection barriers.
• Improve Operational Convenience: Fill the gap in operational diagnostic tools for the Go version, significantly reducing user learning and maintenance costs.
• Enhance Ecosystem Interoperability: Ensure consistency in governance between Go and Java versions, supporting Seata's unified multi-language ecosystem.

Conclusion

This project addresses Seata-Go's shortcomings in infrastructure adaptation and operational troubleshooting by enhancing multi-registry support and diagnostic tool capabilities. This not only improves Seata-Go's production readiness but also strengthens the Apache Seata community ecosystem through user-friendly interactive tools and comprehensive technical documentation.

Useful Link

• https://seata.apache.org/
• https://github.com/apache/incubator-seata-go
• https://github.com/apache/incubator-seata-go-samples
• https://github.com/apache/incubator-seata-ctl

Contact Information

• Mentor Name: TunGuo [tew@apache.org], Apache Seata(incubating) Committer

Description

Currently, the HugeGraph core query engine is built on Java 11 + TinkerPop 3.5.x + Groovy 3. While this stack provides fundamental graph query capabilities, it lags behind in security, performance optimization, and support for modern features. Specifically, the built-in Groovy engine relies on complex, high-maintenance black/whitelist mechanisms for script security, which poses potential bypass risks.

The goal of this task is to comprehensively upgrade HugeGraph's underlying dependencies to Java 17 + TinkerPop 3.7/3.8 + Groovy 4. This is not just a version iteration, but a modern architectural transformation:

1. Groovy 4 & TinkerPop 3.7/3.8: Introduce improved syntax features and security designs. We aim to refactor HugeGraphSecurity using native, efficient sandboxing mechanisms to replace the legacy blacklist logic.
2. Java 17/21 Support: Adapt to the new JDK to fully leverage features like ZGC/Shenandoah GC, Records, and Virtual Threads, significantly improving throughput and reducing long-tail latency in large-scale graph queries.

Applicants are expected to handle the full lifecycle, from dependency upgrades and code refactoring to unit test fixes and final performance benchmarking.

Recommended Skills

1. Java Core: Proficiency in Java development with a solid understanding of Java 17+ new features.
2. HugeGraph Architecture: Basic understanding of HugeGraph's storage structure (KV Store), Schema design, and specifically the Gremlin query execution flow.
3. Graph Computing & Compilers: Familiarity with the TinkerPop Gremlin framework architecture; knowledge of AST (Abstract Syntax Tree) parsing or Functional Programming (FP) mindset is a plus.
4. AI Coding: Proficiency in using AI Coding tools (e.g., Codex, Claude Code, Copilot) to assist in code refactoring, test case optimization, and source code interpretation is highly preferred.
5. Security Awareness: Awareness of code security, understanding of how to prevent Script Injection, and experience designing secure sandbox environments.

💡 Important Notes for Applicants

1. Authenticity Matters: While we encourage the use of AI for coding efficiency, please strictly control and reasonably limit the use of LLMs when writing your project proposal/emails. We value genuine communication and mutual respect.
2. Proactive Engagement: We highly recommend participating in community Mini Tasks early. Demonstrating your hands-on ability within the community will significantly increase your chances of selection and help build trust with mentors.

Task List

• Dependency Analysis & Upgrade:
  • Analyze Breaking Changes from TinkerPop 3.5 to 3.7/3.8.
  • Complete core dependency version upgrades and API adaptations following mentor confirmation.

• Java 17 Environment Adaptation:
  • Resolve compile-time and runtime compatibility issues (e.g., reflection restrictions, module access) to ensure the Server module runs correctly on Java 17 (Java 21 is even better).
  • Update Docker configurations to migrate the default runtime to Java 17 (while exploring backward compatibility with Java 11).

• PD & Store Module Upgrade (New):
  • Extend the upgrade scope to the PD (Placement Driver) and Store modules after completing the core Server upgrade.
  • Ensure these modules are adapted to Java 17 to unify the runtime environment across the HugeGraph ecosystem.

• Security Module Refactoring:
  • Refactor the HugeGraphSecurity component based on Groovy 4 features.
  • Design a lightweight, secure script execution strategy and remove the performance-heavy legacy blacklist logic.

• Testing & Fixes:
  • Fix Unit Test (UT) failures caused by the upgrade.
  • Ensure all core functions (CRUD, complex Gremlin queries) pass verification.

• Performance Benchmarking:
  • Produce a performance comparison report: Java 11 (Old) vs. Java 17 (New) using the Twitter-14B public dataset.
  • Quantify improvements in Latency reduction and Throughput increases.

References

• New Contributor Guide: HugeGraph Contribution Guide (Issue #2212) - Environment setup & basics.

• Upgrade Docs: TinkerPop Upgrade Documentation

• Reference Implementation: JanusGraph Upgrade PR (For reference only)

• Gremlin Learning: Practical Gremlin Guide

• Project Wiki: HugeGraph Deepwiki

Project Size

• Difficulty: Medium (Similar references available)

• Estimated Time: ~250 Hours (~15 Weeks)

Mentors

• Yan Zhang: vaughn@apache.org (Apache HugeGraph PMC)

• Imba Jin: jin@apache.org (Apache HugeGraph PMC)