There are still some lingering issues that I am tracking down, but this is huge progress on the issues plaguing the dashboard since the 4.0.0 release.
Hopefully I can narrow down the rest of the major bugs that have popped up and get everything functioning correctly.
Google is returning a 400 code saying we are using a bad key. Hopefully by using the same methods that are already working elsewhere in the software (specifically the abstracted reactive wrappers I made), this should at least help narrow down where/what is causing the issue or outright solve the issue.
This marks a point where I realize I need to go through the API and make sure its more in line with how other parts of the program gets the same data.
I must have forgotten to update it because it and spring are no longer
getting along. Hopefully its fixed now.
Also changed the indents in the pom files to spaces to match our
guidelines
This should be the way to resolve the API rate limit with calendar
creation. By randomly assigning new guilds one of n amount of accounts,
we spread out the calendar creation load onto many accounts. This should
overall fix the API rate limit of calendar creation per account as well
as allow further expansion.
Notably, adding the announcement modifier option, which allows for
changing when the announcement would be posted relative to the event and
its other rules. Right now not supported on the front end at all, but
the backend is prepped for its support with the announcement posting
system soon to follow.
Okay, so its almost fully reactive. The API is still blocking as of
current. Everything else is reactive now:
- Command system
- All utility methods
- Event listeners
- Announcement Thread
- Google calendar auth
Added simple reactive wrappers for google calendar blocking calls
I have no idea if any of this works, but it *should* work. Time to test!
Massive changes to the bot and d4j required migrating to the latest
snapshot. So far everything seems to work well, but will be tested later
on this week. Hopefully this is one step closer to being able to deploy
this to production in order to make the bot more stable and responsive.
Completely rewrote our in-house logger so that its completely async.
Also designed the new logger so that we could pull it out of this
project and incorporated into our general utils library for all of our
other projects
Apparently several tables were setup with incorrect datatypes resulting
in mapping issues. This is now resolved with the migration scripts
converting the datatypes to the correct types.
This commit introduces the r2dbc api for all database handling to make
it fully reactive so future updates to make the bot fully reactive.
While most calls to the database are still blocking, this does use a
reactive driver for it so further work down the line will be able to use
the database reactively without much additional work.
These changes have not been tested, and will need to be tested
thoroughly as database use is the backbone for the bot's persistence
data scheme.
We have narrowed down where the slowdown starts and ends, however there
is still a lot of things happening between there, so therefore we are
checking what parts of those sections of the code are causing issues.
Its taking, on average, 10-15 seconds to handle this request. To combat
this, we are adding a bunch of debug statements to diagnose *where* the
slowdown is occurring. The next part of this debugging process is to
figure out *why* it is running slow, and how to speed it up to
acceptable speeds.
Messed out how to deploy to repos in the poms as I forgot how to do it,
this issue is now fixed and it will correctly go through the deploy goal
while only actually deploying core to the repos.
This is because they become out of range of JS's `number` type and cause
problems. So, by handling them as strings, and only strings withing the
API, this solves the issue and we should not run into precision issues
anymore.
NovaFox161