You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
descriptor: PoolError::InvalidJsonName covers two different failures, and MalformedMapEntry::message holds a field name #641
Three PoolError shapes in buffa-descriptor/src/pool.rs are worth settling before the next breaking release, since variant and field names are public API.
InvalidJsonName { field, name } reports two unrelated rules: a JSON name that contains NUL, and a non-extension JSON name of the form [...]. Display re-derives which one from name.contains('\0'), and a caller that matches the variant has to do the same. The variant is unreleased, so splitting it (or adding a reason field) costs nothing now.
MalformedMapEntry { message } carries the full name of the map field that uses the entry, as its docs say; the entry message is that field's type. Every other variant uses field for a field name and message for a message name. This one has shipped since 0.7.0, so the rename to field is a breaking change.
MissingTypeName { field } is also returned for an extension with no extendee and a method with no input_type or output_type (resolve_message_type_name). Its message then reads "field pkg.Svc.Method has no type_name", which names neither the missing attribute nor the right kind of declaration.
Activity
bniladridas commentedon Oct 25, 2026
I can work on this. I'd suggest splitting the two non-breaking changes first:
InvalidJsonNameinto the two more specific variants.MissingTypeNameto distinguish fields withouttype_name, extensions withoutextendee, and methods withoutinput_typeoroutput_type.For the
MalformedMapEntry->fieldrename, would you prefer to include that here or reserve it for the next breaking release?I'm happy to follow your preference on the scope.