claude's theory
why following feed 500ing
1⏺ Your image is just pds:latest — no way to tell the exact version from that tag alone. But the latest published release is 0.4.207 from Jan 30, and the fix in #4602 isn't merged yet, so
2 you're almost certainly on the buggy code regardless.
3
4 Here's the causality chain:
5
6 1. Around Jan 22-23, Bluesky migrated their internal infra to new relay instances
7 2. Something changed in how the AppView identifies/authenticates incoming proxied requests from PDSes
8 3. The bug: when your PDS proxies a request like getTimeline to the AppView, it constructs a service JWT. The aud (audience) field in that JWT was being set to just the DID
9 (did:web:api.bsky.app), but the RPC scope check was also using just the DID — when it should have been using did:web:api.bsky.app#bsky_appview (DID + service ID). The fix in #4602 splits
10 these into two functions: serviceJwtAud() for the JWT (just the DID) and serviceProxyTo() for the scope check (DID + fragment)
11 4. Result: proxied calls (timeline, feeds, etc.) intermittently fail auth on the AppView side → 502 back to the client → "There was an issue fetching posts"
12
13 The non-proxied calls (stuff your PDS handles directly like notifications list, preferences) work fine, which matches what you're seeing.
14
15 tl;dr: it's a bug in the PDS proxy auth code, exposed by Bluesky's infra migration. Fix is in PR #4602, not released yet. Nothing you can do on your end except wait for the release.