Dead DID with empty CID crashes JavaScript validation

[mihailik]

Calling listRepos, crashing on first page of response

reported on BlueSky earlier

Calling com.atproto.sync.listRepos via JavaScript client crashes on the first page (and also on the last page #1949 ).

To Reproduce

Steps to reproduce the first behavior:

1. Call listRepos in a normal way, without cursor or pass "0" string as a cursor.
2. It blows: ValidationError: Output/repos/458/head must be a cid string

Sample code:

const atproto = require('@atproto/api');

async function tryListReposFirstPage() {
  const atClient = new atproto.BskyAgent({
    // service: 'https://bsky.social/xrpc'
    service: 'https://bsky.network/xrpc'
  });

  const reply = await atClient.com.atproto.sync.listRepos({ });
}

tryListReposFirstPage();

Exact failure:

XRPCInvalidResponseError: The server gave an invalid response and may be out of date.       
    at ServiceClient.call (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:15634:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async tryListReposFirstPage (C:\Users\mihai\oyin.bo\bluesky-static\accounts\scripts\crash1.js:9:17) {
  status: 2,
  error: 'Invalid Response',
  success: false,
  headers: undefined,
  lexiconNsid: 'com.atproto.sync.listRepos',
  validationError: ValidationError: Output/repos/458/head must be a cid string
      at cid (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14356:14)
      at string2 (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14552:16)
      at validate2 (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14673:14)
      at validateOneOf (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14811:78)
      at object (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14745:25)
      at validate2 (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14681:14)
      at validateOneOf (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14811:78)
      at array (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14720:17)
      at validate2 (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14683:14)
      at validateOneOf (C:\Users\mihai\oyin.bo\bluesky-static\accounts\node_modules\@atproto\api\dist\index.js:14811:78),

You can see above, it complains about 458th entry. Here it is, with CID indeed trimmed:

[458]: {
  "did": "did:plc:6fktaamhhxdqb2ypum33kbkj",
  "head": "b",
  "rev": ""
}

Expected behavior

Don't blow up, return the data to the caller.

The data type of that head field is string in the first place. This particular validation, in this particular position is peculiar and unnecessary.

Details

• Operating system: Windows
• Node version: 20
• \@atproto/api: "^0.7.2" (current now, and published a day ago)
• service: https://bsky.network/xrpc

Can also observe the dodgy data by opening this in browser, look at the bottom of the page:

https://bsky.network/xrpc/com.atproto.sync.listRepos?cursor=0

Additional context

And by the way, that one seems to be a runaway dead DID. Note that describeRepo returns "Could not find user: did:plc:6fktaamhhxdqb2ypum33kbkj":

{
  "error": "InvalidRequest",
  "message": "Could not find user: did:plc:6fktaamhhxdqb2ypum33kbkj"
}

https://bsky.social/xrpc/com.atproto.repo.describeRepo?repo=did%3Aplc%3A6fktaamhhxdqb2ypum33kbkj

[mihailik]

Came up with this "patch" to fix this bug:

// @ts-check

/** @param {import('@atproto/api').BskyAgent} atClient */
export function patchBskyAgent(atClient) {
  atClient.com.atproto.sync._service.xrpc.baseClient.lex.assertValidXrpcOutput = function (lexUri, value, ...rest) {
    return true;
  };
}

And it does indeed work. Now I'm even wondering if I should always run with that.

[bnewbold]

I think this is a relay bug (cc: @whyrusleeping). Certainly look like head is getting returned as the string version of cid.Undef (zero value of cid.Cid), which should probably never happen.

[mihailik]

And by the way, is http://bsky.network/xrpc the right endpoint these days?

Because the old one now only returns one DID, and the new one comes without CORS headers and impossible to invoke from browser 🥴

Kinda confusing halfway state, and \@atproto docs only explicitly point to Firehose for the bsky.network, other places still occasionally point to bsky.social.

[bnewbold]

bsky.social is a "PDS gateway", like a virtual server for multiple PDS instances. This is, for now, a pretty Bluesky (company) specific thing; you can connect directly to the individual PDS instances (morel, etc) for the real PDS semantics.

bsky.network is a Relay.

Some endpoints are implemented by both Relays and PDS instances, which is why some work on both domains.

We will take a peak at CORS on the relay!