toga-ai 1.0.698 → 1.0.699

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -349,6 +349,30 @@ Used for fields SuiteQL doesn't expose on `transaction`: `shippingCost`, `taxTot
349
349
  when `fetchItemFulfillmentById` returned zero lines — see
350
350
  [NYCHH inventory-adjustment → item-fulfillment linking](../../../clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md).
351
351
 
352
+ ### `fetch*ById()` single-record helpers — the REST replacements for the SOAP `App_NetSuite::get*`
353
+
354
+ The togasupply importer fetches individual records by internal id through a family of `fetch*ById()`
355
+ helpers on `App_Api_Netsuite_Rest`, each assembling a SOAP-shaped shim from a SuiteQL header/lines
356
+ query plus (where needed) a REST record GET. As of **2026-08-29 the togasupply sync path uses these
357
+ exclusively — zero `App_NetSuite::` SOAP network calls remain** in `common_sync_togasupply.php` or the
358
+ `*FromNetsuite()` methods:
359
+
360
+ - **`fetchItemReceiptById`** — header + lines + serials (serials via SuiteQL
361
+ `inventoryassignment ⋈ inventorynumber`, grouped per product). Replaces SOAP
362
+ `getItemReceipt`/`getInventoryNumber*`/`getItemIsSerialized`.
363
+ - **`fetchPurchaseOrderById`** / **`fetchSalesOrderByIdFull`** — replace SOAP `getPurchaseOrder` /
364
+ `getSalesOrder`.
365
+ - **`fetchItemFlagsByIds`** — batch item serialized/fulfillable flags; replaces
366
+ `getItemSerializedAndFulfillable`.
367
+ - **`fetchInventoryAdjustmentById`** — replaces the `diagnose_hh` script's SOAP `getObject`.
368
+ - **`fetchInvoiceFile`** — SuiteQL `file`-table lookup + REST `GET /record/v1/file/{id}` content,
369
+ `base64_decode` → raw bytes. Replaces SOAP `getInvoiceFile`.
370
+
371
+ `listCustomers()` also gained a **`companyName`** field on its shim (the `netsuite_customers.php` cron
372
+ moved from `listAllCustomers` → `listCustomers`). REST-shim *shape* traps that bite these helpers (an
373
+ absent nested list crashes 1.0; `scriptId` case-sensitivity on `customFieldList`) are in
374
+ [`netsuite-suiteql-rest-shim.md`](netsuite-suiteql-rest-shim.md).
375
+
352
376
  ## `list*()` helpers — behavior & cost
353
377
 
354
378
  `listSales()`, `listSalesOrders()`, `listOpportunities()` all:
@@ -418,6 +442,13 @@ numbers. Budget hours for multi-year runs and launch them under `nohup`/`tmux`.
418
442
 
419
443
  ## Change history
420
444
 
445
+ - 2026-08-29 — Documented the **`fetch*ById()` single-record helper family** (`fetchItemReceiptById`,
446
+ `fetchPurchaseOrderById`, `fetchSalesOrderByIdFull`, `fetchItemFlagsByIds`,
447
+ `fetchInventoryAdjustmentById`, `fetchInvoiceFile`) that replaced the SOAP `App_NetSuite::get*` calls,
448
+ and the `listCustomers` `companyName` addition — the togasupply sync path now makes **zero
449
+ `App_NetSuite::` SOAP network calls**. Added while root-causing the 5 stuck togasupply integrations as
450
+ REST-shim shape mismatches (see the
451
+ [per-client-sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md)). (jcardinal)
421
452
  - 2026-08-29 — Recorded two NetSuite REST/SuiteQL facts from the NYCHH inventory-adjustment →
422
453
  item-fulfillment **REST migration**: **REST record sublist endpoints
423
454
  (`/record/v1/{type}/{id}/{sublist}`) reject `limit`/`offset` with a 400 `INVALID_PARAMETER`** (a
@@ -6,7 +6,7 @@ project: Library
6
6
  client: shared
7
7
  type: feature
8
8
  status: active
9
- updated: 2026-08-27
9
+ updated: 2026-08-29
10
10
  owners: [dfranks, jcardinal, kyalamarthi]
11
11
  files:
12
12
  - library/app/api/netsuite/rest.php
@@ -112,6 +112,29 @@ Forecast2 tables already store.
112
112
  TransferOrders). A custom field absent from the record reads as null downstream. See
113
113
  [NYCHH NetSuite → TransferOrders import](../../../clients/nychh/features/netsuite-transfer-order-import.md).
114
114
 
