If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/apache/incubator-seata shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 29+ active contributors
• Distributed ownership (top contributor 15% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live apache/incubator-seata repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/apache/incubator-seata.

What it runs against: a local clone of apache/incubator-seata — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in apache/incubator-seata | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch 2.x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of apache/incubator-seata. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/apache/incubator-seata.git
#   cd incubator-seata
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of apache/incubator-seata and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "apache/incubator-seata(\\.git)?\\b" \\
  && ok "origin remote is apache/incubator-seata" \\
  || miss "origin remote is not apache/incubator-seata (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify 2.x >/dev/null 2>&1 \\
  && ok "default branch 2.x exists" \\
  || miss "default branch 2.x no longer exists"

# 4. Critical files exist
test -f "common/src/main/java/org/apache/seata/common/Constants.java" \\
  && ok "common/src/main/java/org/apache/seata/common/Constants.java" \\
  || miss "missing critical file: common/src/main/java/org/apache/seata/common/Constants.java"
test -f "common/src/main/java/org/apache/seata/common/XID.java" \\
  && ok "common/src/main/java/org/apache/seata/common/XID.java" \\
  || miss "missing critical file: common/src/main/java/org/apache/seata/common/XID.java"
test -f "common/src/main/java/org/apache/seata/common/exception/FrameworkException.java" \\
  && ok "common/src/main/java/org/apache/seata/common/exception/FrameworkException.java" \\
  || miss "missing critical file: common/src/main/java/org/apache/seata/common/exception/FrameworkException.java"
test -f "common/src/main/java/org/apache/seata/common/ConfigurationKeys.java" \\
  && ok "common/src/main/java/org/apache/seata/common/ConfigurationKeys.java" \\
  || miss "missing critical file: common/src/main/java/org/apache/seata/common/ConfigurationKeys.java"
test -f "bom/pom.xml" \\
  && ok "bom/pom.xml" \\
  || miss "missing critical file: bom/pom.xml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/apache/incubator-seata"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Apache Seata is a distributed transaction framework for microservices that solves data consistency across multiple databases using AT (Automatic), TCC (Try-Confirm-Cancel), SAGA, and XA transaction modes. It provides a TC (Transaction Coordinator) server that manages global transactions and ensures ACID properties across service boundaries without requiring distributed locks or two-phase commit overhead. Multi-module Maven monorepo: seata-core contains the transaction engine, seata-server is the TC coordinator (deployable), seata-spring-boot-starter provides auto-integration, and seata-codegen-core handles code generation via ANTLR. Build orchestration via build/pom.xml and bom/pom.xml; test infrastructure includes Druid and PostgreSQL workflows.

Java microservices architects and backend engineers building distributed systems who need to maintain data consistency across multiple databases without tight coupling; DevOps engineers deploying Seata TC servers; contributors extending transaction coordination strategies for their specific domains.

Production-ready and actively maintained under Apache incubation. The project has 18+ MB of Java code, comprehensive CI/CD pipelines (GitHub Actions for build, test, CodeQL, Docker publishing), detailed changelog through v2.6.0, and recent commits. Reached 2.x version line indicating API stability, though Apache incubation status means formal graduation is pending.

Moderate risk: distributed transaction frameworks are inherently complex with high stakes for data consistency bugs. The codebase spans multiple transaction models (AT/TCC/SAGA/XA) which increases surface area; Java 18+ MB suggests tight coupling potential. Apache incubation status means governance is still stabilizing. Single repository (no known major forks) concentrates ecosystem risk.

Active development toward v2.x stability: v2.6.0 is current, with v2.5.0 and v2.4.0 recent releases. GitHub workflows run on every push (build.yml, test-ubuntu.yml, test-druid.yml). License compliance checks (licenserc.yaml) and code quality scanning (CodeQL, spotless formatting) are enforced. Docker publishing workflow suggests container-first deployment focus.

git clone https://github.com/apache/incubator-seata.git
cd incubator-seata
mvn clean install -DskipTests
# For the TC server: mvn clean package -DskipTests
cd seata-server && mvn package

Daily commands:

# Build all modules
mvn clean package -DskipTests

# Run TC server (Seata coordinator)
cd seata-server
java -jar target/seata-server.jar

# Or via Docker (see publish-docker.yml)
docker run -p 8091:8091 -p 7091:7091 apache/seata-server:latest

# Verify with client in seata-spring-boot-starter examples

• common/src/main/java/org/apache/seata/common/Constants.java — Defines all core constants used throughout Seata, essential for understanding transaction IDs, configuration keys, and protocol defaults.
• common/src/main/java/org/apache/seata/common/XID.java — Implements the global transaction ID generation and parsing logic, critical to Seata's distributed transaction coordination mechanism.
• common/src/main/java/org/apache/seata/common/exception/FrameworkException.java — Base exception class for the framework; understanding exception hierarchy is essential for error handling across all modules.
• common/src/main/java/org/apache/seata/common/ConfigurationKeys.java — Central registry of configuration property keys; required reading for feature integration and property-driven behavior.
• bom/pom.xml — Bill of Materials controlling dependency versions across all modules; critical for maintaining consistency and avoiding version conflicts.
• .github/workflows/build.yml — Defines the CI/CD pipeline and build validation process; essential for understanding how code is tested and released.

• Transaction Coordinator (TC) (Java, RPC (gRPC or HTTP), persistent storage (MySQL, PostgreSQL, Consul, Nacos)) — Central authority managing global transaction lifecycle, persistence, and atomic commit/rollback decisions across all branches.
  • Failure mode: If TC is unavailable, pending transactions become stuck; recovery requires TC restart with state reload from persistent store. Requires quorum consensus in HA cluster.
• Resource Manager (RM) (JDBC proxy, SQL parsing, local transaction management) — Intercepts local SQL execution, manages branch transaction registration, undo-log generation, and local rollback execution.
  • Failure mode: RM failure leaves unresolved branch state; TC may timeout and force rollback via undo logs. Network partitions between RM and TC risk transaction inconsistency.
• Transaction — undefined

Add a New Configuration Property

1. Define the configuration key constant in ConfigurationKeys.java (common/src/main/java/org/apache/seata/common/ConfigurationKeys.java)
2. Set a sensible default value in DefaultValues.java (common/src/main/java/org/apache/seata/common/DefaultValues.java)
3. Document the property in the changelog for the next version (changes/en-us/2.x.md)

Add a New Exception Type

1. Create a new exception class extending FrameworkException in the exception package (common/src/main/java/org/apache/seata/common/exception/)
2. Register the error code in FrameworkErrorCode.java (common/src/main/java/org/apache/seata/common/exception/FrameworkErrorCode.java)
3. Use the new exception in domain-specific error handling paths across modules (common/src/main/java/org/apache/seata/common/exception/)

Create a New Feature Module

1. Create a new module directory with its pom.xml following the multi-module pattern (all/pom.xml)
2. Add the module as a dependency in bom/pom.xml for version management (bom/pom.xml)
3. Add integration tests to the GitHub Actions workflow (.github/workflows/build.yml)
4. Document the feature in the changelog (changes/en-us/2.x.md)

• Java / Maven — Seata is a JVM-based distributed transaction framework; Maven provides multi-module project structure and dependency management essential for coordinating many interdependent components.
• GitHub Actions — Enables automated CI/CD pipeline including build verification, Docker image publishing, and Maven Central release automation across multiple platforms.
• Multi-module Maven architecture — Seata splits transaction coordination (TC), transaction manager (TM), resource manager (RM), and common utilities into separate modules, each independently testable and deployable.

• Centralized Transaction Coordinator as separate deployment unit

  • Why: Simplifies cluster coordination and guarantees single source of truth for transaction state, but requires additional infrastructure compared to peer-to-peer approaches.
  • Consequence: Higher availability requirements for TC cluster, but stronger consistency guarantees and easier debugging of transaction state.

• Undo-log based rollback mechanism

  • Why: Allows rollback without understanding business logic semantics, works with any SQL database without special schema changes.
  • Consequence: Requires storage and log management overhead; not suitable for systems where exact rollback semantics cannot be expressed via SQL reversal.

• XID (Global Transaction ID) propagation through application context

  • Why: Enables transparent integration without modifying application business logic, leverages existing logging infrastructure.
  • Consequence: Requires careful context management in async/threaded scenarios; overhead of passing XID through every service call.

• Does not provide eventual consistency / saga pattern (AT mode is strong consistency only)
• Not a message queue or event streaming system; orchestrates existing SQL databases and resource managers
• Does not handle cross-timezone or distributed clock synchronization beyond NTP assumptions
• Not designed for real-time sub-millisecond transaction latency; optimized for data consistency at scale

TC server requires external config store (DB/Redis/Consul) — standalone mode needs explicit schema migration (check seata-server/src/main/resources/db/). Network partition handling is AT mode specific; TCC requires explicit try/confirm/cancel methods. Java version constraint likely Java 8+ based on Kotlin presence; check .mvn/jvm.config for compile flags. Undo-log table per business database is mandatory for AT mode but undocumented in file list. Spring integration assumes classpath scanning enabled.

• Two-Phase Commit (2PC) / Distributed Consensus — Seata's TCC mode is built on 2PC principles; understanding prepare/commit phases is essential for avoiding deadlocks and phantom reads across services
• Undo-log (Change Data Capture pattern) — AT mode's non-invasive consistency model relies on capturing SQL changes and rolling back via undo-log; core to Seata's ease-of-use advantage
• Saga Pattern (Choreography vs Orchestration) — Seata implements orchestration-style SAGA transactions via TC server; distinguishing from event-driven choreography impacts resilience and debugging
• Try-Confirm-Cancel (TCC) / Compensating Transactions — TCC mode requires explicit try/confirm/cancel method pairs; understanding idempotency and compensation is critical for correct implementation
• Global Transaction ID (XID) / Context Propagation — XID threading through request headers and RPC contexts is the cornerstone of tracing transactions across service boundaries
• Netty Async I/O & Channel Management — TC-to-microservice communication is Netty-based; understanding channel pooling and async RPC handling is needed for debugging network issues
• State Machine (Transaction State Transitions) — Seata's TC manages global and branch transaction states (Begin → Committing → Committed) with strict state transitions; crashes can leave dangling states

• dtm-labs/dtm — Go-based distributed transaction manager solving same problem (AT/TCC/SAGA modes) with cross-language support; design patterns directly comparable
• apm-with-elastic-stack/demo — Observability companion; distributed transaction tracing critical for debugging Seata transaction flows at scale
• apache/dubbo — Java RPC framework frequently paired with Seata in microservices stacks; Dubbo services call Seata TC for transaction coordination
• alibaba/nacos — Service registry + config center used by Seata for TC server discovery and dynamic property management in production deployments
• alibaba/fescar — Historical predecessor; Seata is the evolved version donated to Apache; design principles and AT mode algorithm inheritance

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for distributed transaction scenarios in test-druid.yml workflow

The repo has a dedicated test-druid.yml workflow but lacks visible integration tests that validate Seata's core distributed transaction functionality across different database drivers. New contributors could add end-to-end tests covering AT mode, TCC mode, and SAGA mode with real database connections to catch regressions early.

• [ ] Review existing .github/workflows/test-druid.yml and test.yml to understand current test coverage
• [ ] Create integration test classes in seata-server module validating AT/TCC/SAGA transaction flows
• [ ] Add test cases for transaction rollback scenarios with Druid connection pools
• [ ] Extend test-druid.yml workflow to run these integration tests against multiple database versions
• [ ] Document test execution requirements in CONTRIBUTING.md

Implement missing changelog entries and standardize changes/ directory structure for recent versions

The changes/ directory shows gaps (no 2.7.0.md, 2.8.0.md files visible) and lacks a standardized template format across existing change logs. This impacts release documentation and version tracking. Contributors could establish a changelog generation pipeline and backfill missing versions.

• [ ] Audit changes/en-us/ and changes/zh-cn/ directories to identify missing versions between 2.6.0 and latest
• [ ] Create a CHANGELOG_TEMPLATE.md with required sections (Features, Bugfixes, Breaking Changes, Dependencies)
• [ ] Add a GitHub Action workflow (.github/workflows/changelog-validate.yml) to validate changelog format on PRs
• [ ] Backfill missing changelog files for recent releases using git commit history
• [ ] Update CONTRIBUTING.md with changelog contribution guidelines

Add security vulnerability disclosure workflow and SECURITY.md enhancement with automated scanning

While SECURITY.md exists, there's no automated dependency vulnerability scanning in the CI/CD pipeline. Given Seata's distributed transaction criticality, adding automated security checks and a clear vulnerability reporting workflow would significantly improve project security posture.

• [ ] Review existing SECURITY.md and enhance with security contact, response timeline, and disclosure policy
• [ ] Create .github/workflows/security-scan.yml with OWASP Dependency-Check or similar scanning tools
• [ ] Integrate Snyk or GitHub's native Dependabot configuration (.github/dependabot.yml) for continuous monitoring
• [ ] Add security-related issue templates in .github/ISSUE_TEMPLATE/ for vulnerability reports
• [ ] Configure branch protection rules to require security scan passes before merge

• Add integration tests for XA mode with PostgreSQL/MySQL in test-ubuntu.yml — currently test-druid.yml covers AT/TCC; XA tests appear absent based on workflow file absence.
• Create Kotlin migration helpers in the seata-kotlin/ module (16KB exists) to simplify Seata client setup with coroutines and Flow-based transaction boundaries.
• Document and test recovery scenarios: add a recovery-demo/ with examples of TC restart, TC crash during 2PC, and network partition handling to .github/workflows/ as a new integration test.

The Apache Seata project demonstrates a reasonable security foundation with ASF sponsorship, proper licensing, and CI/CD pipelines. However, several areas need improvement: (1) The SECURITY.md policy is incomplete/truncated, (2) Complete dependency information is not provided for analysis, (3) Code review enforcement via CODEOWNERS is missing, and (4) Supply chain security controls are not evident in the provided structure. The project should prioritize completing security documentation, implementing comprehensive dependency scanning in CI/CD, and establishing formal code review requirements for security-sensitive components. The presence of multiple test workflows and build configurations requires standardization to ensure consistent security practices.

• Medium · Incomplete Security.md Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated or incomplete, cutting off mid-sentence at 'https://apache.org/security/#vulnerability'. This may indicate missing critical security policy information for contributors and users reporting vulnerabilities. Fix: Complete the SECURITY.md file with full vulnerability disclosure policy, contact information for security issues, and expected response timelines. Ensure it clearly states the process for reporting security vulnerabilities.
• Medium · Incomplete Dependency Analysis — all/pom.xml. The provided pom.xml file for seata-all module appears incomplete, showing only the parent reference and dependencyManagement section without the actual dependencies list. This prevents full assessment of potential vulnerable dependencies. Fix: Review the complete pom.xml file including all declared dependencies. Implement dependency scanning using tools like OWASP Dependency-Check or Snyk in CI/CD pipeline. Regularly update dependencies to patch security vulnerabilities.
• Low · Multiple Build Workflow Files Present — .github/workflows/. Multiple GitHub Actions workflow files for building and testing (.github/workflows/build.yml, test.yml, test-ubuntu.yml, test-druid.yml) suggest potential for inconsistent security configurations across different build pipelines. Fix: Consolidate and standardize workflow configurations where possible. Ensure all workflows follow the same security scanning, dependency checking, and code quality standards. Document the purpose of each workflow file.
• Low · Missing CODEOWNERS File — Root directory. No CODEOWNERS file found in the repository structure, which means there's no enforced code review policy for security-sensitive files. Fix: Create a .github/CODEOWNERS file to specify code owners for security-sensitive directories (e.g., authentication, encryption, configuration modules) and require their review for pull requests.
• Low · No Evidence of Supply Chain Security Controls — Repository root and CI/CD configuration. No visible evidence of supply chain security measures such as SBOM generation, artifact signing, or provenance tracking in the provided file structure. Fix: Implement SLSA framework controls, generate Software Bill of Materials (SBOM), sign releases, and maintain artifact provenance. Document supply chain security practices in SECURITY.md.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.