Basically we weren't sending the right data to prompt a 200 response
!!! the /badge/delete test is breaking previous tests idk why
Even though this test comes close to last it still manages to break
the tests that come before it. The problem may lie with the fact that
because its a much faster route by design that its e2e latency btfo's
the routes before it, allowing it to finish before they do.
This likely causes a race condition.
! Test bot is once again a massive disaster but at least it scales well /shrug
Should probably refactor test bot to be moar straight forward or something idk
+ Also adding some spacing eye candy to make sure we can read things easily
The cases that actually matter should be covered now so I'm confident with this
endpoint's behavior
! A preliminary db::neighbors::get is done to cover the 404 case
Basically if a bad url is used in the request we should 404 the update as there
won't be anything relevant to update
This also "fixes" the /neighbor/update route conveniently enough, which had much
better behavior than expected before.
- Remvoing some fluff from debugging
! put /neighbor/update is failing due to a failure to parse the body correctly on thebackend
Further investigation is required
+ Kinda minor but I'm also adding the ability to `put` things now
+ Also an if statement to avoid failing on checkf for NoneType responses
Opting now for config.json files as they better interoperability between node and rust
+ Hardcoding some variables into build-db.sh
This really shouldn't be an issue however
+ using cat to dump out what table structures are being setup due to strange bugs in pipeline
These are baseline tests however a new /neighbor/remove & /neighbor/edit route should be edited before I call this done on the roadmap.
Also some more intense testing around these current routes is required.
Mostly because the expectation that JSON is being sent to us in /neighbor/add
It could be worth the effort to send this data as json in the body
! Currently parameters are sent via the query string is in line with how most routes behave
For this route is just feels weird dealing with al the issues with json in the query string
+ More error handling in case shit goes wrong
Basically handling more cases where some initial test could result in the whole
script exiting with code(1)
Not really that big of a deal since most tests after _that_ point will fail anyway
but the fix has revealed issues in the auth code magically so I'm keeping up with the new idea
that initial tests should have every resultant case validated to avoid weird behavior
> good code results in good results
who would have guessed
+ Adding some more invite status checks
+ Adding a verbose invite usage check for sanity reasons
- Removing run-api-tests script as it now goes into the /scripts/ directory
+ Adding the wss-hmac setup from the command line arg
It was literally just 1 if statement that I forgot to write in
+ Moving tests to the new client
- Removing web/ module
! Currently all tests are passing 17/17 but the real trickery comes with doing this
on CI which should will likely take some magic somewhere
Or we'll just extend the freechat docker image to finally have all the required
dependancies and just test on that with diesel and what not
Problem: the old test suite was extremely inflexible
This meant that making new tests took way too much time.
+ This new rework makes the new client's backend much thinner and less "magical"
With less magic going on we can pass way more data more easily to the actual
http-request engine making the convenience wrapper over top it much more flexible
Translating old tests to the new engine might take a while but for now the old
client codebase is completely deprecated and will no longer be used+updated
➕ Moving Messages struct in db-lib to root for less namespacing uglyness
➖ Removing an whole unused trait
✨ Message::get_time_range now returns a special 'UserMessage' struct that includes the name of the author
❗ More code must be removed from db-lib since a ton of the trait methods aren't used anymore
* payloads for things like /message/send are now send through the request body
* no longer sending body data in gets
This whole patch is basically so we can allow js clients to exist btw -_-
