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.
This makes the parameter follow the naming convention of badge_*
* badges.id field now uses BIGINT's as intended
* Typo in sql where 'badges' was incorrectly set to 'perms' -_-
! 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
It should be noted that /badge/update needs some more planning so 1 more commit
is justified for it as some consideration must be taken for how individual badge
permissions are going to be handled
The badges_id field has proved to bubble up some issues with updating deep structures
Basically this just means that feature branches for deep features like this are a good idea
! Issue: RTC feature flag was working fine but without the feature flag `Row`'s had no pickup
This meant correct responses were slipping into previously unreachable sections of code
With this frontend points now return proper data structures which of course contain
badge_id vectors
Along with defaulting to '[]' strings in mysql configuration serde_json calls
now fallback to .unwrap_or(Vec::new()) for cheapish callbacks.
These fallback calls are cheap because Vec::new doesn't allocate anything on the heap
because they're empty.
+ Adding some default empty list values where applicable
neighbors now has a default value of '[]' to enforce the "empty list" constraint on that field
Issue seemed to be that artifacts were not being preserved properly.
This was causing failures in test stages where it was basicallly impossible to debug
"real" issues
- Removing artifacting (json-api) for now
They'll be re-added when there's a good way of verifying the quality of builds.
For now they're gone because the mock test stage is doing a lot of work already
+ mock-test job now builds json-api
This fixes the first issue this patches intends on fixing however it's kinda
cheesy and should probably be replaced at some point with a better fix
This patch has not yet been tested but will be in the coming patches
Sumamary: we're just doing a regular delete on the neighbor's table based off
the url field
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
! This route needs way more testing as its currently failing the prelim test listed right now
! Some more misc changes in testing/mod.rs that aren't imporant at all to anyone
It's just an extra comment
This chage is basically required due to the ridiculuous number of parameters that needed to be passed.
Also more POC for showing how serde_json's result type can be used to safely parse http bodies
* add_neighbor now takes a moved Neighbor param instead of the fields individually
This should make it a easier for both front & backend to parse what's happening.
It also let's us leveraege serde_json a bit more
! 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
diesel still requires this however the --database-url flag is there to alleviate this issue
+ make test now cleans up fake png images from the cwd
This is more for comfort reall
unwrap had a chance to panic where as the unwrap_or now defaults to an empty
Bytes object which lets the code after it fail with an HTTP 400. This is preferrable
to a 500 error as there really is no error, just bad/unpollable input from the
end user.
It should be noted at this point we're considering url's as the "primary key"
even though its kinda weird to use them that way.
Even though a varchar primary key doesn't really scale well I'm considering it
fine for now as the neighbors table is controlled by admins(by hand) and hopefully
won't need to scale.
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
