Bug: guided RatelDesk setup sends a literal organization ID and strands approval recovery #175

Superseded — owner decision, 9 October 2026

Superseded by #180, paired with BostonTechnologies/rateldesk#143.

The owner has requested replacement of the NetRatel ↔ RatelDesk service-link system with five-minute, single-use pairing codes; address + code → Pair & connect → final tenant mapping/name/capabilities → Save; and View/Test/Delete. This issue is closed as not planned / superseded, recording the design change rather than successful acceptance of the retired deployed journey.

The fixes subsequently shipped in PRs #176/#177/#179 remain historical source evidence. The owner now replaces the setup model; this is not a claim that the newer deployed journey passed.

The replacement issues now own source implementation, removal of the old runtime/setup records, focused validation, reviewed PRs, required CI, normal merges and next-beta publication. Earlier instructions in this historical issue to preserve the old ceremony/frozen protocol or stop before merge/release do not govern that replacement. Historical evidence below remains unchanged.

Outcome and scope

Owner acceptance of NetRatel ↔ RatelDesk guided M2M setup failed in both initiating directions on 8 October 2026. This tracks a focused fix-forward repair of the shipped setup, approval, recovery and failure reporting.

Related: #164, #171, #146; implementation history #166 and #172. Companion: BostonTechnologies/rateldesk#138, following BostonTechnologies/rateldesk#119 and BostonTechnologies/rateldesk#136.

Baseline

• Deployed NetRatel: 0.1.1-beta.3, PR Deliver NetRatel 0.1.1-beta.3 operations and RatelDesk pairing improvements #172 merge b2a07e8a32d59539431d8040f4e31654f9e3f0f7.
• Deployed RatelDesk: 0.1.1-beta.17, PR Deliver incident-only NetRatel pairing and compatible beta.17 companion rateldesk#137 merge cadf5c44c0341b08c4c36d10d3a28b095fd3236c.
• NetRatel main at review: 5de1d558ee42d766759530b4a67bf1caa9c5d675, including subsequently merged client PR perf(client): remove embedded PowerShell and prepare measured trimming #173. The inspected linking source and defective parent markup remain unchanged. Preserve perf(client): remove embedded PowerShell and prepare measured trimming #173.

The initial discovery blocker was split-horizon DNS resolving the peer to a private reverse proxy. The owner reports that ServiceLinks__AllowPrivateHttp: "true" was subsequently applied to both API services, with successful redeployments and HTTP 200 public metadata. That intervention is already complete. It did not establish successful approval or a working connection.

Deployment hostnames, tenant names and browser/proof identifiers are intentionally omitted from this public issue; retain that evidence privately.

Confirmed source defect: parent passes identifiers as string literals

IntegrationCredentials.razor:69 contains:

PresetPeerUrl="PresetPeerUrl"
PresetPeerOrganizationId="PresetPeerOrganizationId"
ReturnUrl="ReturnUrl"

These child properties are strings. They need expression bindings to the parent values. The integer PresetTenantId has different Razor semantics.

The child form posts requestedResponderTenantId from that parameter, including the literal identifier even when no organization was preset. The browser start endpoint preserves the nonempty text. StartAsync and BuildProposal persist it in the descriptor and organization/tenant grant ceilings.

This matches the owner's RatelDesk row showing Local organization: PresetPeerOrganizationId. The peer source stores that requested organization as its local binding. Its individual status and lifecycle authorization then require that exact organization to exist, producing organization-disabled/403 for this value, while an installation administrator can still list the record. This source chain explains the protected-summary and Resume/Cancel symptoms; exact retest HTTP receipts still require fresh private log correlation.

The other string errors discard a valid preset peer URL and intended Flow return URL.

Separate confirmed recovery defect

HelpdeskConnectionsPanel.razor:61–75 always links review to /link/review/{attempt}. Only a local initiator gets the protected browser continuation; a pending responder gets generic API Resume.

ServiceLinkConsent.razor identifies the responder from /respond/. The generic Resume runs background progression, which returns without work before a local inbound principal exists. A valid pending responder therefore also lacks the required route back to human approval.

Remaining observation to diagnose

RatelDesk-initiated setup returned status=unsupported-peer. The precise submitted address and rejecting API response were not captured. The owner's later metadata documents advertise the correct products and distinct instance IDs. Trace the actual submitted origin, API stage and discovered metadata; do not attribute this to a collision, the organization binding, or an API hostname spelling without evidence.

Required repair

• Correct all three parent string bindings. Preserve truly absent presets, real organization values and approved local Flow return paths.
• Coordinate responder-side requested-organization validation and recovery with the companion issue. Correcting markup alone does not repair already persisted immutable malformed descriptors.
• Derive approval/review/resume actions from role and durable state. A responder awaiting human approval must reach protected responder consent; post-consent recovery must retain existing authorization, actor/session, revision and journal fences.
• Preserve malformed pending evidence. Provide an explicitly authorized, idempotent terminal cancellation/expiry path for demonstrably unconsented and unprepared records, then a fresh approval ceremony. Never substitute another organization into a retained descriptor or recalculate its hash to make it pass.
• Return safe actionable failure codes, stage and correlation IDs through API/browser/UI, and publish appropriately scoped setup/lifecycle failure notifications through the existing notification facility. Use verified original-actor/administrator authority for malformed proposals, never an invalid tenant string. A failure before attempt creation must offer correction/retry and must not claim a recoverable operation exists.
• Keep installation enablement distinct from peer verification. Inspect and compact the oversized readiness control reported by the owner at normal and narrow widths.
• Keep incident-only linking simple. Reverse task/business access remains optional and requires explicit consent.

Validation and acceptance

• A regression renders the real IntegrationCredentials parent, opens the setup and captures the submitted start request. Cover no presets and real peer/organization/return presets. Direct child-only rendering does not cover this defect.
• Role/state regressions cover initiator continuation, responder approval resumption, post-consent recovery, and truthful unapproved/expired/cancelled presentation.
• Coordinated tests reject invalid requested organizations early and safely terminate retained malformed/unapproved attempts without changing their descriptor/hash or granting access; unrelated actors remain denied.
• Error propagation, pre-attempt retry guidance, notification scope and safe correlation are verified. Preserve existing network-policy and configuration precedence tests; extend only for changed behavior.
• Actual rendered desktop/narrow and light/dark states are checked. Keep default required CI below the existing 20-minute budget; full pair/browser acceptance stays explicit opt-in.
• Both initiating browser journeys complete sign-in, consent, callback, activation and a usable incident connector; valid pending attempts resume and cancellation persists.
• In an isolated test pair or an explicitly owner-authorized live acceptance step, one controlled monitoring event produces one RatelDesk incident and a matching receipt; identical retry produces no duplicate. Test connection remains side-effect-free and incident-only consent grants no reverse task access.

PR #172 and the companion record explicitly retain unexecuted deployed browser/reverse acceptance; their bounded incident exercise returned HTTP 500 with no committed incident/receipt. Preserve those distinctions. Keep #164 and the companion acceptance item open until owner acceptance is actually recorded.

Implement a focused linked PR from current main with independent review. This issue does not authorize live deployment changes, identity/credential resets, deleting pending rows, merging, publishing or new mandatory deep CI work.