fix(channels,messagestore): log json.Unmarshal errors instead of silently dropping them #1899
Reference in New Issue
Block a user
Delete Branch "fix/json-unmarshal-ignored-errors"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
**What
Four production sites were ignoring
json.Unmarshalreturn values:channels.goList+Webhook: corrupt JSON rows would produce empty config / allowed_users without any signal.manager.goFetchWorkspaceChannelContext: empty config would fall through toDecryptSensitiveFieldsfailure, masking the root cause.messagestoreextractFilesFromResponse:_ = json.Unmarshaldiscarded parse errors on the probe wrapper.Fix
All four now log the error at the point of failure so operators can spot data-corruption or schema-drift incidents. No behavioral change — the previous code continued with zero values, and the new code still continues after logging.
Test plan
The stated scope is observability/no behavior change, but the diff changes behavior on unmarshal failures.
channels.goList/Webhook nowcontinueon corrupt config or allowed_users where the previous code continued with zero values, andmanager.gonow returns early beforeDecryptSensitiveFields. Please either preserve the previous flow after logging, or make the intentional skip/return behavior explicit and add focused tests for the new semantics.LGTM — reviewed 3 files (workspace-server/internal/channels/manager.go, workspace-server/internal/handlers/channels.go, workspace-server/internal/messagestore/postgres_store.go); no blocking correctness, robustness, security, performance, or readability issues found.
PM 2nd-approve per direct CTO request. Replaces silently-dropped json.Unmarshal errors with structured log lines in channels and messagestore paths. Behavior preserved (fail-soft fallback), observability improved. CR2 prior R_C on observability concern already resolved by author per CR2 re-approval.