Bug:
The registered listeners remain in effect even after
the suite is completed; allowing other suites to trigger
the listeners.
Fix:
Perform clean-up before moving to next suite.
Feature:
This is the opposite action to `TelegramBot#onText()`.
It allows removing any previously-registered listeners.
It is similar to `TelegramBot#removeReplyListener()`.
Bug:
During polling, deleting the already-set webhook, caused
the `TelegramBotPolling#_getUpdates()` return an unexpected
value.
We expect the method to return an array (in the `.then()` clause).
However, deleting the webhook returns its value, which is an object,
from the method `_getUpdates()`.
Fix:
Simply retry the polling request and return the promise.
Notes:
Should we use recursion? I do not think so.
Why? The chances of getting the error (having a webhook set) AGAIN
is quite rare. And if it happens, there must be some problem with
different instances invoking polling and webhook simultaneously.
In that case, we wont struggle to recover from such a scenario.
User is on their own! Isht!
References:
* Bug report: https://github.com/yagop/node-telegram-bot-api/issues/284
* Reported by: @dcparga
Feature:
Polling and WebHook are mutually exclusive. Therefore, return an
error whenever the user tries to start polling, and the instance has
an open webhook, or user tries to open a webhook, and the instance
is already polling.
Feature:
The constructor option, 'filepath', allows us to remove
the TelegramBot's behaviour of allowing users to pass in
file-paths as arguments, as it involves some operations
that might be (are) strongly against what a programmer wishes
to achieve with the library.
Expect this to be documented better in the near future.
Implementation:
* Backwards compatible: The default behavior is not changed!
Feature:
The different mechanisms of fetching updates, i.e. polling
and webhook, have had their implementations improved:
* the TelegramBot instance needs to create the polling and
webhook instances once, and when necessary
* returning promises from TelegramBot#openWebHook() and
TelegramBot#startPolling() allows more precise control
Also,
* TelegramBot#initPolling() is being deprecated in favor of
TelegramBot#startPolling() to ensure consistency (as the
opposite action of TelegramBot#stopPolling())
Feature:
We shall allow passing more options to the HTTP server,
in `https.createServer()`.
We are using a new property, `https`, to avoid any namespace
collisions with our own options.
`options.key`, `options.cert` and `options.pfx` are convenient
options, in that they allow the user to provide paths to the
corresponding files, which are read automatically,
though synchronously!
Implementation:
* completely backwards-compatible
* all changes are being tested, except `options.pfx`
References:
* Pass `ca` prop to https.createServer(): https://github.com/yagop/node-telegram-bot-api/pull/17
Bug:
The library assumes signatures of methods to be, somewhat:
methodName(requiredParam1, requiredParam2, form = {})
where 'requiredParam1' ('requiredParam2', ..., 'requiredParamN')
are parameters that MUST be provided, and
'form' is an optional object allowing supplying any additional,
optional parameters that the Bot API allows.
This allows any new parameters added by Telegram to be
readily-supported by our library.
Also, the following have been included:
* Corresponding tests
* Documentation on the old, deprecated signatures
* Console-logging the deprecation notices
Feature:
Instead of guessing of a proper timeout, we shall use the error
response to calculate it. The error provides us with the number
of milliseconds we need to wait before retrying the request.
Feature:
Our tests are PASSING!
NOTE:
-----
Before running tests, provide the environment variable,
TEST_GAME_SHORT_NAME, whose value is the short name of a game
created for the test bot. It is used in testing methods for
games, such as TelegramBot#sendGame().
Bug:
The test for `TelegramBot#_formatSendData()` is only applicable on
newer versions of Node.js (v6+) that support passing a Buffer
representation of the path to `fs.createReadStream()`.
Fix:
If the runtime does NOT supports passing the Buffer argument, do
NOT run the test on it. This is safe since we are sure that
`fs.ReadStream.path` will never be a Buffer on the runtime being
tested.
Bug:
The (private) method TelegramBot#_formatSendData(), used by public
methods, such as TelegramBot#sendPhoto(), throws an error
if the stream passed (fs.readStream) has the property 'path',
being an instance of Buffer.
For example,
const stream = fs.createReadStream(Buffer.from('cat.png'));
bot.sendPhoto(chatId, stream);
Would throw an error, like
TypeError: Path must be a string. Received <Buffer 60 62 63 64>
This is because of this line:
src/telegram.js:297
fileName = URL.parse(path.basename(data.path)).pathname;
path.basename() can not handle buffer (non-string) paths. From the
docs, "A TypeError is thrown if path is not a string...".
Fix:
Ensure path.basename() receives a string, by converting the buffer
to string.
References:
* fs.ReadStream: https://nodejs.org/docs/latest/api/fs.html#fs_class_fs_readstream
- Adds support for callback_query-type messages
- Adds a showAlert option to answerCallbackQuery to more-closely align with the real bot API
- Adds tests for message editing functionality
- Adds a global test timeout of 10s and adds done() calls to all tests for assurance
- Adds support for callback_query-type messages
- Adds a showAlert option to answerCallbackQuery to more-closely align with the real bot API
- Adds tests for message editing functionality
- Adds a global test timeout of 10s and adds done() calls to all tests for assurance
Mohammed Sohail
GochoMugo
Fabio Zuber
Evgeny Bondarenko
Anton Mironov
Conor Fennell
Serhii Dmytruk
Devin Doolin
Iiro Jäppinen
Yago
AVVS