Skip to content

[6/6] api: Audit enums to handle unknown values where appropriate - #2395

Open
sm-sayedi wants to merge 61 commits into
zulip:mainfrom
sm-sayedi:1982-parse-enums-laxly-p6
Open

[6/6] api: Audit enums to handle unknown values where appropriate#2395
sm-sayedi wants to merge 61 commits into
zulip:mainfrom
sm-sayedi:1982-parse-enums-laxly-p6

Conversation

@sm-sayedi

Copy link
Copy Markdown
Collaborator

Fixes #1982.
Rebased atop #2394.

Goes through all the enums defined in lib/api (from top to bottom, both through the files and inside the files). Makes the enums accept unknown values or explains why we don't/can't accept them. For finding enum definitions inside a file, I used enum [^{]+\{ regex in VSCode "Find" feature (Cmd+F shortcut).

I have also taken the opportunity of going through all the API enums to use dot shorthands in their usages. To find all the usages of FooEnum, I used \bFooEnum(\.\w+) regex in the VSCode "Search: Find in Files" feature (Shift+Cmd+F shortcut) with case-sensitivity on and used the capture group ($1) as the replacement.

sm-sayedi added 30 commits July 28, 2026 00:35
We'll soon change Message.type to use MessageType instead of String.
This will make it compatible with the modern values "channel" and
"direct" when the server starts sending them in the future.

Having it next to Message seems more appropriate than its previous
location.
…omJson

And change MessageTypeConverter.fromJson to forward to MessageType.fromJson.

In future commits, we can use the compatibility logic independent
of MessageTypeConverter; simply by using MessageType.fromJson.
As of 2026-06, the server only sends "stream" type we already support.

This change is for accepting the modern "channel" type that the server
may start sending in the future.
This way, it can also accept "channel" and "direct" as the valid values
for the message type when the server starts sending them in the future.

As of 2026-06, the server only sends "stream" and "private" for message
types. Now, we map them to "channel" and "direct" in deserialization.
The modern type "channel" was added in server-9 (FL-248).
`realm_wildcard_mention_policy` is deprecated in server-10 (FL-352), so
making it optional will avoid throwing when the server stops sending it.
We were already handling unrecognized setting names in
UserSettingsUpdateEvent by making the corresponding field nullable.
To follow our usual pattern for handling unknown values from the Zulip
server API, added an "unknown" value to UserSettingName and made the
field non-nullable.
To make its name consistent with SubscriptionProperty.
We were already handling unrecognized property names in
ChannelUpdateEvent by making the corresponding field nullable.
To follow our usual pattern for handling unknown values from the Zulip
server API, added an "unknown" value to ChannelProperty and made the
field non-nullable.
And add dartdoc.

Although the previous name (fromApiValue) was technically correct, we
generally use that name when the API value differs from the serialized
enum value generated by JsonEnum.fieldRename; for example, in
SystemGroupName:
  'role:administrators' -> SystemGroupName.administrators

The new name (fromRawString) is generally used when the API value and
serialized enum value are the same:
  'allow_empty_topic' -> ChannelTopicsPolicy.allowEmptyTopic
sm-sayedi added 26 commits July 28, 2026 00:41
To match the fallback value in UserTopicItem.visibilityPolicy and avoid
throwing on unrecognized API values.
To match the fallback behavior of Message.flags and avoid throwing on
unrecognized API values.
And add dartdoc.

Although the previous name (fromApiValue) was technically correct, we
generally use that name when the API value differs from the serialized
enum value generated by JsonEnum.fieldRename; for example, in
SystemGroupName:
  'role:administrators' -> SystemGroupName.administrators

The new name (fromRawString) is generally used when the API value and
serialized enum value are the same:
  'unicode_emoji' -> ReactionType.unicodeEmoji
Previously, it would throw and the defined "unknown" value was never
actually used. The purpose of having an "unknown" value is to handle
unrecognized inputs without throwing.
@sm-sayedi sm-sayedi added the maintainer review PR ready for review by Zulip maintainers label Jul 27, 2026
@sm-sayedi
sm-sayedi requested a review from rajveermalviya July 27, 2026 20:46
@sm-sayedi
sm-sayedi force-pushed the 1982-parse-enums-laxly-p6 branch from 1c51e7a to 348e480 Compare July 27, 2026 20:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maintainer review PR ready for review by Zulip maintainers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Audit enums in API to parse laxly where appropriate

1 participant