-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Closed
Description
Description
The Bluesky channel adapter successfully authenticates (createSession returns 200), but subsequent notification polling via app.bsky.notification.listNotifications consistently returns 400 Bad Request.
Root Cause
The binary constructs the notification poll URL as:
/xrpc/app.bsky.notification.listNotifications?limit=25&seenAt=<value>
The seenAt value does not conform to the AT Protocol datetime specification (RFC-3339 / ISO-8601). The Bluesky API responds with:
{"error":"InvalidRequest","message":"Error: seenAt must be an valid atproto datetime (both RFC-3339 and ISO-8601)"}Reproduction
- Configure Bluesky channel with valid credentials in
config.toml - Start daemon
- Observe logs: authentication succeeds, then continuous 400 errors every ~5 seconds:
INFO openfang_channels::bluesky: Bluesky adapter authenticated as did:plc:...
INFO openfang_api::channel_bridge: bluesky channel bridge started
WARN openfang_channels::bluesky: Bluesky: notification fetch returned 400 Bad Request
WARN openfang_channels::bluesky: Bluesky: notification fetch returned 400 Bad Request
(repeats every ~5s)
Verification
Direct AT Protocol API calls confirm:
listNotifications?limit=25(without seenAt) → 200 OKlistNotifications?limit=25&seenAt=<invalid>→ 400 Bad Request
Workaround
Binary patch &seenAt= → &_seen_= (same byte length) + codesign --force --sign - to re-sign. The Bluesky API ignores unknown query parameters and returns 200.
Expected Behavior
The seenAt parameter should be formatted as a valid RFC-3339 datetime string (e.g. 2026-03-07T11:00:00.000Z).
Environment
- OpenFang: v0.3.26
- Platform: macOS (darwin arm64)
- Bluesky handle: confirmed working via direct API test
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels