docs: point markdown backlogs at Gitea issues (status lives in Gitea)

This commit is contained in:
Joseph Doherty
2026-11-06 15:31:44 -05:00
parent 10c04a23d7
commit 0e89966da6
9 changed files with 75 additions and 49 deletions
@@ -1,6 +1,8 @@
# Known issue — inbound API method compile errors are not client-visible; no on-demand validation (2026-06-25 session)
**Status:** OPEN · **Found:** 2026-06-25 · **Context:** live ops session on `wonder-app-vd03` — three deployed inbound methods (`IpsenMESMoveIn`, `MesMoveIn`, `MesMoveOut`) returned `Script compilation failed for this method` after being authored from a design doc that used the wrong DB-helper name (`Database.QuerySingle<T>` instead of the shipped async `Database.QuerySingleAsync<T>`). Diagnosing the *actual* Roslyn error required an SSH dive into the central log; nothing in the CLI or the Management/data-plane API surfaces it.
> **Status lives in Gitea.** Open items from this file are tracked as issues on gitea.dohertylan.com/dohertj2/ScadaBridge (label `migrated`, 2026-11-06). This file is a historical/design record — do not track status here; file new work as an issue.
**Status:** OPEN → #75 · **Found:** 2026-06-25 · **Context:** live ops session on `wonder-app-vd03` — three deployed inbound methods (`IpsenMESMoveIn`, `MesMoveIn`, `MesMoveOut`) returned `Script compilation failed for this method` after being authored from a design doc that used the wrong DB-helper name (`Database.QuerySingle<T>` instead of the shipped async `Database.QuerySingleAsync<T>`). Diagnosing the *actual* Roslyn error required an SSH dive into the central log; nothing in the CLI or the Management/data-plane API surfaces it.
**Components:** Inbound API (#14), CLI (#19), Management Service (#18)
Issues are listed worst-first. Severities are author estimates. Neither item caused data loss — once the scripts were corrected via `UpdateApiMethod` they compiled and ran (verified with a live `MesMoveIn` test against the `Z28061Sim` instance: `{"WasSuccessful":true,"ErrorText":"","BatchID":0}`).
@@ -9,7 +11,7 @@ Related: the runtime mechanics behind both items are captured in the recall note
---
## 1. The real inbound-script compile error is server-log-only; there is no `api-method validate`
## 1. The real inbound-script compile error is server-log-only; there is no `api-method validate` → #75
**Severity:** Medium · **Components:** Inbound API (#14), CLI (#19), Management Service (#18)
**Symptom:** When an inbound method's script fails to compile, every caller of `POST /api/{method}` gets the same generic body — `Script compilation failed for this method` — with no diagnostic. The actual Roslyn error (e.g. `'InboundDatabaseHelper' does not contain a definition for 'QuerySingle'`) is written **only** to the central server log. There is no CLI command and no API verb to (a) retrieve the last compile error for a method, or (b) compile/validate a method's script on demand the way templates can be validated.
@@ -40,7 +42,7 @@ Returning the raw Roslyn text to an *external, API-key* caller is the right defa
---
## 2. The `_knownBadMethods` cache is neither observable per-method nor resettable without a full-replace update
## 2. The `_knownBadMethods` cache is neither observable per-method nor resettable without a full-replace update → #75
**Severity:** Low-Medium · **Components:** Inbound API (#14)
**Symptom:** Once a method's script fails to compile, its name is recorded in an in-memory bad-methods set and every later request **short-circuits** to the generic message *without recompiling*. Consequences observed/known: