Based on your stack trace, the issue happens from the collection2 library, which uses an outdated method for configuring allow/deny rules. The problem isn’t with updateAsync as a Mongo operation or any other, but rather with how these allow/deny rules are set up to let client operations affect the server directly.
Previously, both update and updateAsync could be used within collection.allow({ <here> }). This duplication added no value, as allow/deny rules only need a single validator for client operations, regardless of whether the operations are async or sync.
In 3.1.1 onwards, allow/deny validators are configured solely through insert, update, and remove options, which can include async validation logic. We’ve also made additional fixes in our revision of this feature, as happened on this PR: Tweaks on allow/deny rules by nachocodoner · Pull Request #13499 · meteor/meteor · GitHub
Community packages, like collection2, must stay updated with the latest standards. You can use METEOR_NO_DEPRECATION to ignore warnings, even with a regex to target only allow/deny ones. However, it’s good when seeing them to report these issues or fixes for these packages to address deprecations and prepare for breaking changes in future Meteor minor versions.