Without an initial flush(), the JVM HttpServer buffers all
output until the first flush() in the 15-second keep-alive loop.
Clients with shorter timeouts (e.g. 10 s) abort before receiving
any data.
Add a flush() call directly after creating ServerSentEventSender,
before the wait loop, so the HTTP 200 response and headers reach the
client immediately upon connection.
Adds regression test SseInitialFlushTest that verifies at least one
byte arrives within 2 seconds of connecting to GET /api/v1/events.
When filling or updating a V2 group, profile keys were copied from
DecryptedGroup.members into the local profile store but not from
requestingMembers. Admins who never had a prior session with a user in
the join queue then lacked profile keys and could not decrypt profiles
(e.g. for listContacts).
Also process DecryptedRequestingMember entries the same way as full
members, using DecryptedMember / DecryptedRequestingMember types so the
lib module does not require a direct protobuf dependency.
Made-with: Cursor
* Add distinct JSON-RPC error code for captcha rejection
Previously submitRateLimitChallenge mapped CaptchaRejectedException to
the generic USER_ERROR code (-1), making it indistinguishable from any
other user error (bad params, unknown command, etc.).
Introduce CaptchaRejectedErrorException and wire it to a new error code
(-6 / CAPTCHA_REJECTED_ERROR) throughout the JSON-RPC layer. Callers can
now reliably distinguish a rejected captcha token (user must obtain a
fresh token) from a network failure (transient, worth retrying) or a
generic argument error.
The CLI exit code for this path becomes 6, consistent with the existing
per-error-type exit code convention.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Add exit code 6 to man page
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* Add OpenAPIDocs
* Remove the json prefix from the names
* Format file
* Rename models to schemas
* Add required = true to all the required attributes
* Add missing required = true schemas
* Deprecated fields are not required
* switch to micronout json generation
* Fix generator for JsonUnwrapped files
* Fix layout of manual schemas
* Pretty print the json files
* Remove @JsonProperty(required = true)
* Make references local
* Updated the readme
* Removed uneeded import
* Remove extra empty lines
* Clean readme
* Add docs depedency only when needed
* Revert uneeded changes
* Revert more changes
* Better formatting
* Simplified name
* fix: remove jsonunwrapped workaround by upgrading to micronaut-json-schema version 2.0.0-M6
* Simplified jsonSchemas task definition
* Updated readme with the new schemas path
* typo fixing
* Remove empty space from merge
* Surface retry-after seconds for plain rate-limit failures
libsignal-service's RateLimitException exposes retryAfterMilliseconds
for HTTP 413 responses, but signal-cli only forwarded retry-after for
ProofRequired (428) failures. Clients had no signal for when it was
safe to retry plain rate-limited sends, so every failed retry
potentially extended the server-side window.
SendMessageResult now carries an optional rateLimitRetryAfterSeconds,
populated from the upstream Optional<Long>. JsonSendMessageResult
exposes it for RATE_LIMIT_FAILURE type. Text output includes the
window when known. Aggregate RateLimitErrorException now carries the
real nextAttemptTimestamp (was hardcoded to 0).
Closes#1996.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Address review: include proof-required retry-after and ceiling-round millis
Codex adversarial review flagged two issues in the phase 1 retry-after
plumbing:
* Aggregate retry-after ignored proof-required failures. Because
isRateLimitFailure is true for proof-required cases but
rateLimitRetryAfterSeconds was only populated from plain 413s, an
all-proof-required batch (or a mixed batch where the proof-required
delay was longer) could flow into outputResult() and produce a
RateLimitException(0), telling callers to retry immediately.
* Millisecond Retry-After values were truncated by integer division,
so 1..999ms became 0 and non-second-aligned values lost up to 999ms.
A retry suggested from the floored value can land before the
server's real deadline and re-trigger the limit.
SendMessageResult.from(...) now populates rateLimitRetryAfterSeconds
from either the proof-required seconds or the plain rate-limit ms
(converted via ceiling division), giving maxRateLimitRetryAfterSeconds
a single source of truth. JsonSendMessageResult.from(...) reads the
unified field. New millisToCeilingSeconds helper plus boundary test.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Preserve source compat and document retry-after field change
Add a non-canonical 8-arg SendMessageResult constructor that delegates
to the canonical form with null retry-after. This keeps source
compatibility for any downstream code that constructs the record
directly (tests, mocks) without changing the canonical shape. Records
permit additional constructors alongside the canonical one.
Document the retryAfterSeconds meaning change in the CHANGELOG. The
field was previously populated only for proof-required failures; it
is now populated whenever the server sends a Retry-After header. The
canonical proof-required discriminator is still token != null.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Fix sender key re-distribution on every group message in daemon mode
sendGroupMessageInternalWithSenderKey() calls sender.send() which handles
distribution and delivery, but never calls markSenderKeySharedWith() on
success. SenderKeySharedStore therefore has no record that the distribution
was sent, causing it to re-distribute to all recipients on every subsequent
sendGroupMessage call.
This results in a fresh unidentified TLS connection being opened for each
group message (~6s delay per send), even for back-to-back sends to the
same group. All send modes are affected: DBus daemon, JSON-RPC socket/http,
and CLI send command all share the same code path.
The fix mirrors the existing pattern in resendMessage() (line 307): after
a successful send, record each successful recipient's address+device in
the sender key shared store.
* Fix sender key re-distribution on every group message
SenderKeySharedStore.markSenderKeysSharedWith() stored the address using
entry.toString() instead of entry.address(). Since SenderKeySharedEntry is
a Java record, toString() returns the full record representation:
SenderKeySharedEntry[address=<uuid>, deviceId=1]
instead of just the UUID. When signal-service-java later calls
getSenderKeySharedWith() and compares the retrieved addresses against the
current group member UUIDs, the comparison always fails — causing the
distribution message to be re-sent to all recipients on every
sendGroupMessage call.
This results in a fresh unidentified TLS connection being opened for each
group message (~6s delay per send), even for immediate consecutive sends
to the same group. All send modes are affected: DBus daemon, JSON-RPC
socket/http, and the CLI send command all share the same code path.
The fix is a one-character change: entry.address() instead of
entry.toString().
