feat: add tg-time tag support to HTML stream parser#60
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a35c1e3db6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const unixAttr = workingTag.attrs.get("unix"); | ||
| if (!unixAttr || isNaN(parseInt(unixAttr, 10))) { | ||
| return false; |
There was a problem hiding this comment.
Treating unix as valid when parseInt can read only a numeric prefix causes malformed <tg-time> tags (for example unix="1773412200abc" or unix="1e6") to be accepted and converted into a different timestamp instead of remaining literal text like other invalid tags. This silently changes user input and emits incorrect date_time entities; validate that the whole attribute is an integer string before parsing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e4c09947a9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const formatAttr = openTag.attrs.get("format"); | ||
| const date_time_format = (formatAttr ?? | ||
| "") as MessageEntity.DateTimeMessageEntity["date_time_format"]; |
There was a problem hiding this comment.
tg-time currently copies any format attribute directly into date_time_format, but Telegram requires this string to match the date-time grammar (r|w?[dD]?[tT]?, with empty allowed). Inputs like <tg-time unix="1647531900" format="yyyy-MM-dd">…</tg-time> are therefore converted into a date_time entity that the Bot API can reject at send time, instead of being treated as invalid markup like other malformed tags.
Useful? React with 👍 / 👎.
| if (!unixAttr || !/^-?\d+$/.test(unixAttr)) { | ||
| return undefined; | ||
| } | ||
| const unixTime = parseInt(unixAttr, 10); |
There was a problem hiding this comment.
The numeric check accepts arbitrarily long digit strings, and parseInt can produce non-finite values (Infinity) for very large inputs. That yields unix_time: Infinity in the entity (which serializes to null in JSON), causing malformed outbound payloads instead of preserving the original tag text as invalid input.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5917d0bc34
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const unixTime = parseInt(unixAttr, 10); | ||
| if (!Number.isFinite(unixTime)) { | ||
| return false; |
There was a problem hiding this comment.
The current validation only checks Number.isFinite(parseInt(unixAttr, 10)), which still accepts integers outside JavaScript’s safe integer range. For inputs like unix="9007199254740993", parseInt produces a rounded value (9007199254740992), so the parser silently emits a date_time entity with the wrong timestamp instead of preserving the original markup as invalid text. This can corrupt user-provided dates for large unix values; add a safe-integer/range check before accepting the tag.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This is technically true. But given that raw entity tag implementation also suffers from the same precision issue, we can allow this for now for feature parity.
1 participant
No description provided.