the test events for subscriptions are different from actual subscription events coming from twitch

[rexroof]

Triggering a test event in the web ui generates a different json object than an actual sub event from twitch.

examples:

Actual event from twitch:

{
  "id": "7dc9cbef-86d7-419b-ad10-8f2eecb7529d",
  "event_id": null,
  "event_type": "subscribe",
  "event_source": "PubSub",
  "event_data": {
    "topic": "channel-subscribe-events-v1.503715992",
    "message": {
      "benefit_end_month": 0,
      "user_name": "nperry0",
      "display_name": "nperry0",
      "channel_name": "rexroof",
      "user_id": "33002146",
      "channel_id": "503715992",
      "time": "2021-05-07T11:24:37.152109459Z",
      "sub_message": {
        "message": "does this cover the postage?",
        "emotes": null
      },
      "sub_plan": "1000",
      "sub_plan_name": "Channel Subscription (rexroof)",
      "months": 0,
      "cumulative_months": 2,
      "context": "resub",
      "is_gift": false,
      "multi_month_duration": 0
    }
  },
  "created": "2021-05-07T11:24:37+0000",
  "origin": "twitch"
}

a similar test event triggered via the web UI:

{
  "id": "2b4b6111-eac7-4190-8d8b-d7beecc04ca7",
  "event_id": "3395a76c-bc0f-4b35-a0ee-ac7a7bdf9f06",
  "event_type": "subscribe",
  "event_source": "TestCall",
  "event_data": {
    "type": "MESSAGE",
    "data": {
      "topic": "channel-subscribe-events-v1.44322889",
      "message": {
        "user_name": "nperry0",
        "display_name": "nperry0",
        "channel_name": "rexroof",
        "user_id": "33002146",
        "channel_id": "503715992",
        "time": "2021-05-07T11:50:12.652Z",
        "sub_plan": "1000",
        "sub_plan_name": "Channel Subscription",
        "cumulative_months": "2",
        "streak_months": "",
        "context": "resub",
        "is_gift": false,
        "sub_message": {
          "message": "does this cover the postage?",
          "emotes": []
        }
      }
    }
  },
  "created": "2021-05-07T11:50:12.665233+00:00",
  "origin": "test"
}

there are some different data types in there, and the information coming through is in different spots.

[FiniteSingularity]

Thanks for catching that @rexroof, and for the detailed response of an actual sub. I'll take a look this afternoon, and get that fixed.

[FiniteSingularity]

Ok, looking at the full message structure- the Test data is actually closer to the raw message that is received by the PubSub listener:

{
  "type": "MESSAGE",
  "data": {
    "topic": "channel-subscribe-events-v1.503715992",
    "message": {
      "user_name": "nperry0",
      "display_name": "nperry0",
      // etc..
    }
  }
}

When I was re-doing the subscription message a couple weeks back, I apparently changed things to only grab the raw data field rather than the entire message. I am going to go back to putting the entire message structure back in event_data. The reason behind this- I'd like the event_data field to be the same data structure you'd receive from a native call of the API. Unfortunately, @rexroof this will be a bit of a breaking change, if your bot was already properly grabbing the real subscribe events. Apologies for that.

I will add some migration code to update old entries in the database to match the new format.

[rexroof]

no worries, as long as I can use the test events to generate all the json that I'd expect to come, I'm a-okay.

[FiniteSingularity]

I just merged in a branch that should fix this. A couple of things to note: 1) I don't get enough subs in my stream to reliably test the actual data coming from Twitch. If you get some sub messages that differ from what the test even shows, please let me know. 2) The PubSub docs (where we grab the subscription data from) shows that there is a "streak_months" parameter that doesn't show up in your example data, and I dont see it any of my recorded past subs. Then again, they might not have been streak subs. So, what I have done- you can leave streak_months blank, and if so, it will suppress it from the output. I suspect that Twitch only sends it if the sub is part of a streak. 3) In all the test messages I was generating a random id. These ids for real messages are database ids (so that you can use future TAU api endpoints to look them up). Since a test event is not added to the database, I am now setting these to null. 4) PubSub events do not return a twitch event ID. Therefore these values are also now null for Subscription test events. 5) AS mentioned above, the new format now embeds the topic/message fields within a data field. This is so that we are forwarding on the actual Twitch response in PubSub.

Please re-open and let me know if you find any more discrepancies. As I mentioned, actual twitch subs are a bit hard to test, as I cant just generate them, and (unfortunately ;) ) dont have them constantly pouring in during my streams. :D

[rexroof]

I want to comment, because I'm not sure if it was obvious: the messages that I posted in my original opening of this issue were BOTH events that came from tau, it's just that one was a test event and the other was actually triggered by a real event from twitch. the REAL event does contain a "months" attribute. could that be replacing streak_months?

so if the new format always puts the response under a data attribute, does that mean all of the test events should match the real events coming from twitch? seems like that would mean that I don't have to change my code if it's just designed with the existing test events?

[FiniteSingularity]

I want to comment, because I'm not sure if it was obvious: the messages that I posted in my original opening of this issue were BOTH events that came from tau, it's just that one was a test event and the other was actually triggered by a real event from twitch. the REAL event does contain a "months" attribute. could that be replacing streak_months?

I appreciate the clarification, and think we are both talking about the same thing. So that we can make sure we're talking about the same thing, and make sure there isn't another issue I am missing: the two differences I saw between the TAU test event, and the TAU twitch forward event were:

1. The base of event_data. The actual message from Twitch's PubSub looks like:

   {
   "type": "MESSAGE",
   "data": {
       "topic": "channel-subscribe-events-v1.{BROADCASTER_ID}"
       "data": { /* All of the event data */}
   }
   }

   I was correctly assembling this message for the test messages, but had a bug in processing the real twitch events, where I was only grabbing the "data" field. This is now fixed so that both the TAU test message as well as TAU's forwarded real twitch event, have the root type and data fields.

2. In my test event, I was not creating all of the necessary fields. (Side note- I still need to add a test event for gift subs, as their data format is a little different). The channel subscription PubSub response format can be seen here: https://dev.twitch.tv/docs/pubsub#example-channel-subscriptions-event-message . In my test events, I was missing benefit_end_month, months, and multi_month_duration, and was always including streak_months. In the PubSub event definition (link above), notice that both months, and multi_month_duration are deprecated, and have been replaced by cumulative_months, and streak_months. I believe that Twitch's definition of 'deprecated' is "leave the field, but always assign it a value of zero," as I've never seen months or multi_month_duration have anything but zero. However, now all of the fields are included- the deprecated fields are given a value of zero, and streak_months is only included if it has a value greater than zero.

so if the new format always puts the response under a data attribute, does that mean all of the test events should match the real events coming from twitch? seems like that would mean that I don't have to change my code if it's just designed with the existing test events?

That is the intent, yes- make the test events identical to the actual Twitch events. It looks like at this point, the non-gift-sub events should be identical, but please let me know if you notice any other inconsistencies. Also, stay tuned- I am going to be wiring up the ability to page through past events (Filtered by type), and give the ability to replay them. That way, you can play back old events, and make sure they match your generated test events. (I also included some migration code that is automatically run, which properly converted the old real subscribe events to have the correct format in the database).