docs: add IDEA shadow deployment and rollback guide

This commit is contained in:
zgw
2026-08-11 19:38:26 +08:00
parent 8b050ac9d6
commit 2fbb20c5b1
5 changed files with 365 additions and 9 deletions

View File

@@ -4,7 +4,7 @@
**Goal:** Build a clean `origin/main`-based branch that observes inbound and outbound allocation with the Java algorithm while preserving every Legacy decision and business write.
**Architecture:** Reuse the existing `fortucky-algorithm` planner as an internal module, but expose it to WMS only through a fail-open shadow gateway. The gateway plans in a separate timed transaction; the original Legacy procedures remain unchanged and authoritative. A reduced SQL package installs only read-model and diagnostic objects.
**Architecture:** Reuse the existing `fortucky-algorithm` planner as an internal module, but expose it to WMS only through a fail-open shadow gateway. The gateway plans in a separate timed `READ_UNCOMMITTED` transaction; the original Legacy procedures remain unchanged and authoritative. A reduced SQL package installs only read-model and diagnostic objects, creates no Legacy-table triggers, and refreshes its read model in full before planning.
**Tech Stack:** Java 17, Spring Boot, Spring JDBC transactions, MyBatis, SQL Server 2016, JUnit 5, Mockito, AssertJ, Maven 3.9.11.
@@ -15,6 +15,7 @@
- Legacy procedures execute exactly once and their current response construction remains authoritative.
- Shadow observation is disabled by default and fails open on every runtime error.
- Shadow database scripts never insert, update, or delete WMS business rows.
- Shadow database scripts never create triggers on WMS business tables.
---
@@ -113,10 +114,10 @@
- Test: `fortucky-algorithm/src/test/java/com/ruoyi/algorithm/repository/ShadowSqlServerMigrationScriptTest.java`
**Interfaces:**
- Produces: read-model tables/views/procedures, decision log, dirty-lane queue, and three enqueue-only business-table triggers.
- Produces: read-model tables/views/procedures and decision log; planning performs a full warehouse-scoped read-model refresh.
- Excludes: ACTIVE mutation procedures and WMS business-table DML.
- [ ] Write static SQL tests with an allow-list for tables, views, procedures, and triggers; reject tidy/workflow/replay/reservation mutation names and business-table DML.
- [ ] Write static SQL tests with an allow-list for tables, views, and procedures; reject all triggers, dirty queues, tidy/workflow/replay/reservation mutation names, and business-table DML.
- [ ] Add an install/uninstall symmetry test and a test requiring initial synchronization plus diagnostic queries.
- [ ] Run focused tests and confirm RED because scripts are absent.
- [ ] Build the reduced scripts from the reviewed SQL Server 2016-compatible read-model portions.

View File

@@ -8,7 +8,7 @@ Create a clean field-test branch directly from `origin/main` that runs the Java
1. The branch is based on `origin/main` and contains no license, UI, TLS, tidy, replay, PDA, WCS callback, or ACTIVE workflow integration changes.
2. Legacy stored procedures are called exactly once with the same inputs and their return values remain authoritative.
3. Shadow planning runs before the Legacy allocation so it observes the pre-decision state, but it runs in a separate `REQUIRES_NEW` transaction with a configurable timeout.
3. Shadow planning runs before the Legacy allocation so it observes the pre-decision state, but it runs in a separate `REQUIRES_NEW`, `READ_UNCOMMITTED` transaction with a configurable timeout.
4. A shadow exception, timeout, missing optional input, missing algorithm object, or comparison logging failure is caught and logged; it cannot skip, replace, roll back, or rewrite the Legacy result.
5. No ACTIVE entry point is exposed by `ruoyi-admin`. Startup rejects any algorithm mode other than `SHADOW` when shadow observation is enabled.
6. Shadow mode writes only `alg.*` read-model and diagnostic objects. It never calls reservation, tidy, deep-workflow, replay, move-completion, or other procedures that write WMS business tables.
@@ -45,7 +45,7 @@ There are no algorithm controllers, ACTIVE schedulers, workflow callbacks, reser
## Transaction and failure isolation
Shadow planning uses `TransactionTemplate` with `PROPAGATION_REQUIRES_NEW`, read-model writes enabled, and a short timeout. The transaction completes or rolls back before Legacy allocation starts, so algorithm locks and rollback state cannot leak into the Legacy transaction. The adapter catches runtime failures at its public boundary and returns an empty observation.
Shadow planning uses `TransactionTemplate` with `PROPAGATION_REQUIRES_NEW`, `ISOLATION_READ_UNCOMMITTED`, read-model writes enabled, and a short timeout. The transaction completes or rolls back before Legacy allocation starts, so algorithm locks and rollback state cannot leak into the Legacy transaction. The adapter catches runtime failures at its public boundary and returns an empty observation.
The integration never queries `alg.tidy_mode` and never uses an update lock for admission control.
@@ -55,13 +55,13 @@ The integration never queries `alg.tidy_mode` and never uses an update lock for
- policy/read-model/diagnostic tables required by inbound and outbound planning;
- read-only views over WMS business data;
- topology, snapshot, lane-state, dirty-lane refresh, and decision-log support;
- three narrowly scoped `dbo` triggers that only enqueue affected lanes into `alg.dirty_lane_queue`;
- topology, snapshot, lane-state, full-refresh, and decision-log support;
- no triggers on any Legacy WMS table and no dirty-lane queue;
- initial read-model synchronization.
It excludes tidy, replay, reservation mutation procedures, deep workflow, outbound workflow, WCS completion, PDA callback, and any stored procedure that inserts, updates, or deletes WMS business rows.
`uninstall-shadow.sql` first removes the three `dbo` triggers, then removes only shadow-owned `alg` objects and the `alg` schema. It never modifies WMS business rows. Operators must export `alg.decision_log` before uninstalling.
`uninstall-shadow.sql` removes only shadow-owned `alg` objects and the `alg` schema. It never modifies WMS business rows. Operators must export `alg.decision_log` before uninstalling.
## Configuration
@@ -85,7 +85,7 @@ Automated tests prove:
- missing project/stock input still invokes Legacy exactly once;
- Legacy result and response structure remain authoritative;
- SHADOW configuration rejects ACTIVE mode;
- shadow SQL contains only allow-listed objects and no WMS business-table DML;
- shadow SQL contains only allow-listed `alg` objects, no triggers, and no WMS business-table DML;
- install/uninstall object lists are symmetrical;
- existing project tests and packaging still succeed.