Right now, reward redemptions that are not executed immediately (ie they get queued up), and are instead handled later by a moderator/streamer are ignored by the PubSub client. It's unclear initially why we had the code this way (maybe because of fluid models being returned from Twitch while this topic was undocumented). Now, we can safely use this same type for handling the redemption-status-update type.
Tested this code locally and it seems to be working fine.
Thanks to @itssimple for helping with this.
TODO: This whole topic (community-points-channel-v1) is deprecated/retired/undocumented in favor of the now documented channel-points-channel-v1.<channel_id>. We should probably keep the existing community-points-channel-v1 topic so as to prevent breaking people's codebases unnecessarily. All new implementations should use the channel-points topic though (once implemented).
Right now, reward redemptions that are not executed immediately (ie they get queued up), and are instead handled later by a moderator/streamer are ignored by the PubSub client. It's unclear initially why we had the code this way (maybe because of fluid models being returned from Twitch while this topic was undocumented). Now, we can safely use this same type for handling the
redemption-status-update
type.Tested this code locally and it seems to be working fine.
Thanks to @itssimple for helping with this.
TODO: This whole topic (
community-points-channel-v1
) is deprecated/retired/undocumented in favor of the now documentedchannel-points-channel-v1.<channel_id>
. We should probably keep the existingcommunity-points-channel-v1
topic so as to prevent breaking people's codebases unnecessarily. All new implementations should use the channel-points topic though (once implemented).(squash this PR)