[BREAKING] Tasks Parity #425
Conversation
|
There is likely to be some code samples which I need to update/add as part of this PR too (relating partially to #424) This will also need a rebase too. However, I'd love a review once time permits as I do not plan on making any further changes to the API unless called upon to. |
No functionality change, just an improvement to tests to prevent the test runner from crashing (and less complaints from SwiftLint)
Sometimes it would fail stating the task was still there, I believe this was because it hadn't finished deleting. Hopefully it'll now wait. Passed 50 iterations locally.
Sherlouk
force-pushed
the
36X-task-parity
branch
from
cff33b7
to
41d7976
Compare
Sherlouk
force-pushed
the
36X-task-parity
branch
from
dc3d6fc
to
f10885c
Compare
|
The sole test which is failing is |
|
bors try |
| @@ -133,7 +133,7 @@ async_guide_filter_by_ids_1: |- | |||
| } | |||
| } | |||
| async_guide_filter_by_statuses_1: |- | |||
| client.getTasks(params: TasksQuery(statuses: ["failed", "canceled"])) { result in | |||
| client.getTasks(params: TasksQuery(statuses: [.failed, .canceled])) { result in | |||
There was a problem hiding this comment.
Is this PR breaking so?
Not an issue for me to break, we are not stable yet. It's to apply the right versioning and provide a clear changelog
There was a problem hiding this comment.
This is a breaking change, yes. The changes have been documented in the initial PR description, in case you want to copy them into a changelog 😀
There was a problem hiding this comment.
For what it's worth, and looking at tickets in the backlog, I'm intentionally looking to prioritise breaking changes now in order to get us to a stable position quicker.
There was a problem hiding this comment.
Ok let's merge it with breaking then! thank you for the help of the changelog ❤️
tryBuild failed: |
Other solutions include: - fetching all documents and asserting total count - deleting all documents before adding again (expect 8) - create a new index just for this one test
Sherlouk
force-pushed
the
36X-task-parity
branch
from
9e55019
to
4bcee63
Compare
curquiza
added
breaking-change
|
Build succeeded:
|
Closes #363
Closes #366
Closes #368
Closes #254
User/Client Facing
Dateobjects instead ofStringfor dates within task modelstotalto task results response (replacing Addtotalto TasksResult #412)try!(force try) to prevent crashes in test runnerBreaking Changes
Task.Statushas a new value.canceled(handle in anyswitchcases)TaskTypereplaces a previous String based API (use.descriptionto access String)TasksQueryuses compiled types instead of String APIs (example:"indexUpdate"is now.indexUpdate)enqueuedAtnow uses Date instead of ISO-8601 StringParity
Reviewing documentation available on MeiliSearch's website, this PR brings the
TasksAPI up to 100% parity with existing features. It resolves many errors caused by the previous design (both architecturally but also instability in the current release), and provides future-proofness against further scope within the tasks API.Personal
As I am developing my own Swift based application for monitoring MeiliSearch (and it's tasks), this branch has been extremely helpful for me in exploring jobs and being able to cancel them and performing my own housekeeping.
The type safety has been delightful and actually detected a bug in my original implementation which had a typo in a task name.