Troubleshooting Tips
Some tips for avoiding common problems.
- Troubleshoot authorization mismatch
- Check the channel
- Troubleshoot data state operations
- Troubleshoot user voting
- Ensure correct time settings
You can also get help from Muxy and the developer community by joining the Muxy Developer Support Forum on Discord.
Troubleshoot authorization mismatch
A JWT is issued for a specific environment:
- Requests for the production environment are made to
api.muxy.io
- Requests for the development or staging environment are made to
sandbox.api.muxy.io
If the token you are using to authorize a request does not match the target environment, the request fails with an error like the following:
Request authorization failure
Status: 403 forbidden
Body:{ "reason": "User was unauthorized to access this resource", "info": "Allowed stage mismatch" }
This typically happens when you switch between the staging and production environments using a sandbox-only token. You must obtain a new token for the production environment, using the PIN authorization workflow.
- For a Unity game, see the example in the Unity GameLink Tutorial.
- For other development platforms, see one of these recipes:
To check the target environment of a JWT you are using to authorize calls:
- Look at the token in the Authorization header of any request to an authenticated endpoint (that is, any endpoint other than
auth
). The header contains your client ID (a number) followed by the JWT:
"Authorization: extension-id jwt". The JWT is an alphanumeric string that starts witheyJ
. - Copy out the JWT part and enter it into JWT.IO.
- Look for the
allowed_stage
field in the payload area. If the value does not match the expected stage, then this is an error.
- In a sandbox-only JWT, the
allowed_stage
value is "sandbox", which causes the "Allowed stage mismatch" in the production environment. - In a production-stage JWT, the field does not exist, which causes an error in the sandbox environment.
Check the channel
If you receive data for a channel other than the one you expect, you can check the channel encoded in the JWT you are using to authorize requests.
To check whether a JWT is generated for the wrong channel:
- Look at the token in the Authorization header of any request to an authenticated endpoint (that is, any endpoint other than
auth
). The header looks like this: "Authorization: ". The JWT value should start with 'eyJ'. - Copy out the JWT part and enter it into JWT.IO.
- Check the 'channel_id' and 'user_id' fields to make sure they match what is expected.
The channel_id
value is the same as the user_id
of the broadcaster of that channel.
Troubleshoot data state operations
If you are getting unexpected results when accessing stored data values, check that values are actually getting set in the proper store. The different stores for state and configuration data have specific authorization requirements.
- The caller must have the
broadcaster
role to successfully write configuration values, or to set values in thechannel_state
store. - The broadcaster must be the owner of an extension to set values in the
extension_state
store.
If state values are not found or are incorrect, they might have been set without proper authorization, or they might have been written to the wrong data store.
You can retrieve all state values to make sure that a state value was actually set as expected, and is in the correct state store.
js medkit.getAllState().then(state => { console.log(state); });
js medkit.getAllConfig().then(config=> { console.log(state); });
See the Data Tracking guides for complete details of the scope and authorization requirements for the different data stores.
Troubleshoot user voting
A common mismatch with voting occurs when viewers vote using a stale poll ID.
Consider a game that intermittently runs a poll with poll_id="rps"
to play Rock Paper Scissors against the audience. Every 5 minutes, the game writes to state and then broadcasts a message, which pops up a poll on the extension interface. After one minute, it gets the results.
This flow will count all of the votes in the rps
poll, including votes from previous runs, and votes that were cast between runs. Even if you delete the poll after the run, users can still cast votes using that ID, and those votes become "stale" votes in any future run that you create using the same ID.
The poll manager can send a DELETE request to clear data from the log for a given poll ID. (See Poll Management for details of the REST API.)
To ensure that each poll begins with a clean slate, the game should do this immediately BEFORE creating a new poll with the same ID. (It's ok to delete an ID that does not exist.)
The correct sequence of operations is: Delete poll ID -> Create new poll with ID -> Wait for votes -> Get results
Ensure correct time settings
Sometimes users' system clocks can't be trusted to have the correct time. For
example, users who live near a time-zone border might manually set their time zone
and adjust the system clock by an hour.
To avoid problems, MEDKit provides the function getOffsetDate()
to get a more accurate date object.
The SDK communicates with the server on load to calculate the time offset without reference to the user's system clock.
The function takes no arguments, and returns a Date object representing the real time.
medkit.getOffsetDate();
Updated almost 3 years ago