115
+ - **⚠ `scriptId` in a `customFieldList` def is CASE-SENSITIVE on lookup — a case skew silently
116
+ returns the default (2026-08-29).** `custbody_stocking_order` was **tagged** in the shim with the
117
+ uppercase scriptId `CUSTBODY_STOCKING_ORDER` but **read** by the importer as lowercase
118
+ `custbody_stocking_order`, so the lookup never matched and always fell back to the default (unchecked)
119
+ — which mis-routed **every** NYCHH order to a Transfer Order. Fixed by lowercasing the scriptId in
120
+ **both** `buildSalesOrderShims()` and `fetchSalesOrderById()` defs; `END_CUSTOMER` is intentionally
121
+ left uppercase because it is resolved by internalId `3149`, not by scriptId. Nothing errors on a case
122
+ skew — the field just reads as its default — so verify the exact scriptId string on both the write and
123
+ the read side. See [NYCHH TransferOrders import](../../../clients/nychh/features/netsuite-transfer-order-import.md).
124
+
125
+ - **A shim must produce the SOAP object's SHAPE, not just its scalar fields — an absent nested list
126
+ crashes 1.0 (2026-08-29).** `fetchCustomerById()`'s `addressbookList` was where the AIG lookup phase
127
+ crashed: a REST customer with no/odd address made the shim omit the nested `addressbook` structure the
128
+ old SOAP object always carried, and the downstream unguarded read raised a warning → `App_Error`
129
+ `exit()` (see the `getCustomFieldValue` warning-safety gotcha below — same class). It now builds
130
+ `addressbookList` via a `shimAddress()` helper that normalizes `country` to the `_unitedStates` enum
131
+ and returns an **empty `addressbook: []`** when there is no address, so the shape always matches;
132
+ two helpers were extracted for reuse — `countryToSoapEnum()` (country string → SOAP enum) and
133
+ `refString()`. This is the concrete "REST shim returns null/absent where SOAP had a value" failure
134
+ the [per-client-sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md) diagnoses via
135
+ `Logs.Issue`/`Logs.Event`. **When adding or editing a shim, reproduce the full SOAP shape (including
136
+ empty nested lists), not just the fields you happen to need.**
137
+
115
138
  ## Transaction status sourcing (1.0) — and the 2026.2 REST `status.id` change
116
139
 
117
140
  1.0 reaches NetSuite over **two transports, and neither reads status off a REST record GET
@@ -192,6 +215,17 @@ None — uniform across clients (NetSuite is a single shared account).
192
215
 
193
216
  ## Change history
194
217
 
218
+ - 2026-08-29 — Recorded two shim-shape facts from root-causing the 5 stuck togasupply integrations
219
+ (which were **shim-shape mismatches, not dead SOAP** — see the
220
+ [per-client-sync doc](../../worker/features/netsuite-togasupply-per-client-sync.md)): a
221
+ `customFieldList` **`scriptId` is case-sensitive on lookup** — `CUSTBODY_STOCKING_ORDER` (write) vs
222
+ `custbody_stocking_order` (read) silently returned the default and mis-routed every NYCHH order to a
223
+ Transfer Order (fixed by lowercasing in both `buildSalesOrderShims`/`fetchSalesOrderById`;
224
+ `END_CUSTOMER` stays uppercase, resolved by internalId 3149); and a shim must reproduce the SOAP
225
+ object's **full shape** — `fetchCustomerById()`'s `addressbookList` omitting the nested `addressbook`
226
+ crashed the AIG lookup phase (unguarded null read → warning → `exit()`), now built via `shimAddress()`
227
+ (country → `_unitedStates` enum, empty → `addressbook: []`) with extracted `countryToSoapEnum()` /
228
+ `refString()` helpers. (jcardinal)
195
229
  - 2026-08-27 — **Traced the missing `tl.location` SELECT to its cause — a merge, not an omission — and
196
230
  recorded what restoring it re-animates** (forecast2 open-orders, TRUE-79162). TRUE-79078 (31fadd77)
197
231
  originally added `tl.location` + `BUILTIN.DF(tl.location)`; merge c3caa11a (2026-06-24) resolved in
@@ -6,7 +6,7 @@ project: Library
6
6
  client: shared
7
7
  type: feature
8
8
  status: active
9
- updated: 2026-08-17
9
+ updated: 2026-08-29
10
10
  owners: [jcardinal, mhammontree, bala]
11
11
  files:
12
12
  - library/app/api/toga2.php
@@ -396,6 +396,15 @@ enable flags** and an optional `$monitorTogadeskDepartmentIds[]`:
396
396
 
397
397
  ## Change history
398
398
 
399
+ - 2026-08-29 — The `*FromNetsuite()` importer methods in this class were **completed onto REST** — the
400
+ item-receipt and inventory-adjustment paths dropped their last `App_NetSuite::` SOAP calls in favor of
401
+ `App_Api_Netsuite_Rest::fetch*ById()`, so the togasupply importer now makes **zero SOAP network
402
+ calls**. Also **corrects the 2026-08-27 entry below**: the private `isStockingOrder()` custom-field
403
+ read had a `scriptId` case-mismatch (`CUSTBODY_STOCKING_ORDER` vs `custbody_stocking_order`) that
404
+ silently defaulted and mis-routed every NYCHH order — now fixed. Method-level detail and the full
405
+ per-client fix set live on
406
+ [NetSuite → TOGa Supply per-client sync](../../worker/features/netsuite-togasupply-per-client-sync.md)
407
+ (2026-08-29). (jcardinal)
399
408
  - 2026-08-27 — `send()`'s throw sites were **reverted to plain `throw new Exception(...)`** (both
400
409
  sites) as part of removing the sync engine's swallow-and-skip data-loss bug — the importer must
401
410
  propagate a failed write, not catch it (see
@@ -6,7 +6,7 @@ project: Worker
6
6
  client: shared
7
7
  type: feature
8
8
  status: active
9
- updated: 2026-08-28
9
+ updated: 2026-08-29
10
10
  owners: ["dfranks", "bala", "jcardinal", "mhammontree", "snaredla"]
11
11
  files:
12
12
  - worker/crons/toga2/netsuite/common_sync_togasupply.php
@@ -531,8 +531,96 @@ Parameters are stored **per client DB** but accessed **through the TOGa2 API**,
531
531
  direct-FK-column change) on
