[nijeesh-stream]

TLDR

• The CI app (31197) now has scheduled messages enabled (chat_scheduled_messages_enabled), so ScheduledMessageIntegrationTest no longer needs the STREAM_SCHEDULED_MESSAGES_ENABLED gate. It was never set in CI, so these tests have never run. The gate is removed and they now run on every PR and in the weekly scheduled job.
• The server rounds a future scheduled_at up to the next whole UTC minute (minimum now + 1 minute). The create and update tests now floor the requested time to a whole minute, which the server stores unchanged, and assert it exactly instead of to the second.
• Risk: test-only change. The tests now depend on the CI app keeping the feature on.

🤖 Generated with Claude Code

---

Note

Low Risk
The serialization tweak only drops an empty legacy field from outbound message requests; integration coverage now assumes CI keeps scheduled messages enabled.

Overview
Scheduled message sends no longer include an empty reaction_scores object in the JSON body. MessageRequestObject now uses @JsonInclude(NON_EMPTY) so Lombok’s @Singular map is omitted when unset, avoiding {} that breaks scheduled sends on servers before chat#19652. A unit test asserts the scheduled send payload does not contain reaction_scores.

Integration tests for scheduled messages run unconditionally: the STREAM_SCHEDULED_MESSAGES_ENABLED gate is removed now that CI’s app has the feature on. Create/update tests floor scheduled_at to a whole UTC minute (matching server rounding) and compare Date values exactly instead of by second.

^{Reviewed by Cursor Bugbot for commit 49ec51b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[ianb-gs]

CI is red on exactly the tests this PR un-skips. In the 🧪 Test & lint job, all 5 integration tests that call schedule(...) fail with StreamException: SendMessage failed with error: "", thrown from schedule() at ScheduledMessageIntegrationTest.java:34:

• Can schedule a message on behalf of a user
• Can update the message and send time of a scheduled message
• Can query a user's scheduled messages in a channel
• Can send a scheduled message now
• Can cancel a scheduled message

The failure happens on the send request itself, before any of the new minute-rounding assertions run, so the assumption that the CI app has the feature enabled hasn't been shown to hold here.

One data point: the .NET SDK's equivalent live tests (stream-chat-net#219) no longer skip when the feature is off, and its CI is green, so the .NET CI app does have scheduled messages enabled. Worth checking:

1. Whether Java CI's STREAM_KEY points at the same app (the PR mentions 31197) with chat_scheduled_messages_enabled on.
2. If it does, whether the send payload matches the backend contract, e.g. scheduled_at combined with pending or other fields. The empty error message also suggests the SDK's error parsing drops the response body, and assertDoesNotThrow hides the status, so printing the raw status and body would make this much easier to diagnose.

This shouldn't merge until the job is green.

[nijeesh-stream]

Thanks, root-caused. The Java CI app (31197, us-east4:c1) has chat_scheduled_messages_enabled on. The failure is a server bug: the Java SDK always sends "reaction_scores": {}, and the server's JSONPlaceholder type had no MarshalJSON, so the stored scheduled payload was written as invalid JSON ("reaction_scores":e30=) and the INSERT failed with syntax error at or near ":" (500). Go/Ruby/PHP/.NET/Python don't send that field, which is why their suites pass.

Server fix: https://github.com/GetStream/chat/pull/19652. This PR stays unmerged until that's deployed on c1 and CI is green.

Agree on the empty error message: a 500 body loses its details in the SDK's error parsing. I'll track that separately.