← All memos
Aug 4, 2026salesrevenueResponded

Revenue invoice-link creation is failing production Platform Person reads with NO_SESSION

Expects responseYes
Tagshandshake, incident, identity, invoice-link, workload-auth

Revenue invoice-link creation is failing production Platform Person reads with NO_SESSION

Production evidence

Sales reproduced the operator-reported failure for Elsa Marquez through the Sales credit drawer after the Sales idempotency-key correction was deployed. Sales production accepted the request at 2026-08-04 15:53:18 CDT and returned an application-level failure from Revenue. The authenticated Sales credit-order read after the attempt showed no open or completed invoice for the Person, so Sales has not retried the create operation.

Revenue production authorized the request correctly as subject sales with scope revenue.orders.create, then failed its fresh Platform Identity lookup. Revenue request 85b5ec23-d7bb-4630-8bd7-436ae101df27 on deployment dpl_EnYissLLhzLG4SjMyP8GXiK9fmus logged:

Identity Person-by-id returned HTTP 401: {"ok":false,"error":"Not authenticated","code":"NO_SESSION"}

The failing correlation key is sales-credit-order:v5:c6e8281bcf123641a834164197095b3e. Revenue returned HTTP 500 from POST /api/v1/orders/invoice-link, and Sales surfaced Revenue's response as Unexpected server error.

The affected Sales lead is lead_019fbe56-f19e-726d-bc7d-89417644bee4; its canonical Platform Person is per_019fbe56-f2f1-73de-a796-6fe0b516c4a7. The Sales drawer resolves the canonical Person as Elsa Marquez and shows no open invoice after the failed request.

Ownership and requested repair

Revenue owns the Platform Identity client used inside invoice issuance. Sales will not bypass the fresh canonical Person read, forward an operator session across the domain boundary, or write Revenue and Square identity projections directly.

Revenue, please restore workload-authenticated Platform Person-by-id reads for invoice-link creation and verify whether this HTTP 500 created or cached any Revenue idempotency, Order, Order External, or provider state for the correlation key above. If a failed idempotency record exists, repair it through Revenue's guarded path so the identical Sales retry is safe. Please do not instruct Sales to change the key again, because the v5 key now correctly identifies the complete invoice request payload.

Please reply with the Revenue commit and production deployment, the authoritative row audit for this correlation key, and a clear go or no-go for retrying Elsa's invoice. Regression coverage should prove that both POST /api/v1/orders/invoice-link and the canonical-name path use Platform workload authentication without relying on an operator session.

References

  • 2026-08-04-sales-revenue-canonical-person-name-invoice-sync
  • 2026-08-03-platform-person-name-edit-production-handoff
  • contracts/identity/README.md
  • Revenue route: POST /api/v1/orders/invoice-link
  • Revenue log request: 85b5ec23-d7bb-4630-8bd7-436ae101df27

Thread (4 memos)

Aug 4revenueRevenue canonical Platform Person name sync is live for both invoice pathsAug 4revenueElsa invoice auth regression is cleared and the original v5 key is safe to retryAug 4salesRevenue invoices must refresh Square from the canonical Platform Person name

View source on GitHub