532
532
  [NYCHH inventory-adjustment → item-fulfillment linking](../../../clients/nychh/features/netsuite-inventory-adjustment-fulfillment-link.md).
533
533
 
534
+ - **⚠ 2026-08-29: the 5 stuck togasupply integrations were REST-shim SHAPE mismatches, NOT dead
535
+ SOAP — and how to tell them apart.** Five clients had a section frozen at `RUNNING` and the first
536
+ hypothesis was "SOAP is down." **SOAP was up.** The real cause was introduced by the earlier
537
+ SOAP→REST list-method conversion: a REST shim returns `null`/absent where the old SOAP object
538
+ carried a value, and in 1.0 **any unguarded read of that null raises a PHP warning that
539
+ `App_Error` escalates to `exit()`** (see the 1.0 backend-php standard *Any PHP warning terminates
540
+ the request*, and the [rest-shim warning-safety gotcha](../../library/features/netsuite-suiteql-rest-shim.md)).
541
+ The `exit()` mid-section leaves that record-type's `NETSUITE_EXECUTION_MODE_*` stuck at `RUNNING`
542
+ with the watermark frozen — i.e. **a shim-shape mismatch presents identically to a poison order.**
543
+ So a stuck section is never "SOAP is dead"; it is one specific record hitting one specific
544
+ unguarded shim field.
545
+ **Diagnosis playbook (durable):** query prod **`Logs.Issue` + `Logs.Event`** (the
546
+ `App_Error_Capture` tables, schema `Logs`, via the toga-db MCP) for the client's `clientId` — each
547
+ stuck section maps to an exact crash **file:line** in `common_sync_togasupply.php` or `toga2.php`.
548
+ The `RUNNING` mode + frozen watermark **is** the stuck signal (see the window/watermark gotchas
549
+ above); `Logs.Issue`/`Event` turns it into a line number, far faster than reading the cron blind.
550
+ **Per-client fixes shipped (all in `library`, `php -l` clean, and fail-loud — a genuinely
551
+ unresolvable case now throws rather than silently continuing):**
552
+ - **Item receipts — Canon + Endeavor Health** (`syncItemReceiptFromNetsuite`): migrated off SOAP to
553
+ new REST `fetchItemReceiptById` (header + lines + serials via SuiteQL
554
+ `inventoryassignment ⋈ inventorynumber`, serials grouped per product) + `fetchPurchaseOrderById`
555
+ + `fetchItemFlagsByIds`; removed all `App_NetSuite::` SOAP calls (`getItemReceipt` /
556
+ `getPurchaseOrder` / `getItemIsSerialized` / `getInventoryNumber*`). Guards added;
557
+ **`RtnAuth` (return-authorization) item receipts are intentionally NOT imported** (explicit
558
+ documented skip), and an **unknown `createdFrom` type throws**.
559
+ - **Purchase orders** (`syncPurchaseOrderFromNetsuite`): a missing PO entity now **throws** (was an
560
+ unguarded crash); `getSalesOrder` → REST `fetchSalesOrderByIdFull`; a `2400` ACL-strip that used
561
+ to skip now **throws**. Threaded a new `array &$lookupWarehouseByNetsuiteLocationInternalId` param
562
+ from **both** callers — which also fixed a **null `arg13` `TypeError`** into
563
+ `syncSalesOrderFromNetsuite`.
564
+ - **Transfer orders — GroWrk `SALES_ORDERS`** (`syncTransferOrderFromNetsuite`): fixed an
565
+ all-catalog lookup that read `->uuid` off the array instead of `[0]`; an **unmapped NetSuite TO
566
+ status now throws** (was default-to-pending + log).
567
+ - **Item fulfillments — Elite (also Quad / S&P Global / Prudential-EDI)**
568
+ (`syncItemFulfillmentFromNetsuite`): the "Undefined index" on service/shipping lines with an
569
+ **empty `orderLine`** (`$lookupNsSalesOrderItemsByOrderLine['']`) is now guarded so it falls
570
+ through to the existing reconstruct path.
571
+ - **NYCHH stocking-order routing** — the `isStockingOrder` scriptId **case-mismatch** (full detail
572
+ in the [rest-shim doc](../../library/features/netsuite-suiteql-rest-shim.md)): the custom field was
573
+ tagged `CUSTBODY_STOCKING_ORDER` but looked up lowercase → always returned the default →
574
+ **every NYCHH order was mis-routed to a Transfer Order.** Fixed by lowercasing the scriptId in
575
+ both shim defs.
576
+ - **AIG lookup-phase crash** — `fetchCustomerById`'s `addressbookList` is now built via `shimAddress`
577
+ (country normalized to the `_unitedStates` enum, empty → `addressbook: []`); extracted
578
+ `countryToSoapEnum()` + `refString()` helpers, plus a belt-and-suspenders guard in
579
+ `common_sync_togasupply.php`.
580
+
581
+ - **SOAP→REST is now COMPLETE for the togasupply sync path (2026-08-29).** With the item-receipt and
582
+ (2026-08-29) inventory-adjustment migrations plus the new `fetch*ById` methods, **zero
583
+ `App_NetSuite::` (SOAP) network calls remain** anywhere in the `common_sync_togasupply.php` engine
584
+ or the `*FromNetsuite()` methods it calls — so the whole tier-wide-freeze class above is now driven
585
+ by REST-shim shape, not SOAP availability. New REST completeness pieces built in `library`:
586
+ `fetchInvoiceFile` (SuiteQL `file` lookup + REST `GET /record/v1/file/{id}` content, `base64_decode`
587
+ → raw bytes; replaces `getInvoiceFile`), `getItemSerializedAndFulfillable` → `fetchItemFlagsByIds`,
588
+ the `diagnose_hh` script's `getObject` → `fetchInventoryAdjustmentById`, and
589
+ `worker/crons/sync/netsuite/netsuite_customers.php` `listAllCustomers` → `listCustomers` (with
590
+ `companyName` added to the `listCustomers` shim).
591
+
592
+ - **⚠ SALES_ORDERS line renumber is now a validate-before-mutate TWO-PHASE UPDATE (2026-08-29) —
593
+ supersedes the delete-recreate + pinned-skip approach.** `syncSalesOrderFromNetsuite`'s renumber no
594
+ longer DELETEs and re-creates lines (nor keeps un-deletable/invoiced rows at their old number — see
595
+ the 2026-08-17 pinned-skip gotcha above, now historical). It **parks** every drifting line at a
596
+ temporary `lineNumber` (base = `max(current, target lineNumbers) + headroom`, headroom const
597
+ **1000**), then **finalizes** each to its target — so `UNIQUE(salesOrderId, lineNumber)` is never
598
+ transiently violated and pinned FK-RESTRICT children (invoiced/fulfilled lines) renumber accurately
599
+ via `UPDATE` instead of being stranded at a stale number. It **throws BEFORE any PUT** if a kept or
600
+ undeletable row occupies a needed target, so a failure never leaves the order in a partial state.
601
+ Note `SalesOrderItems.lineNumber` is a **`smallint`**, so the parked base must stay within smallint
602
+ range for the client's line counts (headroom 1000 is safe at observed volumes).
603
+
534
604
  ## Change history
