AsyncAPI 3.x: build genes from message payloads

[LautaroPetaccio]

Seventh in the AsyncAPI stack, on top of #5. The first piece that turns the parsed document into something the search can hold.

The seam

The parser deliberately stops at the schema: it leaves every $ref inside a payload alone, and guarantees that whatever those references reach is present in componentSchemas. This trades on that guarantee — it hands the whole schema map to RestActionBuilderV3.createGeneForDTO, which wraps it in a synthetic OpenAPI document and lets the existing machinery resolve the references and build the genes.

Reusing that rather than writing a second JSON-Schema-to-gene converter means AsyncAPI payloads get what REST already has. I checked rather than assumed, by characterising the seam against the shapes AsyncAPI actually uses before writing anything:

shape	result
object with required	required fields plain, others OptionalGene
$ref to a component schema	resolved and inlined
minimum / maximum	kept — IntegerGene [min=3, max=1000]
oneOf	ChoiceGene over both branches
self-referencing schema	terminates via CycleObjectGene
nullable: true	NullableGene
type: [object, "null"]	object read correctly, but nullability dropped
const	lost — becomes a free string

The bounds one matters most: NCS's error reply is only reachable because n is declared minimum: 3, so the boundary has to survive into the gene for the search to find it. It does.

const

const is invisible to the gene builder, with or without an explicit type beside it. That is not an exotic corner: const is how a document says which message a payload is (request: {const: list_legs} — voiceblender does this across 109 operations, and five documents in the wider corpus use it). Left alone, the discriminator is a random string and the service never recognises the message.

It is rewritten to the single-valued enum that means the same thing, with the type inferred from the literal when the schema states none. A boolean const is the exception and stays free, since there is no enum handling for booleans — asserted in a test rather than left to be discovered.

Why invalidData is off for payloads

That flag adds a bogus member to every enum on purpose, to probe how a service handles a value it never declared. In a message payload it backfires: a const arrives here as a one-value enum, and a message carrying an unrecognised discriminator is silently dropped. Half the messages sent would go nowhere — wasting executions, and firing the no-reply fault target for a fault of our own making.

Nothing is lost for reaching error paths, since the bounds that drive them are preserved.

One change to shared REST code

Finding the above exposed an inconsistency, fixed here. The bogus member added to a string enum is guarded by options.invalidData:

if (options.invalidData) { add("EVOMASTER") }

but the 42, 42L and 42.0 added to integer, long and number enums were not — they were added even with invalid data switched off. They are now guarded the same way. Since allowInvalidData defaults to true, default behaviour is unchanged; this only takes effect for a caller that explicitly asks for valid data, which is what this PR does.

Happy to split that into its own PR if you would rather.

Testing

13 new tests in AsyncApiGeneBuilderTest, including one that builds a gene for every message of a real document and one that asserts building genes does not rewrite the parsed model underneath. 344 in total across the AsyncAPI package and the REST suites that exercise the shared builder — RestActionBuilderV3Test (155), HttpSemanticsOracleTest (55), SchemaUtilsTest, RestSchemaOraclesTest, BlackBoxUtilsTest, JsonPatchSchemaResolverTest.

[arcuri82]

fields should not be at bottom of file

[LautaroPetaccio]

Done!