Run on mongoose 6 (replaces #70) #71

Merged

backmeupplz merged 2 commits from mongoose-6 into master

2026-10-22 19:17:45 +00:00

backmeupplz commented

2026-10-22 18:43:12 +00:00

(Migrated from github.com)

Dependabot's #70 (mongoose 5.7.0 → 6.13.10) plus the code change it needs. mongoose 6 throws "useCreateIndex" is not a valid option to set at startup, so #70 on its own would crash the bot on deploy.

Drop mongoose.set('useCreateIndex' / 'useFindAndModify') and the no-op useNewUrlParser / useUnifiedTopology connect flags
mongoose.set('strictQuery', false) keeps v5's query filtering (v6 would silently drop unknown filter fields)

Testing

I tested against the prod server version, MongoDB 3.6.23 (banofbot-db), on Node 22. The real app.js ran with a fake Telegram bot through this script: group created, /help, /language + language callbacks, /limit + lti, /time + tlti, /votekickWord, a keyword ban request, four votes (one repeat), the kick, an admin candidate, /lock and a locked non-admin command.

master (mongoose 5.7.0) and this branch make the same 43 bot calls with the same arguments
the stored chat settings and the request (starter, candidate, ban/no-ban voters) are the same
restarting Mongo under the running bot: v6 reconnects cleanly and keeps handling messages (v5 recovered too, after hundreds of disconnect/error cycles)

Deploy note

v5 stopped building indexes at the first error: the declared unique {id: 1} conflicts with the existing non-unique id_1. v6 carries on, so the first start builds three indexes the schemas already declare but prod never got: chats {type: 1, last_ban: -1}, chats {newcomers.0: 1} and users {first_name: 1, last_name: 1}. They're built with background: true, so on 3.6 they don't lock the collections.

🤖 Generated with Claude Code

Dependabot's #70 (mongoose 5.7.0 → 6.13.10) plus the code change it needs. mongoose 6 throws `"useCreateIndex" is not a valid option to set` at startup, so #70 on its own would crash the bot on deploy. - Drop `mongoose.set('useCreateIndex' / 'useFindAndModify')` and the no-op `useNewUrlParser` / `useUnifiedTopology` connect flags - `mongoose.set('strictQuery', false)` keeps v5's query filtering (v6 would silently drop unknown filter fields) ## Testing I tested against the prod server version, MongoDB 3.6.23 (`banofbot-db`), on Node 22. The real `app.js` ran with a fake Telegram bot through this script: group created, `/help`, `/language` + language callbacks, `/limit` + `lti`, `/time` + `tlti`, `/votekickWord`, a keyword ban request, four votes (one repeat), the kick, an admin candidate, `/lock` and a locked non-admin command. - master (mongoose 5.7.0) and this branch make the same 43 bot calls with the same arguments - the stored chat settings and the request (starter, candidate, ban/no-ban voters) are the same - restarting Mongo under the running bot: v6 reconnects cleanly and keeps handling messages (v5 recovered too, after hundreds of disconnect/error cycles) ## Deploy note v5 stopped building indexes at the first error: the declared unique `{id: 1}` conflicts with the existing non-unique `id_1`. v6 carries on, so the first start builds three indexes the schemas already declare but prod never got: chats `{type: 1, last_ban: -1}`, chats `{newcomers.0: 1}` and users `{first_name: 1, last_name: 1}`. They're built with `background: true`, so on 3.6 they don't lock the collections. 🤖 Generated with [Claude Code](https://claude.com/claude-code)