535
605
 
606
+ - 2026-08-29 — **Root-caused the 5 stuck togasupply integrations as REST-shim SHAPE mismatches, not
607
+ dead SOAP, and fixed them.** SOAP was up; the earlier SOAP→REST conversion left shims returning
608
+ null/absent where SOAP had values, and a 1.0 unguarded read of that null → PHP warning →
609
+ `App_Error` `exit()` → the section frozen at `RUNNING`/watermark stuck (presents identically to a
610
+ poison order). Recorded the durable diagnosis playbook (map each stuck `clientId`/section to a crash
611
+ file:line via prod `Logs.Issue`/`Logs.Event`, the `App_Error_Capture` tables). Shipped per-client
612
+ `library` fixes, all fail-loud: item-receipts SOAP→REST (`fetchItemReceiptById` +
613
+ `fetchPurchaseOrderById` + `fetchItemFlagsByIds`, RtnAuth skip, unknown `createdFrom` throws — Canon
614
+ + Endeavor Health); PO missing-entity throw + `arg13` warehouse-lookup TypeError fix +
615
+ `fetchSalesOrderByIdFull` + 2400-ACL throw; TransferOrder all-catalog `[0]`/`->uuid` fix + unmapped
616
+ status throw (GroWrk); IF empty-`orderLine` "Undefined index" guard (Elite/Quad/S&P/Prudential-EDI);
617
+ the `isStockingOrder` scriptId case-mismatch that mis-routed **every** NYCHH order to a Transfer
618
+ Order; and the AIG `fetchCustomerById` address-shim crash. Also **completed SOAP→REST for the whole
619
+ togasupply path** (zero `App_NetSuite::` network calls remain; new `fetchInvoiceFile` /
620
+ `fetchItemFlagsByIds` / `fetchInventoryAdjustmentById`, `listAllCustomers`→`listCustomers`+companyName),
621
+ and replaced the SALES_ORDERS renumber with a **validate-before-mutate two-phase UPDATE** (park at
622
+ temp lineNumbers, then finalize; throws before any PUT) superseding the delete-recreate + pinned-skip
623
+ approach. (jcardinal)
536
624
  - 2026-08-29 — The inventory-adjustment sync (and the on-demand fulfillment / sales-order import it
537
625
  triggers) in `syncInventoryAdjustmentFromNetsuite` was **migrated SOAP → REST/SuiteQL**, closing the
538
626
  SOAP round-trip cost flagged 2026-08-28; the remaining error-log-and-swallow `try/catch` in the
@@ -5,13 +5,14 @@ project: Library
5
5
  client: shared
6
6
  type: standard
7
7
  status: active
8
- updated: 2026-08-21
8
+ updated: 2026-08-29
9
9
  owners: [jcardinal, rgirish, mhammontree, ajean]
10
10
  files: []
11
11
  related:
12
12
  - ../apps/library/architecture.md
13
13
  - ../apps/library/features/email-queue-attachments.md
14
14
  - ../apps/library/features/error-capture-1-0.md
15
+ - ../apps/worker/features/netsuite-togasupply-per-client-sync.md
15
16
  - ../../2.0/standards/backend-php.md
16
17
  ---
17
18
 
@@ -507,9 +508,12 @@ Additional verified detail:
507
508
  - **Diagnostic fingerprint:** an occurrence count that is an exact multiple of the job's
508
509
  scheduled frequency (e.g. 20/hour for `*/3 * * * *`) means **one** poisoned item retried,
509
510
  not many distinct failures.
