Two integration tests fail against Mastodon 4.6: scheduled-status idempotency (500) and filtered-notification requests

[milmazz]

While verifying #126 (PR #143), the integration suite was run against ghcr.io/mastodon/mastodon:v4.6.1 on a freshly provisioned stack. All OAuth tests pass there, but two pre-existing tests fail; both pass on the v4.4.8 image CI now pins. These need investigating before any CI bump toward the 4.6 parity target.

1. scheduling a status returns a scheduled status; idempotency key deduplicates

POST /api/v1/statuses with scheduled_at + an Idempotency-Key header returns 500 Internal Server Error on v4.6.1:

** (Hunter.Error) "{\"status\":500,\"error\":\"Internal Server Error\"}"
code: Hunter.create_status(conn, "idempotent probe #hunterci", idempotency_key: key)
test/integration/mastodon_test.exs:218

A server 500 suggests a Mastodon-side regression or a changed contract around scheduled statuses/idempotency — worth reproducing with curl against 4.6.x and checking upstream release notes/issues before deciding whether Hunter needs a change.

2. filtered notifications become requests that can be accepted

On v4.6.1 (fresh DB, no rate limiting in play) the NotificationRequest for the filtered mention never materializes:

** (RuntimeError) notification request not created yet
test/integration/mastodon_test.exs:316

Possibly a changed default in 4.6's notification-policy/filtering behavior (e.g. for_not_following semantics or request-creation conditions).

Related, but separate: the test is also non-idempotent locally

Independent of server version, this test leaves permanent state behind: accept_notification_request creates a NotificationPermission for kadaba, so any re-run against a reused local DB finds her mentions no longer filtered and times out waiting for a request. Fresh-DB CI is unaffected. A fix could remove the permission in on_exit via an API call if one exists, or the test could tolerate the pre-permitted state.

Environment

• Repro: edit docker-compose.ci.yml images to v4.6.1, then docker compose -f docker-compose.ci.yml down -v && ./scripts/ci/setup_mastodon.sh && source scripts/ci/.env.hunter && mix test --only integration
• Result on v4.6.1: 26/28 (only the two above fail) · on v4.4.8: 28/28

🤖 Generated with Claude Code

https://claude.ai/code/session_012Ye7jCRcC5hkSBt3dALD44

[milmazz]

Investigated both failures against a freshly provisioned v4.6.1 stack (plus curl and source-level analysis of Mastodon v4.4.8 ↔ v4.6.1). Findings:

1. Scheduled-status idempotency 500 — upstream Mastodon 4.6 regression, not a Hunter bug

The first POST /api/v1/statuses with an Idempotency-Key succeeds; any second call with the same key returns 500. Web container log:

NoMethodError (undefined method 'account' for nil):
app/services/process_hashtags_service.rb:6:in 'ProcessHashtagsService#call'
app/services/post_status_service.rb:163:in 'PostStatusService#postprocess_status!'
app/services/post_status_service.rb:61:in 'PostStatusService#call'

Mechanism (diff of post_status_service.rb v4.4.8 → v4.6.1): the 4.6 refactor moved the duplicate check into a with_idempotency helper. On a dedup hit, its return idempotency_duplicate only returns from the helper — call discards the value, continues with @status = nil, and postprocess_status! crashes. In 4.4.8 the return lived directly in call. Reproducible with plain curl (first call 200, second call 500). Still present on mastodon main as of 2026-07-16; no upstream report found. Nothing to change in Hunter — the test is asserting documented behavior. This blocks bumping CI to 4.6.x unless the dedup assertion is version-guarded.

2. Missing NotificationRequest — not a 4.6 change; it was the test's own leftover state

On a truly fresh 4.6.1 database the full suite passes this test (my run: 28/29, the only failure being the 500 above). The failure only reproduces on a reused database: accepting a request grants kadaba a permanent NotificationPermission, FilterCondition#override_for_sender? then exempts her mentions from filtering forever, so no request is created and eventually times out. Confirmed the permission row directly in the DB of a poisoned stack; the same exemption exists in 4.4.8. So the "related, but separate" non-idempotency noted in this issue was the whole story for this failure.

Fix (PR #149): Mastodon exposes no API to revoke the permission, but BlockService destroys it (both 4.4.8 and 4.6.1), so the test now resets it with a block/unblock pair at the start and in on_exit. Verified: 3 consecutive green runs on a poisoned 4.6.1 DB, and 29/29 on a fresh CI-pinned 4.4.8 stack.

Operational note

Two back-to-back full-suite runs against one stack trip rack-attack throttles (30 deletes/30 min) and fail with 429s — clear the rack::attack/rate_limit Redis keys between runs when testing locally.

Disposition

• Hunter-side bug: fixed by Make filtered-notification integration test idempotent (#144) #149.
• Idempotency 500: needs an upstream mastodon/mastodon report; nothing actionable in Hunter until their fix ships, at which point the 4.6 CI bump can proceed with no test changes.

🤖 Generated with Claude Code

[milmazz]

Closing: the Hunter-side failure is fixed by #149, and the remaining failure is an upstream Mastodon 4.6 regression tracked for the CI-bump work rather than a Hunter bug.