vulcan icon indicating copy to clipboard operation
vulcan copied to clipboard

Union codecs do not match by namespace

Open cryptism opened this issue 4 years ago • 3 comments

Given two events both called MyEvent that are records with the namespaces org.foo.events and org.bar.events, the expected behaviour would be to successfully decode a message matching org.bar.events if the respective codec was present in the union. However it fails as altMatching only seems picks up the first matching event in the union chain, which in this case would be the codec for org.foo.events.

Just want to check if this is indeed unexpected behaviour in vulcan, and what the behaviour should be - should both codecs be tested given the event or can altMatching be modified to match on the canonical name of the schema?

Happy to explain more if I haven't been clear here.

cryptism avatar Oct 15 '21 11:10 cryptism

We used to resolve on full name but it was changed in #132 (#136) -- maybe @bplommer can explain more?

vlovgr avatar Oct 17 '21 13:10 vlovgr

Yes, I think the current behaviour is wrong. It's really an artifact of how we build on top of the Apache Avro java SDK, which loses information during decoding. What happens is that Avro unions themselves are tagged (they begin with a number field indicating which union member they contain) but the Avro SDK converts them to an untagged union, so we have to use various heuristics to work out which union member we have decoded.

Not matching by namespace is, at least superficially, correct, as name matches only require the unqualified name, not the fullname, to match. However I think we should try to match on fullname first and then fall back to unqualified name if that fails - certainly we should try all alternatives with the same unqualified name before raising an error.

bplommer avatar Oct 17 '21 19:10 bplommer

#445 should allow addressing this properly, since we'll be decoding from a tagged rather than untagged union.

bplommer avatar May 05 '22 07:05 bplommer