510
- - **In job code, prevention beats containment.** Guard optional data with `isset()` before
511
- reading it, and consume/ack the item in a `finally` (or under a `catch (Throwable)`) so a
512
- genuine exception cannot strand it. You cannot wrap your way out of a notice.
511
+ - **In job code, prevention beats containment for a warning.** Guard optional data with
512
+ `isset()` before reading it — you cannot wrap your way out of a notice. This is about the
513
+ uncatchable-warning mechanics above; it is **not** license to ack-and-continue past a genuine
514
+ (catchable) exception in a reconciliation loop. See *Fail-loud is the default for
515
+ import/sync/cron code* below before reaching for a `finally`/`catch (Throwable)` ack — that
516
+ pattern caused a real data-loss incident in this exact engine.
513
517
 
514
518
  > **Existing guidance under review.** An earlier version of this section recommended
515
519
  > wrapping fragile I/O in `try { ... } catch (\ErrorException $e)` relying on the GLOBAL
@@ -521,6 +525,59 @@ Additional verified detail:
521
525
  > (~L112-123), `clients/prudential/profile.md` (~L75). Prefer the local-handler pattern
522
526
  > from the canonical section above for anything new.
523
527
 
528
+ ### Fail-loud is the default for import/sync/cron code — never catch-and-continue or log-and-skip a record
529
+
530
+ **This is the standing policy for reconciliation jobs; it supersedes the "consume/ack in a
531
+ `finally`" framing in the section above wherever the two would conflict.** For import/sync/cron
532
+ code that reconciles data from an external system into ours — the NetSuite → TOGa Supply sync
533
+ (`worker/crons/toga2/netsuite/`) is the canonical example — the rule is: **if anything prevents
534
+ the job from producing accurate data, let it throw.** The exception must propagate and abort the
535
+ run. Do not:
536
+
537
+ - Wrap a per-record dispatch in `try { … } catch (Throwable) { error_log(...) }` and move on to
538
+ the next record.
539
+ - Wrap a section/job in `try { … } finally { <advance the checkpoint> }` so the checkpoint still
540
+ moves even when the try body threw.
541
+ - Downgrade a hard failure to a log line and keep going "because most records succeeded."
542
+
543
+ **Why.** These jobs track progress with an execution-mode flag plus a watermark/cursor (e.g.
544
+ `NETSUITE_EXECUTION_MODE_*` / `NETSUITE_LAST_SYNC_DATETIME_*`). A thrown, unhandled exception
545
+ leaves that state at **RUNNING** with the watermark **not advanced** past the failure — visible
546
+ proof the run failed, the record still owes a retry, and a developer needs to look. Catching the
547
+ exception and continuing does the opposite: it drops the record, silently advances the checkpoint
548
+ past it (the loss becomes **permanent**, not retried), and can even reset the mode back to
549
+ **IDLE**, telling the next run "everything's fine" when it isn't. **Data accuracy is prioritized
550
+ over availability here — even for a failure that is not auto-retriable** (an ACL/permission
551
+ error, a malformed upstream record, a constraint violation). A run stuck at RUNNING that needs a
552
+ developer to reconcile it is the correct, intended outcome; a clean-looking IDLE run that quietly
553
+ dropped data is not.
554
+
555
+ **The one legitimate exception is a true message/inbox queue** — a loop reading items one at a
556
+ time from something like an IMAP inbox or an SQS queue, where an item that is never acknowledged
557
+ blocks every item behind it forever. There, and only there, consuming/acking the poison item so
558
+ the queue can move past it is defensible — and even then, **prefer surfacing** the failure
559
+ (dead-letter it, alert on it, record it against the item) over silently discarding it. A
560
+ reconciliation cron with its own per-client cursor is **not** this case: nothing blocks behind a
561
+ RUNNING watermark except that one client's own next run, which is exactly what the window
562
+ grow/shrink behavior is designed around.
563
+
564
+ **Real incident.** On 2026-08-20 a change wrapped every per-order dispatch across all six
565
+ NetSuite → TOGa Supply sections in `catch (Throwable) { error_log }` and wrapped each section in
566
+ `try { … } finally { finishModeIteration }`. It looked like an improvement — "don't let one bad
567
+ order jam the sync" — but it silently dropped any record whose write failed, advanced the
568
+ watermark past it, and reset the mode to IDLE, so a failed run looked identical to a successful
569
+ one. This was found and reverted 2026-08-27 (all per-order catches and section-level
570
+ `try/finally` removed — a failure now aborts the section with the mode left RUNNING), and a
571
+ related error-log-and-swallow path in the same engine's inventory-adjustment section was removed
572
+ again 2026-08-29 during its SOAP→REST migration. Full detail: [NetSuite → TOGa Supply Per-Client
573
+ Sync](../apps/worker/features/netsuite-togasupply-per-client-sync.md).
574
+
575
+ This does not relax the "any PHP warning terminates the request" mechanics above, or the two
576
+ sanctioned local opt-outs for a **notice/warning** you must genuinely contain (a monitoring ping,
577
+ a defensively-guarded optional read). Those exist to survive an *uncatchable warning* without
578
+ crashing something that must not crash. This rule is about a **catchable exception** in a
579
+ reconciliation loop, where surviving it quietly is exactly the wrong behavior.
580
+
524
581
  ### Test mode silently disables queued email — non-prod cannot validate a queue bug
525
582
 
526
583
  `App_Email::setQueueForSending()` (`library/app/email.php` ~L161) is gated on
@@ -5,12 +5,13 @@ project: Library
5
5
  client: shared
6
6
  type: standard
7
7
  status: active
