fix: preserve explicit notification preference false - #57
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
assigned_to.notify.follow_preference/notify.follow_preferenceis a tri-state field:true— explicitly use the personal preference;false— use thepersonal_channelslisted in the request.The OpenAPI schema modelled it as an optional non-nullable boolean, so the generator emitted
FollowPreference boolwithomitempty. Go's encoder dropsfalse, so the SDK could never sendthe one value that activates
personal_channels— a request carryingpersonal_channelswasaccepted but delivered over the responder's personal preference instead.
Change
Model the field as
"type": ["boolean", "null"]in the OpenAPI source (already merged upstream inflashduty-docs) and re-sync + regenerate. The generator's existing nullable-request-scalar ruleturns it into a pointer:
Callers send an explicit
falsewithflashduty.Bool(false); a nil pointer stays off the wire.The same contract backs incident creation, responder addition and incident assignment, so all three
request schemas are corrected and
AssignedTonow exposesnotify..gitignoreadditionally covers local-only scratch directories so they cannot be committed by accident.Compatibility
FollowPreferencechanges fromboolto*boolon the three request-side notify structs. Keyedliterals that set the field must switch to
flashduty.Bool(true)/flashduty.Bool(false).Response-side structs (
ScheduleNotifyBy,EscalateTargetBy,FeedDetailIncidentAssignNotify) andthe escalation-rule / schedule request structs are unchanged — their backend counterparts are plain
booleans where omitted is equivalent to
false.Validation
make check— gofmt/gci clean, golangci-lint 0 issues,go test -race ./...green, build OK.*boolwithomitempty./incident/create,/incident/responder/addand/incident/assign:Bool(false)serialises as"follow_preference":false; nil omits the key entirely.Replaces #56 (same code, rebased onto a clean history).