zyr/FT546MWS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: cap concurrent shadow planning

Browse Source
This commit is contained in:
zgw
2026-08-11 20:04:31 +08:00
parent 6a870601b5
commit 6738eff609
4 changed files with 76 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/superpowers/specs/2026-08-11-ft546wms-shadow-only-design.md
View File

@@ -13,6 +13,7 @@ Create a clean field-test branch directly from `origin/main` that runs the Java
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.
7. Shadow observation is disabled by default and must be enabled explicitly in the IDEA Run Configuration.
8. At most one shadow planning operation runs per JVM. Concurrent observations are skipped immediately without queueing or delaying Legacy allocation.
## Architecture
@@ -20,7 +21,7 @@ The existing `fortucky-algorithm` planner and JDBC read model are reused as an i
- `ShadowObservationProperties` controls enablement, warehouse fallback, and timeout.
- `ShadowSafetyGuard` validates the effective mode at startup.
- `ShadowPlanningObserver` performs fail-open inbound/outbound planning in an independent transaction and returns an immutable observation token.
- `ShadowPlanningObserver` performs fail-open inbound/outbound planning in an independent transaction, admits at most one plan per JVM, and returns an immutable observation token.
- Legacy services invoke the observer immediately before their existing stored procedure, execute the original Legacy code unchanged, then submit the Legacy result for comparison logging.
There are no algorithm controllers, ACTIVE schedulers, workflow callbacks, reservation calls, or changes to the frontend.
@@ -45,7 +46,7 @@ There are no algorithm controllers, ACTIVE schedulers, workflow callbacks, reser
## Transaction and failure isolation
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.
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. A JVM-local nonblocking gate permits one planning call at a time; a concurrent call returns an empty observation immediately, while successful and failed calls both release the gate in `finally`. Comparison logging is not gated. 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.