You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our bounty activities wrap three logically distinct but ordered processes:
updating the bounty data model for the respective activity (I.e. marking a bounty as claimed)
updating the bounty card with the new bounty data
notifying the users in the interaction
Our current architecture means that runtime errors in either of those two functions result in the same error message (Sorry something is not working and our devs are looking into it.)
However, most errors with the bot come from steps 2 or 3. If the bounty data model has been updated, users can go to the web to find an accurate representation of the bounty.
Ideally, we can find some sort of smart way to tell users that in a disaster scenario their bounty has been updated, but that the failure means the bounty card will be stale until a fix/update is pushed.
The text was updated successfully, but these errors were encountered:
Our bounty activities wrap three logically distinct but ordered processes:
Our current architecture means that runtime errors in either of those two functions result in the same error message (
Sorry something is not working and our devs are looking into it.
)However, most errors with the bot come from steps 2 or 3. If the bounty data model has been updated, users can go to the web to find an accurate representation of the bounty.
Ideally, we can find some sort of smart way to tell users that in a disaster scenario their bounty has been updated, but that the failure means the bounty card will be stale until a fix/update is pushed.
The text was updated successfully, but these errors were encountered: