Always trigger jung bot help command by forward message. Would like to changing the command to junghelp

Handle ProvisionedThroughputExceededException during the spike. May retry after a period of time.

狼人谷 @hktgb 【無洗版都話Spam detected? 冗超聯admin入黎 @hkwerewolfgame 睇下】

Add back the existing feature.

https://serverless.com/framework/docs/providers/aws/events/http-api/

Possible solutions:

1. Similar to Facebook's API rate limit, Your app can make 200 calls per hour per user in aggregate. As an example, if your app has 100 users, this means that your app can make 20,000 calls. One user could make 19,000 of those calls and another could make 1,000, so this isn't a per-user limit. It's a per-app limit (Link)

Plugin: https://github.com/alexdebrie/serverless-dynamodb-backups

Sorry I’m new to GitHub but I’m here to report an issue of JungBot. It cannot automatically display top 10 jung people for my group at 18:00 since a few days ago while it works for other groups. I tried kicking and rebooting the bot but the problem still exists. Here is my telegram ID: @Sxiymloenm. Feel free to contact me. Thanks.

Add back the existing feature.

To run both the old and new services in parallel for a week. Once the new services have built up seven days of DB records, shut down the old service and switch over to the new service.

Due to telegram api message length limit. Adding logic for handle this case

automatic deployment on develop and master branch

Max items return per query is ~ 5k. Need a recursive feature to retrieve all items

Followup #1759

Currently, public methods of MessageController are coupled with mongoose dependent methods. It is desirable to extend the storage flexibility to make it easier to switch to or experiment with other data storage facilities or to quickly start the bot (by using sqlite3 or memory cache as the data storage) for a quick preview of the functionalities of the bot.

As discussed with @siutsin , one of a requirement related to this change is to allow certain operations (such as adding a message) to be executed on multiple data storage implementations.

new relic required customised handler for websockets

Currently, all tasks are done with onMessages. Should send to SQS and trigger another function.

This equivalent is to follow-up on #89. Currently, as there is no distinct equivalent in DynamoDB compare to MongoDB, we need to create another table to track the groups to prevent scanning millions of records.

EDIT: Increase the priority of this issue. For scan (offFromWork), it is not practical to scan 3m records to generated unique chatId. A separate table is required to retrieve all the groupIds.

Beyond the free tier, traces recorded cost $5 per 1 million traces recorded ($0.000005 per trace).

X-ray is getting pricy, should disable once the service is stable.

Able to set admin mode on, such that only admin is allowed to use top ten and all jung.

Unable to run OffFromWork with four days of production data, received dead letter notification from AWS.

The bot should not add a record if the previous message's sender in the same chat/group is the same as the incoming msg's sender.

• league table in 7 day
• message to indicate how many msg to catch up

- [ ] top shooter - 7 day privacy concern

- [ ] table - all time privacy concern

- [ ] top shooter - all time privacy concern

Great Bot.
can i customized the counting number announcement time? if no can you see if you can provide me a version where this customization is avaliable?
my TG: @chung2hk
Email: [email protected]

Ip range: https://core.telegram.org/bots/webhooks#the-short-version

Suggest to have user Id or link to user profile in the list instead of the name only, it is not easy to locate the user.

Throttle to 20 msg per mins takes way too long to send all the message, hence, hitting the 15 mins hard limit of lambda.

• Copy Prod DB to Dev
• Consolidate announcement with the body to reduce numbers of
• Test and see if telegram allows broadcast without throttling

Trying with the pay per request model, and generated quite some bills for DynamoDB.

Stats from 19 Apr 5 am to 21 Apr 2 am SGT (45 hours)

5,677 ReadRequestUnits (~126 requests per hour)
697,004 WriteRequestUnits (~15500 requests per hour)

DynamoDB On-Demand Capacity Pricing in us-east-1:
$0.25 per million read request units (N. Virginia)
$1.25 per million write request units (N. Virginia)

Forecast for one month:
Read Request: 126 * 24 * 30 = 90720
Write Request: 15500 * 24 * 30 = 11160000
Read Cost: $0.02
Write Cost: $13.95

Peak Table Read Capacity: < 2.5
Peak Index Read Capacity: < 4.5
Peak Table Write Capacity: < 9
Peak Index Write Capacity: < 9

DynamoDB Provisioned Capacity Pricing in us-east-1:
Write capacity unit (WCU) | $0.00065 per WCU
Read capacity unit (RCU) | $0.00013 per RCU

Forecast for one month:
RCU: ( 2.5 + 4.5 ) * 24 * 30 = 5040
WCU: ( 9 + 9 ) * 24 * 30 = 12960
RCU Cost: $0.66
Write Cost: $8.42

AWS Free tier comes with 25 WCUs and 25 RCUs of provisioned capacity:
The free tier should be enough to cover the usage for free. However, the data contains only around two days of data. It might significantly affect the RCU for the scan operation when the database grows into a full seven days of data.

/alljung list all members....
How to make nobody to use this command?
Thanks!

I am thinking to write a cache to support getJungMessage() i.e. getCount, getJung, addUsage.
I expect the cache can handle 1000+ groups and each has 1500 people and accumulating >1,000,000,000 messages. The cache is somehow independent on the number of messages, but dependent on number of members in a group (which has a very small limit). And thus, the query should be completed in <1ms, given enough storage and not so bad cpu and somewhere 1GB ram.

I would like to make an early note, because

1. this may overlap what you are working.
2. It is possible to retain the API, but would nearly complete rewrite message.js (not so much code).
3. The cache is specific, it may not be capable to be extended in future, in case there maybe other queries.

The cache can work with mongodb as backend, but if the above scenario is to be assumed, mongodb would need to be replaced, regardless of speed, it has already took way too many memory and storage for just 1,000,000 (at least the format need document need to be changed). And this is a larger amendment to be discussed. I would suggest lmdb/rocksdb as candidates.

For group managing, remove idle user