feat(privacy-types): add RequestIdAlreadyExists DsrErrorCode

[mason-hale]

Important

Small, high-priority review: additive type-only change (no behavior changes) that blocks WAL-10697 on main, mirroring #417.

Summary

• Add DsrErrorCode.RequestIdAlreadyExists (REQUEST_ID_ALREADY_EXISTS) with a DSR_ERROR_MESSAGE builder.
• Emitted when a bulk DSR submission (via GraphQL) reuses an existing requestId without isRestart: true.
• Unblocks main#47604 so it can drop the local DsrErrorCode re-export after Version Packages publishes and the yarn catalog is bumped.

Test plan

• pnpm run --dir packages/privacy-types test
• pnpm run --dir packages/privacy-types typecheck
• Release via changeset Version Packages PR after merge

  

[linear-code]

WAL-10697

[pkg-pr-new]

Open in StackBlitz

@transcend-io/airgap.js-types

pnpm add https://pkg.pr.new/@transcend-io/airgap.js-types@445

yarn add https://pkg.pr.new/@transcend-io/airgap.js-types@445.tgz

@transcend-io/cli

pnpm add https://pkg.pr.new/@transcend-io/cli@445

yarn add https://pkg.pr.new/@transcend-io/cli@445.tgz

@transcend-io/design-tokens

pnpm add https://pkg.pr.new/@transcend-io/design-tokens@445

yarn add https://pkg.pr.new/@transcend-io/design-tokens@445.tgz

@transcend-io/internationalization

pnpm add https://pkg.pr.new/@transcend-io/internationalization@445

yarn add https://pkg.pr.new/@transcend-io/internationalization@445.tgz

@transcend-io/privacy-types

pnpm add https://pkg.pr.new/@transcend-io/privacy-types@445

yarn add https://pkg.pr.new/@transcend-io/privacy-types@445.tgz

@transcend-io/sdk

pnpm add https://pkg.pr.new/@transcend-io/sdk@445

yarn add https://pkg.pr.new/@transcend-io/sdk@445.tgz

@transcend-io/type-utils

pnpm add https://pkg.pr.new/@transcend-io/type-utils@445

yarn add https://pkg.pr.new/@transcend-io/type-utils@445.tgz

@transcend-io/utils

pnpm add https://pkg.pr.new/@transcend-io/utils@445

yarn add https://pkg.pr.new/@transcend-io/utils@445.tgz

@transcend-io/mcp

pnpm add https://pkg.pr.new/@transcend-io/mcp@445

yarn add https://pkg.pr.new/@transcend-io/mcp@445.tgz

@transcend-io/mcp-server-admin

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-admin@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-admin@445.tgz

@transcend-io/mcp-server-assessment

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-assessment@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-assessment@445.tgz

@transcend-io/mcp-server-base

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-base@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-base@445.tgz

@transcend-io/mcp-server-consent

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-consent@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-consent@445.tgz

@transcend-io/mcp-server-discovery

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-discovery@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-discovery@445.tgz

@transcend-io/mcp-server-docs

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-docs@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-docs@445.tgz

@transcend-io/mcp-server-dsr

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-dsr@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-dsr@445.tgz

@transcend-io/mcp-server-inventory

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-inventory@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-inventory@445.tgz

@transcend-io/mcp-server-preferences

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-preferences@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-preferences@445.tgz

@transcend-io/mcp-server-workflows

pnpm add https://pkg.pr.new/@transcend-io/mcp-server-workflows@445

yarn add https://pkg.pr.new/@transcend-io/mcp-server-workflows@445.tgz

commit: bd09838

[michaelfarrell76]

cant we just assume passing a requestId means isRestart=true?

[mason-hale]

@michaelfarrell76 we do that for the bulk REST endpoint, attaching the flag on the sombra ingress when requestId is provided by a customer. but this isn’t possible for graphQL (which already passes isRestart=true; the whole convention of this flag was introduced to distinguish between a restart and between Sombra creating a new request as it passes requestId with the encryptedCEKContext). this is addressing an outstanding small bug where if graphQL passes an existing requestId without isRestart=true, it will upsert and overwrite the request, which we don’t want to happen. see ticket for more details, but yeah

[mason-hale]

this is really just capturing a narrow internal/graphQL case brought up by annalisa here: https://github.com/transcend-io/main/pull/47483#pullrequestreview-4952929677

if you’re wondering why isRestart is necessary at all, it has to do with the CEK context stuff introduced by annalisa back in april; i went on a bit of a deep dive.

[iamtheluckyest]

@michaelfarrell76 we do that for the bulk REST endpoint, attaching the flag on the sombra ingress when requestId is provided by a customer. but this isn’t possible for graphQL (which already passes isRestart=true; the whole convention of this flag was introduced to distinguish between a restart and between Sombra creating a new request as it passes requestId with the encryptedCEKContext). this is addressing an outstanding small bug where if graphQL passes an existing requestId without isRestart=true, it will upsert and overwrite the request, which we don’t want to happen. see ticket for more details, but yeah

Mason is correct about us needing to pass requestId for all requests on the Sombra ingress endpoint due to the way we generate the encryptedCekContext. We do have some logic (that was only partially implemented and Mason fixed up) where on the backend we were looking up requests by id and if they already existed, we would treat them as a restart. But it meant that we couldn't distinguish between the following:

• intended to restart a request, but passed a bad id
• intended to create a new request

So isRestart was added to distinguish intent and throw more helpful errors. I can still see this as not truly being necessary, but that's the reasoning we went with.

[michaelfarrell76]

ok @mason-hale @iamtheluckyest i am fine to document this, but if the intention for the REST API is to not expose isRestart and requestId always means isRestart=true, and this is just an implementation detail of the transcend <> sombra api, then i'd probably just throw a normal error in that situation rather than using the code. the codes are going to be primarily for different situations that the customer should handle in their code.

[mason-hale]

@michaelfarrell76 i'm gonna close this for now given the error doesn't arise from the public API - i'll just throw a normal error in the other PR. lmk if you'd rather this come in and i can re-open