Read rows other applications wrote without failing on their payloads

[devhawk]

Two bugs a Java application hits when it shares a system database with applications it did not write. Both surfaced in the interops demo, where Java, Python, TypeScript and Go apps drive each other's workflows through one dbos schema.

Read an empty error column as no error

The Go SDK stores a workflow's error as a non-nullable string, so a workflow that succeeded leaves "" in error where this SDK writes NULL. Java treated any non-null value as an error and parsed it as JSON, so reading a perfectly healthy Go workflow threw:

MismatchedInputException: No content to map due to end-of-input

The other SDKs already tolerate both spellings — TypeScript coerces on the way in (row.error ? row.error : null), Python never reads the column unless the status says ERROR. SystemDatabase.errorOrNull does the same at each site that reads the column: a workflow's, a step's, and the transactional step schema's.

Empty, not blank. No SDK writes a non-empty run of whitespace here, so a blank-but-not-empty value is content to hand back rather than quietly discard. What this SDK writes is unchanged and stays conservative: an absent error is NULL.

Don't try to deserialize a format we don't recognize

getWorkflowStatus threw IllegalArgumentException: Serialization is not available on any row written in a format this runtime has no deserializer for. Workflow IDs address the whole system database, so a status read reaches another application's rows on purpose, and what is wanted from such a row is the metadata — who owns it, what it is, whether it finished. Losing all of it over a payload the caller may not have asked for is the wrong trade.

Not only an interop problem: two Java applications on one system database, one configured with a custom serializer and one not, hit exactly this. custom_base64 is as unreadable here as py_pickle is.

SerializationUtil.canDeserialize asks the question directly rather than catching a failure — the two built-in formats, plus whatever a configured custom serializer names. The reads that assemble a record from a row skip the payloads when the answer is no and report them as null.

Only where the payload is one field of a record — a workflow's status, a workflow's steps. Everywhere the payload is the answer still throws, because there is nothing else to hand back: getEvent, a workflow's result, a recv'd message, a stream, and a recorded step result on replay. That last one matters most, since a step that "returned null" because its output could not be read would corrupt the run it is replaying, so it has a test of its own.

Three paths read a record but must not accept a null payload, and check for themselves:

• Running a workflow. The arguments are the point, and one invoked with arguments it never had is worse than one marked ERROR. executeWorkflowById refuses and names the format. The error is recorded in this runtime's own format: one we cannot read is one we cannot write, and serializing into it would throw and leave the workflow PENDING forever — the hang this refusal exists to prevent.
• Exporting one. An export is imported back, so a payload dropped on the way out restores a workflow that never had it. Conductor can ask an application to export a peer's workflow, which is exactly when this bites.
• Importing one. Import re-serializes every payload, so it needs a serializer for the recorded format as much as export did, and it writes a null payload straight through as NULL — a lossy batch would import as an emptied workflow rather than an error. Checked for the whole batch before the transaction opens.

Testing

• 632 tests pass; spotlessCheck, javadoc and compileTestJava green.
• New InteropTest cases cover both empty-error reads, peer rows in an unreadable format (status and listing), a custom serializer this app lacks, the export and import refusals, and the step-replay refusal.
• New PortableSerializationTest case drives an ENQUEUED py_pickle row through the executor and asserts it lands ERROR naming the format, rather than hanging PENDING.
• Verified end to end against the interops demo: 57 tests pass with the four-language apps sharing one system database, built against this branch.

🤖 Generated with Claude Code

[devhawk]

adding some fixes to breaking changes introduced by #471