As noted by @illustreets, I’ve run into something similar indeed a few times. My app’s Meteor version is still 1.9.2. I ultimately did nothing to fix this, because apart from a few times this error never popped up again.
The exact same errors in my app never resulted in server crashes, however, so your case seems far more serious than was mine.
Let’s separate concerns at this point. The server crash is one issue, posting it on Github sounds like a very good idea.
The other concern is the IDBDatabase transaction error. Please read my original post and the answers to it if you didn’t yet.
I’ve checked the error stack trace of your app, and this revealed that the error occurred in your app at the very same Meteor code line as in mine:
In the original thread @rjdavid said they’re experiencing this error too.
The error occurs in conjunction with Meteor’s dynamic import handling, so far usually (or only?) observed on iPads and iPhones. It breaks the dynamic import cache in IndexedDB for that app, meaning that the app on that device can’t recover again, unless the IndexedDB will be properly deleted and the app restarted. I’ve found out about how to do that programmatically:
window.indexedDB.deleteDatabase("MeteorDynamicImportCache");
window.location.reload();
See that answer here. In that scenario your client code would catch the error and deal with it accordingly.
I still can’t comprehend how a mere propagation of a client error to the server can lead to its crash. Are you 100% sure that the two things are related to each other? Does the timestamp of the server crash match very closely that of the client error?