[rawo]

Closes #130.

Problem

OutboxProcessor.processNext writes every result of a batch with one updateAfterProcessingBatch call inside the claim transaction. If the database rejects one row's last_error, the whole transaction rolls back:

• entries that were already delivered go back to PENDING
• retries doesn't advance for anything

The next tick redelivers the entire batch, and this repeats indefinitely. Under Exposed's default retry it happens three times per tick. Two values trigger it easily:

• MySQL: an HTTP error body over 64 KB overflows TEXT (ERROR 1406 Data too long).
• Postgres: a NUL character is refused in text.

Separately, HttpMessageDeliverer read every response body fully into heap with BodyHandlers.ofString().

Fix

• Core (covers every transport): OutboxEntry.retry and toFailed sanitize the error.
  • NULs are stripped.
  • The text is truncated to the new public OutboxEntry.MAX_LAST_ERROR_LENGTH = 4096 chars with a ... [truncated] marker, never between the two halves of a surrogate pair (MySQL rejects a lone surrogate as an invalid string).
  • 4096 chars × 4 bytes fits comfortably inside MySQL's 65,535-byte TEXT.
• HTTP: a bounded body handler.
  • 2xx bodies are discarded (BodySubscribers.replacing("")).
  • Error bodies keep only the first HttpMessageDeliverer.MAX_ERROR_BODY_BYTES = 2048 bytes, and the rest is drained without being stored so the connection stays reusable.

Not in this PR

The issue also suggests isolating per-row update failures, e.g. falling back to row-by-row updates so any unexpected DB rejection only affects its own row. That is a larger behavioural change to the store/processor contract. With both known triggers removed I've left it for a follow-up, and I'm happy to open an issue for it.

Tests

• MysqlLastErrorPoisonBatchTest / PostgresLastErrorPoisonBatchTest (Testcontainers) share lastErrorPoisonBatchTests:
  • control: writing the raw value (100 KB on MySQL, NUL on Postgres) through updateAfterProcessingBatch fails. This proves the scenario is real.
  • a batch of one healthy and one poisoned entry → the healthy one stays DELIVERED, and the poisoned one is PENDING with retries = 1 and a bounded, NUL-free last_error.
• OutboxEntryLastErrorTest: unchanged short errors, truncation on both retry and toFailed, the exact-limit boundary, NUL stripping, and no split surrogate pairs.
• HttpMessageDelivererTest: a 1 MB error body is bounded in both deliver() and deliverBatch(), short error bodies are kept whole, and a large success body is discarded while still counting as Success.
• ./gradlew ktlintCheck build test pass locally.

🤖 Generated with Claude Code

[rawo]

Review focused on transactions/data loss, memory, performance and structure. The fix is correct for both triggers in #130. sanitizeLastError keeps the result ≤ MAX_LAST_ERROR_LENGTH, the surrogate check is right, and the bounded body handler does cap heap per request. The control tests are a good touch. No blockers. Inline notes below, roughly in order of importance.

Residual poison-batch risk (worth tracking in the follow-up you mention): sanitizing only covers the two known values. One more cheap trigger remains on MySQL: okapi_outbox is created without an explicit CHARACTER SET, so it inherits the schema/server default. On a schema that is still latin1 or utf8mb3, which is common on 5.7-era or migrated databases, an error body containing an emoji or any character outside that charset fails in strict mode with ERROR 1366 Incorrect string value. That rolls back the whole batch again, delivered entries included. Two options: add DEFAULT CHARSET=utf8mb4 in a new changeset (the existing-table case needs an ALTER), or prioritise the per-row fallback so any unexpected rejection only affects its own row. I'd open that issue now rather than later.

[rawo]

Minor, structure: sanitizing in retry/toFailed covers the processor path, but OutboxEntry is a public data class. copy(lastError = ...) or the constructor (custom processors, tests, listeners that rebuild entries) still reach updateAfterProcessing* unsanitized. The real boundary is the store write (setString(5, entry.lastError) in both stores). Calling sanitizeLastError there too, or only there, would make the guarantee hold for every caller. It is idempotent, so doing it in both places costs nothing.

Nit: the KDoc says "at most 4 bytes per char". A UTF-16 char is at most 3 UTF-8 bytes (a 4-byte code point uses 2 chars), so the real bound is ~12 KB. The conclusion holds; only the wording is off.

[rawo]

Performance / lock duration: replacing("") and boundedUtf8Body both still read the whole body to drain the connection. Heap is now bounded, but time isn't. HttpRequest.timeout only covers waiting for response headers, not body streaming. So an endpoint that drips a large or endless error body keeps deliver() busy indefinitely, and with it the scheduler's claim transaction: the claimed rows stay locked, and on MySQL under REPEATABLE READ so do the gap locks (#129).

This isn't a regression (ofString() behaved the same way), but now that the subscriber is custom it's cheap to fix. Once limit bytes are collected, subscription.cancel() instead of draining. For HTTP/1.1 that closes the connection rather than reusing it, which is the right trade for an error response. HTTP/2 just resets the stream. That needs a small hand-written BodySubscriber instead of ofByteArrayConsumer, which can't cancel. An overall deadline on the batch (future.get(timeout) / orTimeout) would also bound it.

[rawo]

Concurrency reasoning checks out. Reactive Streams §1.3 guarantees serial onNext signals with happens-before, and the mapping runs off the completed future, so the unsynchronized ByteArrayOutputStream/truncated state is safe.

Nit: "... [truncated]" now appears in two modules. OutboxEntry.TRUNCATION_MARKER is private, so the HTTP module and both tests hard-code the literal. Consider making it public (or internal plus a test-fixture accessor) so the marker can't drift.