feat: add protection against missing allowed_updates #422
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #422 +/- ##
==========================================
- Coverage 41.35% 38.72% -2.63%
==========================================
Files 16 16
Lines 5035 4862 -173
Branches 204 194 -10
==========================================
- Hits 2082 1883 -199
- Misses 2951 2977 +26
Partials 2 2
☔ View full report in Codecov by Sentry. |
|
I never ran this code … I'll test it some more before merging |
|
Yes, in the getting started guide. |
|
I haven’t seen that for years. Is it anchor-able? |
|
No, but it is screenshottable:
|
|
Okay I won’t believe my eyes again |
|
Believe Ctrl+F and other hacking skillz |
|
Works well actually. Will be much more useful if #424 gets merged. |
| const debugErr = d("grammy:error"); | ||
|
|
||
| export const DEFAULT_UPDATE_TYPES = [ |
There was a problem hiding this comment.
All update types appear to be available in filter.ts as UPDATE_KEYS already. Should we prefer to do
export const ALL_UPDATE_TYPES = Object.keys(UPDATE_KEYS);
export const DEFAULT_UPDATE_TYPES = ALL_UPDATE_TYPES.filter(u => u !== 'chat_member');To keep a single source of truth for update types in grammY's source?
There was a problem hiding this comment.
I considered this, but they're semantically unrelated because the supported filter queries need not be the same as the Bot API specs. That's why I didn't follow DRY.
There was a problem hiding this comment.
Is it completely semantically unrelated, or perhaps just that it is a superset of Bot API specs? I'd presume you always want to support update types from Bot API specs, but want room to also conjure L1s of your own.
If so, we can probably do TG_UPDATE_KEYS and CUSTOM_UPDATE_KEYS (if and when it is needed); where filter.ts exports the former, and filters on the set union of the above?
There was a problem hiding this comment.
Is it completely semantically unrelated
Yes. I don't want to mix those two things. One is a mirror of the specs, and the other is the base for filter query validation. We don't know if we want to have filter queries for all fields in updates, or if we will have excessive queries that are not found in updates (shortcuts that aren't computed perhaps).
People often forget to specify some updates which they listen for. This PQ fixes that by logging a warning in debug mode in such cases.
Closes #107.