Skip to main content
All Docs
FeaturesmyProp (AgentOS People Portal)Updated April 4, 2026

Incident: Account Discovery Regression in v0.1.70

Incident: Account Discovery Regression in v0.1.70

Status: Under investigation — fix pending
Severity: High — affects all user authentication flows
File: src/lib/letmc/accounts.ts

Summary

Version 0.1.70 introduced a regression in the account discovery mechanism. The single, correct API call used to identify a portal user's account has been replaced with five parallel calls that use an incorrect URL structure. As a result, account lookup fails for all user types — landlords, tenants, buyers, vendors, and contractors.

Background: How Account Discovery Works

When a user logs into the myProp portal, the system needs to resolve their email address to one or more accounts held within AgentOS. This is done via a discovery request to the AgentOS API before a session is established.

The correct discovery call is:

GET /{clientName}/accounts?emailAddress={email}&api_key={key}

This single endpoint returns all matching account records across all types in a single response, which the portal then uses to determine the user's role and available data.

What the Regression Introduced

The updated code in src/lib/letmc/accounts.ts replaced the single call with 5 parallel requests, each targeting a type-specific sub-path:

GET /v3/{shortName}/lettings/landlords?emailAddress={email}
GET /v3/{shortName}/lettings/tenants?emailAddress={email}
... (and 3 more)

This approach has two distinct problems:

1. Incorrect URL Structure

The URLs use /v3/{shortName}/lettings/... which does not match the AgentOS endpoint specification. The correct base path is /{clientName}/accounts. These requests will return errors or empty results regardless of the email address supplied.

2. Behavioural Change

Even if the URLs were corrected, splitting a unified query into 5 type-scoped queries is a breaking behavioural change from the original implementation. The original Lambda function (which this portal layer is designed to mirror) always used the single accounts endpoint.

Impact

  • All portal users attempting to log in via email lookup are affected.
  • Account resolution will fail silently or return no results, blocking portal access.
  • Outbound API call volume to AgentOS increases by 5× per login attempt, which may trigger rate limiting.

Recommended Fix

Replace the parallel query block in src/lib/letmc/accounts.ts with a single call to the correct endpoint:

// Correct implementation
const response = await fetch(
  `/${clientName}/accounts?emailAddress=${encodeURIComponent(email)}&api_key=${apiKey}`
);
const accounts = await response.json();

The response from this unified endpoint should be mapped to the existing account-type model used downstream in the authentication flow. No changes to the model or downstream consumers should be required.

Verification Checklist

Before closing this incident, confirm:

  • src/lib/letmc/accounts.ts issues exactly one outbound request per discovery attempt
  • The request URL matches /{clientName}/accounts?emailAddress={email}&api_key={key}
  • Landlord, tenant, buyer, vendor, and contractor accounts are all resolved correctly from the single response
  • No /v3/{shortName}/lettings/... paths remain in the accounts discovery logic
  • End-to-end login tested for at least one account of each type

Related