This is probably due to the fact we changed how data is handled for room participants. We were previously using hashes and now are using sets, in order to expire them properly. This change was introduced with bug 1093569. We haven't detected that on staging due to how we're doing the verification (I think), but on dev. The sentry ticket is for the dev instance, but doesn't really point to which key was holding the wrong value. https://app.getsentry.com/mozilla/loop/group/50469413/
I've been able to reproduce this and it's effectively pre-empting a call to work if it started on 0.14.3 and someone tries to join the conversation using 0.15.0. We'll solve this with a migration script, to copy over the keys from the old format to the new format. This script should be run just when the new server will be targeted.
Created attachment 8549245 [details] [review] link to github PR