Closed smolleyes closed 1 year ago
Is there something more in the log?
hi,
not just this
if i increase verbosityLevel on tdl i have too much messages :p
verbosity 3 :
eth-sniper-bun-1 | [ 3][t 6][1699368708.676340103][Td.cpp:2604][#2][!MultiTd] Create Td with layer 164, database version 14 and version 48 on 4 threads
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 6][1699368708.676357746][Td.cpp:4104][#2][!Td][&td_requests] Sending update: updateOption {
2023-11-07 15:51:48 eth-sniper-bun-1 | name = "version"
2023-11-07 15:51:48 eth-sniper-bun-1 | value = optionValueString {
2023-11-07 15:51:48 eth-sniper-bun-1 | value = "1.8.19"
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 6][1699368708.676388025][Td.cpp:4104][#2][!Td][&td_requests] Sending update: updateOption {
2023-11-07 15:51:48 eth-sniper-bun-1 | name = "commit_hash"
2023-11-07 15:51:48 eth-sniper-bun-1 | value = optionValueString {
2023-11-07 15:51:48 eth-sniper-bun-1 | value = "2589c3fd46925f5d57e4ec79233cd1bd0f5d0c09"
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 6][1699368708.676392078][Td.cpp:4104][#2][!Td][&td_requests] Sending update: updateAuthorizationState {
2023-11-07 15:51:48 eth-sniper-bun-1 | authorization_state = authorizationStateWaitTdlibParameters {
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 0][1699368708.676401615][Client.cpp:293][&td_requests] End to wait for updates, returning object 0 0x150bcc001b60
2023-11-07 15:51:48 eth-sniper-bun-1 | 133 | this._innerDefer.reject(error);
2023-11-07 15:51:48 eth-sniper-bun-1 | 134 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | 135 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | 136 | class TdlError extends Error {
2023-11-07 15:51:48 eth-sniper-bun-1 | 137 | constructor(err, msg) {
2023-11-07 15:51:48 eth-sniper-bun-1 | 138 | super(msg);
2023-11-07 15:51:48 eth-sniper-bun-1 | ^
2023-11-07 15:51:48 eth-sniper-bun-1 | error: Error
2023-11-07 15:51:48 eth-sniper-bun-1 | at new TdlError (/app/backend/node_modules/tdl/dist/client.js:138:4)
2023-11-07 15:51:48 eth-sniper-bun-1 | at /app/backend/node_modules/tdl/dist/client.js:227:63
2023-11-07 15:51:48 eth-sniper-bun-1 | at processTicksAndRejections (:55:76)
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 1][1699368708.679566621][ConcurrentBinlog.cpp:25][#1][!Binlog /app/backend/_td_database/td.binlog] Finished to close binlog
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 4][1699368708.679640531][SqliteConnectionSafe.cpp:39] Close SQLite database [path:/app/backend/_td_database/db.sqlite]
2023-11-07 15:51:48 eth-sniper-bun-1 | [ 3][t 4][1699368708.687242507][Td.cpp:4104][#1][!Td][&td_requests] Sending update: updateAuthorizationState {
2023-11-07 15:51:48 eth-sniper-bun-1 | authorization_state = authorizationStateClosed {
2023-11-07 15:51:48 eth-sniper-bun-1 | }
2023-11-07 15:51:48 eth-sniper-bun-1 | }
seems he doesnt like when i have one channel sending a looot of messages... if i exit from this group i don t see it crash (i think... need time to confirm)
If you're using bun instead of Node.js, it looks like it doesn't print additional properties of the Error
instances and so you can't see the actual error. Perhaps in the error
handler, you can also print the .err
property, like this: client.on('error', e => console.error(e, e?.err))
. Or you can also try to switch to node.js to see if the problem persists.
will try and let you know, i can t switch to node so easily unfortunately... :/
got more infos with your log code:
| Got error: 133 | this._innerDefer.reject(error);
2023-11-07 21:50:37 eth-sniper-bun-1 | 134 | }
2023-11-07 21:50:37 eth-sniper-bun-1 | 135 | }
2023-11-07 21:50:37 eth-sniper-bun-1 | 136 | class TdlError extends Error {
2023-11-07 21:50:37 eth-sniper-bun-1 | 137 | constructor(err, msg) {
2023-11-07 21:50:37 eth-sniper-bun-1 | 138 | super(msg);
2023-11-07 21:50:37 eth-sniper-bun-1 | ^
2023-11-07 21:50:37 eth-sniper-bun-1 | error: Error
2023-11-07 21:50:37 eth-sniper-bun-1 | at new TdlError (/app/backend/node_modules/tdl/dist/client.js:138:4)
2023-11-07 21:50:37 eth-sniper-bun-1 | at /app/backend/node_modules/tdl/dist/client.js:227:63
2023-11-07 21:50:37 eth-sniper-bun-1 | at processTicksAndRejections (:55:76)
2023-11-07 21:50:37 eth-sniper-bun-1 | 36 | },
2023-11-07 21:50:37 eth-sniper-bun-1 | 37 | send(client, request) {
2023-11-07 21:50:37 eth-sniper-bun-1 | 38 | tdjson.send(client, JSON.stringify(request));
2023-11-07 21:50:37 eth-sniper-bun-1 | 39 | },
2023-11-07 21:50:37 eth-sniper-bun-1 | 40 | async receive(client) {
2023-11-07 21:50:37 eth-sniper-bun-1 | 41 | const response = await tdjson.receive(client);
2023-11-07 21:50:37 eth-sniper-bun-1 | ^
2023-11-07 21:50:37 eth-sniper-bun-1 | error: receive is not finished yet
I think the N-API compatibility in bun is probably not totally correct which leads to a race condition (though not a data race), the JSC vs V8 differences could also be showing.
Also, are you creating multiple clients?
I published tdl@7.4.1-beta.0
with a potential fix (can be installed via npm install tdl@beta
).
hi, no i don t use multiple clients, will try the fix, thanks a lot for the suppport !
installed an running, i ll let you know
seems stable ! good, will let it run longer :)
hi!
worked all night long no crash at all, all right.
I close the issue , thanks a lot !
have a nice day :)
@Bannerets, when can we expect this fix to be included in a stable release?
I've encountered a similar issue in version 7.4.0 using prebuilt binaries version 1.8.23. This occurs when operating a single client with Node.js 20, where I exclusively use async/await calls. Here's the stack trace for reference:
Object.receive (c:\Dev\My\tdlib-sample\node_modules\tdl\dist\client.js:41)
Client._loop (c:\Dev\My\tdlib-sample\node_modules\tdl\dist\client.js:459)
await (Unknown Source:0)
Client (c:\Dev\My\tdlib-sample\node_modules\tdl\dist\client.js:227)
createClient (c:\Dev\My\tdlib-sample\node_modules\tdl\dist\index.js:167)
After encountering this error, the client becomes unresponsive to any subsequent requests, and attempts to close it are unsuccessful.
After upgrading to version 7.4.1-beta.0
, the previously reported issue has been resolved.
Yes, sorry, this should've been done earlier. I just published tdl@7.4.1
.
hi
i randomly got this error after few minutes on my bot:
Got error: 133 | this._innerDefer.reject(error); 134 | } 135 | } 136 | class TdlError extends Error { 137 | constructor(err, msg) { 138 | super(msg); ^ error: Error at new TdlError (/app/backend/node_modules/tdl/dist/client.js:138:4) at /app/backend/node_modules/tdl/dist/client.js:227:63 at processTicksAndRejections (:55:76)
how can i debug it a bit more ? once i have this error bot don t parse new message received in update event, how can i "restart" the bot ?
ps: is it possible to only update the database with message from a list of selected chat_id ?
thanks a lot !