8
- updated: 2026-08-06
8
+ updated: 2026-08-29
9
9
  owners: [jcardinal, ajean]
10
10
  files: []
11
11
  related:
12
12
  - ../apps/library/architecture.md
13
13
  - ../apps/worker/architecture.md
14
+ - backend-php.md
14
15
  ---
15
16
 
16
17
  # Framework 1.0 (App_) Rules
@@ -150,3 +151,12 @@ public function processOrder(): void {
150
151
  $this->response->success($result);
151
152
  }
152
153
  ```
154
+
155
+ **This pattern is scoped to a single request/response unit of work — it does not extend to
156
+ import/sync/cron code.** Above, catching stops the *whole* action and returns one error response;
157
+ nothing after the catch runs "successfully" on partial data. A batch/reconciliation job (a cron
158
+ looping over many external records, advancing a cursor/watermark) is a different shape: catching
159
+ per-record there and continuing to the next one is exactly the anti-pattern that caused a
160
+ data-loss incident in the NetSuite → TOGa Supply sync. For that class of code, see
161
+ `1.0/standards/backend-php.md` § *Fail-loud is the default for import/sync/cron code* — the job
162
+ must throw and abort, not catch-and-continue.
@@ -5,13 +5,15 @@ project: _Underscore
5
5
  client: shared
6
6
  type: standard
7
7
  status: active
8
- updated: 2026-08-25
8
+ updated: 2026-08-29
9
9
  owners: [jcardinal, mhammontree, dfranks, bala]
10
10
  files: []
11
11
  related:
12
12
  - ../apps/_underscore/architecture.md
13
13
  - ../apps/api2/architecture.md
14
14
  - ../apps/worker2/architecture.md
15
+ - framework-rules.md
16
+ - ../../1.0/standards/backend-php.md
15
17
  ---
16
18
 
17
19
  ## General Principals
@@ -677,6 +679,14 @@ $c = 'Hello ' . $world;
677
679
  ### PHP Error Handling
678
680
 
679
681
  * Always use exceptions to handle unexpected conditions.
682
+ * **Import/sync/cron code that reconciles external data must fail loud — never catch-and-continue
683
+ or log-and-skip a record.** A mid-loop failure must throw and abort the job, leaving its
684
+ checkpoint/watermark unmoved for retry/investigation, rather than being caught, logged, and
685
+ stepped over. See `2.0/standards/framework-rules.md` § *The above is for a per-entity job — a
686
+ reconciliation/import worker that loops over many records is different, and must fail loud* and
687
+ `1.0/standards/backend-php.md` § *Fail-loud is the default for import/sync/cron code* (the
688
+ policy this corrects, after a per-order catch-and-continue change caused a data-loss incident in
689
+ the NetSuite → TOGa Supply sync).
680
690
 
681
691
  ### Choosing an exception class is a ROUTING decision, not style
682
692
 
@@ -946,6 +956,10 @@ See: 2.0/apps/worker2/features/cross-account-aws-access.md
946
956
 
947
957
  ## Change history
948
958
 
959
+ - 2026-08-29 — Added a fail-loud cross-reference under **PHP Error Handling**: import/sync/cron
960
+ code that reconciles external data must never catch-and-continue or log-and-skip a record;
961
+ points to the full policy and the NetSuite → TOGa Supply sync data-loss incident recorded in
962
+ `framework-rules.md` and `1.0/standards/backend-php.md`. (jcardinal)
949
963
  - 2026-08-25 — Clarified the exception-routing rule: `_Exception_Validation` is a valid 400 throw
950
964
  site from a **scripted-API method** too, not only a pre/post interceptor or model op. Verified at
951
965
  the outer `execute()`/`api()` catch in `api2/Controller/Index.php` (~L317) where
@@ -5,7 +5,7 @@ project: _Underscore
5
5
  client: shared
6
6
  type: standard
7
7
  status: active
8
- updated: 2026-08-28
8
+ updated: 2026-08-29
9
9
  owners: [jcardinal, ajean, apeterson]
10
10
  files: []
11
11
  related:
@@ -14,6 +14,8 @@ related:
14
14
  - ../apps/api2/architecture.md
15
15
  - ../apps/dbchanges2/architecture.md
16
16
  - ../apps/dbchanges2/features/surface-layer-schema.md
17
+ - backend-php.md
18
+ - ../../1.0/standards/backend-php.md
17
19
  ---
18
20
 
19
21
  # Framework 2.0 (_underscore) Rules
@@ -298,6 +300,23 @@ returns nothing (or returns only when it succeeds) leaves a blind spot in the au
298
300
  only for genuinely retriable conditions, where the queue's retry is the intended behaviour; a
299
301
  handled non-retriable failure should return a result describing what happened rather than throwing.
300
302
 
303
+ ### The above is for a per-entity job — a reconciliation/import worker that loops over many records is different, and must fail loud
304
+
305
+ `ProcessOrder(int $orderId)` above is scoped to **one** record: the job either succeeds or fails
306
+ as a whole, and "log and return a failure result" for a non-retriable error means *this job*
307
+ (this one order) is done — no other record is silently dropped alongside it. Do not generalize
308
+ that shape to a worker action that **internally loops over many records to reconcile external
309
+ data** (a NetSuite import, a bulk sync, anything advancing its own cursor/watermark across a
310
+ batch). For that shape, catching a per-record failure inside the loop and moving on to the next
311
+ record is the same anti-pattern documented in `1.0/standards/backend-php.md` § *Fail-loud is the
312
+ default for import/sync/cron code* — it silently drops the record and can leave the job's own
313
+ progress-tracking (checkpoint/cursor) looking healthy when it isn't. A batch/reconciliation worker
314
+ must let a mid-loop failure **throw and abort the job**, leaving its checkpoint unmoved so the
315
+ queue's retry (or a developer) picks up where it actually left off — never catch-per-record and
316
+ continue. Data accuracy outranks job "completion," even when the failure is not retriable (e.g. an
317
+ ACL error on one record) — a developer reconciling a stalled job is the intended outcome, not a
318
+ job that reports success having quietly skipped records.
319
+
301
320
  ## `c_`-prefixed custom columns are framework-dynamic
302
321
 
303
322
  Columns prefixed `c_` are **custom/dynamic** columns that the `_underscore` model layer handles
@@ -317,6 +336,14 @@ and not how the convention works. Use a non-`c_` column when you *do* want the f
317
336
  ACL-governed field treatment.
318
337
 
319
338
  ## Change history
339
+ - 2026-08-29 — Added a distinction under **Error handling in workers**: the documented
340
+ `ProcessOrder`-style per-entity pattern (catch non-retriable, log, return a failure result) does
341
+ **not** extend to a worker action that loops over many records to reconcile external data (a
342
+ NetSuite import, a bulk sync). That shape must fail loud — a mid-loop failure throws and aborts
343
+ the job so its checkpoint/cursor stays unmoved — matching the fail-loud policy corrected in
344
+ `1.0/standards/backend-php.md` after a per-order catch-and-continue change caused a silent
345
+ data-loss incident in the NetSuite → TOGa Supply sync (found 2026-08-20, reverted 2026-08-27,
346
+ final swallow removed 2026-08-29). (jcardinal)
320
347
  - 2026-08-28 — Extended § Schema migrations with the production-state rules. Recorded that cluster
321
348
  isolation is **physical** (verified: the prod Core reader exposes only Core/Forecast/
322
349
  Forecast_Archive/Team, the client reader only `Client_*`), so a cross-database reference cannot
@@ -46,9 +46,11 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
46
46
  ## Clients
47
47
 
48
48
  - **AIG (Staples Protection Plan)** (`aig`) → [clients/aig/INDEX.md](clients/aig/INDEX.md)
49
+ - **Canon** (`canon`) → [clients/canon/INDEX.md](clients/canon/INDEX.md)
49
50
  - **Compass Canada** (`compass-canada`) → [clients/compass-canada/INDEX.md](clients/compass-canada/INDEX.md)
50
51
  - **Compass USA** (`compass-usa`) → [clients/compass-usa/INDEX.md](clients/compass-usa/INDEX.md)
51
52
  - **Elite** (`elite`) → [clients/elite/INDEX.md](clients/elite/INDEX.md)
53
+ - **Endeavor Health** (`endeavor-health`) → [clients/endeavor-health/INDEX.md](clients/endeavor-health/INDEX.md)
52
54
  - **Fordham University** (`fordham`) → [clients/fordham/INDEX.md](clients/fordham/INDEX.md)
53
55
  - **GroWrk** (`growrk`) → [clients/growrk/INDEX.md](clients/growrk/INDEX.md)
54
56
  - **Northwell Health** (`northwell`) → [clients/northwell/INDEX.md](clients/northwell/INDEX.md)
@@ -60,6 +62,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
60
62
  - **Quad Graphics** (`quad`) → [clients/quad/INDEX.md](clients/quad/INDEX.md)
61
63
  - **Rate** (`rate`) → [clients/rate/INDEX.md](clients/rate/INDEX.md)
62
64
  - **Richmond University Medical Center** (`rumcsi`) → [clients/rumcsi/INDEX.md](clients/rumcsi/INDEX.md)
65
+ - **S&P Global** (`spglobal`) → [clients/spglobal/INDEX.md](clients/spglobal/INDEX.md)
63
66
  - **Staples** (`staples`) → [clients/staples/INDEX.md](clients/staples/INDEX.md)
64
67
  - **Tow Foundation** (`tow-foundation`) → [clients/tow-foundation/INDEX.md](clients/tow-foundation/INDEX.md)
65
68
  - **TOGA Technology** (`true`) → [clients/true/INDEX.md](clients/true/INDEX.md)
@@ -6,13 +6,14 @@ apps:
6
6
  - api2
7
7
  - dbchanges2
8
8
  - library
9
+ - worker
9
10
  - worker2
10
11
  project: API
11
12
  client: aig
12
13
  type: profile
13
14
  status: active
14
- updated: 2026-08-17
15
- owners: ["mhammontree"]
15
+ updated: 2026-08-29
16
+ owners: ["mhammontree", "jcardinal"]
16
17
  files: []
17
18
  related:
18
19
  - clients/aig/features/entitlement-intake.md
@@ -0,0 +1,5 @@
1
+ # Client: Canon `canon`
2
+
3
+ | Doc | Framework | Summary | Files |
4
+ |-----|-----------|---------|-------|
5
+ | [Canon](profile.md) | 2.0 | Canon is a **TOGa-Supply NetSuite integration client** on the shared 1.0 NetSuite → TOGa Supply per-client sync (`worker` + `library`). | |
@@ -0,0 +1,34 @@
1
+ ---
2
+ title: "Canon"
3
+ framework: "2.0"
4
+ apps:
5
+ - library
6
+ - worker
7
+ project: Worker
8
+ client: canon
9
+ type: profile
10
+ status: active
11
+ updated: 2026-08-29
12
+ owners: ["jcardinal"]
13
+ files: []
14
+ related:
15
+ - ../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
16
+ ---
17
+
18
+ ## Summary
19
+
20
+ Canon is a **TOGa-Supply NetSuite integration client** on the shared 1.0 NetSuite → TOGa Supply
21
+ per-client sync (`worker` + `library`). Its thin wrapper
22
+ `worker/crons/toga2/netsuite/sync_togasupply_canon.php` is the **canonical example** referenced by
23
+ the shared-engine doc — copy it when onboarding a new client. NetSuite transactions (sales orders,
24
+ POs, invoices, item receipts, item fulfillments, inventory adjustments) sync into Canon's 2.0
25
+ `Client_Canon` tenant through the TOGa2 API.
26
+
27
+ This profile was seeded during the 2026-08-29 root-cause work that fixed Canon's stuck
28
+ `ITEM_RECEIPTS` section — the item-receipt path was migrated SOAP → REST (`fetchItemReceiptById`);
29
+ full mechanics and the diagnosis playbook live in
30
+ [NetSuite → TOGa Supply per-client sync](../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
31
+
32
+ ## Integration touchpoints
33
+
34
+ - **`worker` / `library` (1.0)** — the shared togasupply sync engine + `App_Api_Toga2` bridge.
@@ -0,0 +1,5 @@
1
+ # Client: Endeavor Health `endeavor-health`
2
+
3
+ | Doc | Framework | Summary | Files |
4
+ |-----|-----------|---------|-------|
5
+ | [Endeavor Health](profile.md) | 2.0 | Endeavor Health is a **TOGa-Supply NetSuite integration client** on the shared 1.0 NetSuite → TOGa Supply per-client sync (`worker` + `library`). | |
@@ -0,0 +1,32 @@
1
+ ---
2
+ title: "Endeavor Health"
3
+ framework: "2.0"
4
+ apps:
5
+ - library
6
+ - worker
7
+ project: Worker
8
+ client: endeavor-health
9
+ type: profile
10
+ status: active
11
+ updated: 2026-08-29
12
+ owners: ["jcardinal"]
13
+ files: []
14
+ related:
15
+ - ../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
16
+ ---
17
+
18
+ ## Summary
19
+
20
+ Endeavor Health is a **TOGa-Supply NetSuite integration client** on the shared 1.0 NetSuite → TOGa
21
+ Supply per-client sync (`worker` + `library`). NetSuite transactions sync into Endeavor's 2.0
22
+ `Client_<Id>` tenant through the TOGa2 API via a thin
23
+ `worker/crons/toga2/netsuite/sync_togasupply_*.php` wrapper.
24
+
25
+ This profile was seeded during the 2026-08-29 root-cause work that fixed Endeavor's stuck
26
+ `ITEM_RECEIPTS` section — the item-receipt path was migrated SOAP → REST (`fetchItemReceiptById`);
27
+ full mechanics and the diagnosis playbook live in
28
+ [NetSuite → TOGa Supply per-client sync](../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
29
+
30
+ ## Integration touchpoints
31
+
32
+ - **`worker` / `library` (1.0)** — the shared togasupply sync engine + `App_Api_Toga2` bridge.
@@ -0,0 +1,5 @@
1
+ # Client: S&P Global `spglobal`
2
+
3
+ | Doc | Framework | Summary | Files |
4
+ |-----|-----------|---------|-------|
5
+ | [S&P Global](profile.md) | 2.0 | S&P Global is a **TOGa-Supply NetSuite integration client** on the shared 1.0 NetSuite → TOGa Supply per-client sync (`worker` + `library`). | |
@@ -0,0 +1,32 @@
1
+ ---
2
+ title: "S&P Global"
3
+ framework: "2.0"
4
+ apps:
5
+ - library
6
+ - worker
7
+ project: Worker
8
+ client: spglobal
9
+ type: profile
10
+ status: active
11
+ updated: 2026-08-29
12
+ owners: ["jcardinal"]
13
+ files: []
14
+ related:
15
+ - ../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md
16
+ ---
17
+
18
+ ## Summary
19
+
20
+ S&P Global is a **TOGa-Supply NetSuite integration client** on the shared 1.0 NetSuite → TOGa Supply
21
+ per-client sync (`worker` + `library`). NetSuite transactions sync into its 2.0 `Client_<Id>` tenant
22
+ through the TOGa2 API via a thin `worker/crons/toga2/netsuite/sync_togasupply_*.php` wrapper.
23
+
24
+ This profile was seeded during the 2026-08-29 root-cause work on the stuck togasupply integrations:
25
+ S&P Global was one of the clients exposed to the item-fulfillment "Undefined index" on an empty
26
+ `orderLine` (`syncItemFulfillmentFromNetsuite`), fixed in shared code. Full mechanics and the
27
+ diagnosis playbook live in
28
+ [NetSuite → TOGa Supply per-client sync](../../1.0/apps/worker/features/netsuite-togasupply-per-client-sync.md).
29
+
30
+ ## Integration touchpoints
31
+
32
+ - **`worker` / `library` (1.0)** — the shared togasupply sync engine + `App_Api_Toga2` bridge.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "toga-ai",
3
- "version": "1.0.698",
3
+ "version": "1.0.699",
4
4
  "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
5
5
  "keywords": [
6
6
  "claude",