Commit ad185ab
fix(identity): correct audiusSdk accessor in authMiddleware (.full.users -> .users) (#14482)
## Problem
Users report failing/janky signups, with `POST
https://identityservice.audius.co/users/update` misbehaving ([Slack
thread](https://audius-internal.slack.com/archives/CA80RCL77/p1781637102823139)).
`authMiddleware` (which gates `/users/update`, `/record_ip`, and every
other authenticated endpoint) backfills `blockchainUserId`/`handle` for
any identity `Users` row that lacks them — i.e. **every guest / freshly
signed-up user**. It did this via:
```js
req.app.get('audiusSdk').full.users.getUserAccount({ ... })
```
But the `@audius/sdk` instance **has no `.full` namespace** — `users` is
a top-level API (`audiusSdk.users.getUserAccount`). So `.full` is
`undefined` and `.users` throws a **synchronous `TypeError`** on every
new-user auth request.
Confirmed in prod logs:
```
TypeError: Cannot read properties of undefined (reading 'users')
at authMiddleware (build/src/authMiddleware.js:97:68)
msg: "Failed to update blockchainUserId/handle"
```
The surrounding `try/catch` swallowed it and called `next()`, so the
request proceeded but the **backfill silently never happened** — new
identity rows never got `blockchainUserId`/`handle` set.
## Why it started now
The bad accessor came in with the **monorepo import** of
identity-service (#14388, 5/22), which rewrote `authMiddleware` to use
`@audius/sdk`. It was dormant until #14474 (6/15) shipped
`loadAudiusSdk.cjs` into the build, so the SDK actually initialized and
this line began firing — matching the regression window. (identity
hadn't been deployed in a while; 6/15 was the first monorepo image
promoted to prod.)
I verified prod is in the *benign* config otherwise:
`environment=production` is set in `identity-service-secret`, so the SDK
targets prod discovery — the issue is purely the wrong accessor, not SDK
misconfig.
## Fix
Use the correct accessor `audiusSdk.users.getUserAccount` in both
`authMiddleware` and `parameterizedAuthMiddleware`. One-token change per
call site.
## Notes
- Ray's `record_ip` hunch is a red herring: `/users/update` doesn't call
`recordIP`. (Though `/record_ip` is also gated by `authMiddleware`, so
it hit the same TypeError — likely the source of the confusion.)
- Same 6/15 batch also fixed a related latent crash: #14378 reads
`src/data/disposable_email_blocklist.conf` at signup via an unguarded
`fs.readFileSync`; that file wasn't copied into the build until #14474
(same one-liner that also added `loadAudiusSdk.cjs`). Worth hardening
that read separately.
- The batch's endpoint removals (#14458, #14472) are safe — the legacy
`packages/libs` methods that hit them aren't called by any current
client.
## Verification
- Confirmed `getUserAccount` lives on the top-level `UsersApi`
(`audiusSdk.users`) and there is no `.full` in the SDK instance shape
(`@audius/sdk` `index.d.ts`).
- Confirmed response shape `res.data.user` is still correct
(`UserAccountResponse.data: Account`, `Account.user: User`).
- Confirmed prod `environment=production`.
After deploy, the `TypeError ... reading 'users'` log should disappear
and `Failed to update blockchainUserId/handle` should drop to near-zero.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>1 parent 2b2f3d5 commit ad185ab
1 file changed
Lines changed: 2 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
114 | 114 | | |
115 | 115 | | |
116 | 116 | | |
117 | | - | |
| 117 | + | |
118 | 118 | | |
119 | 119 | | |
120 | 120 | | |
| |||
181 | 181 | | |
182 | 182 | | |
183 | 183 | | |
184 | | - | |
| 184 | + | |
185 | 185 | | |
186 | 186 | | |
187 | 187 | | |
| |||
0 commit comments