Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calender Creation Confirm #72

Closed
smnc opened this issue Oct 6, 2020 · 10 comments
Closed

Calender Creation Confirm #72

smnc opened this issue Oct 6, 2020 · 10 comments
Labels

Comments

@smnc
Copy link
Collaborator

smnc commented Oct 6, 2020

Who is the bug affecting?

Admins setting up the bot

What is affected by this bug?

The bot

When does this occur?

When creating a calendar

Where on the platform does it happen?

Calendar Creation Wizard

How do we replicate the issue?

Sporadic. Happens sometimes, other times not.
Calender fails to respond to !cal confirm

Expected behavior (i.e. solution)

Calender should be created

Other Comments

Possibly related to #67
Tickets #1811, #1814, #1824, #1826, #1827 all seem to be examples.

@smnc smnc added the bug label Oct 6, 2020
@smnc
Copy link
Collaborator Author

smnc commented Oct 7, 2020

Add #1830 to the list.

@smnc
Copy link
Collaborator Author

smnc commented Oct 7, 2020

Add #1832 to the list.

@smnc
Copy link
Collaborator Author

smnc commented Oct 8, 2020

Add #1835 too.

Looks like the problem might be shard 8. Still waiting for confirmation from ticke #1827, but the rest of the servers all appear to be shard 8.

@NovaFox161
Copy link
Member

Ever since pushing out a snapshot update that fixed issues with guild data saving, I haven't been able to replicate this issue nor have we gotten any recent reports since then of calendar creation failing.

I know neither of those issues are linked, but there were other minimal changes in those commits that are deployed that could have solved the issue...

@smnc
Copy link
Collaborator Author

smnc commented Oct 30, 2020

Looks like ticket 1883 might be a new case, and there was 1874 a few days ago too.

@smnc
Copy link
Collaborator Author

smnc commented Oct 30, 2020

List of servers I've tracked with the issue:
Ticket - Server ID - Shard
#1811 - 691016432711893063 - 8
#1814 - 758657222992855071 - 11
#1823 - 548741514424090634 - 8
#1824 - 757653868132827246 - 8
#1827 - 743950313874129078 - 11
#1832 - 556172336685121546 - 8
#1835 - 763504131616014386 - 8
#1837 - 763892824449220636 - 11
#1838 - 763914879114805249 - 3
#1839 - 277824132530438144 - 3
#1846 - 326575968858669057 - 14
#1853 - 699753735920025620 - 14
#1874 - 723239961901531166 - 6
#1883 - 453646581544255489 -11

@vanyamil
Copy link

Just got this bug. Shard 8 currently displaying about a Gb of RAM use above almost all other shards. Server ID 792426587445657610, is it on there?

@NovaFox161
Copy link
Member

Just got this bug. Shard 8 currently displaying about a Gb of RAM use above almost all other shards. Server ID 792426587445657610, is it on there?

No, that's on shard 6. Increased RAM usage doesn't always indicate an issue, could just mean increased usage on that one shard compared to others.

@vanyamil
Copy link

Got fixed now - the previous commands from an hour prior ran, supposedly creating the calendar twice. However, !cal review showed no calendar was recorded. Creating it again worked out well, with nearly no delay (no more than expected from API communication).

@NovaFox161
Copy link
Member

Considering this now resolved since all related code has since been rewritten and we have had no further reports in nearly a year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants