[BREAKING] Tasks Parity

Sherlouk commented 1 year ago

Closes #363 Closes #366 Closes #368 Closes #254

User/Client Facing

Introduces Cancel Tasks API
Introduces Delete Tasks API
Provides compiler-safe access to task types
- Utilising a future-proof solution avoiding errors should new task types be added without Swift support
Provides compiler-safe access to task result details
- Utilising a future-proof solution avoiding errors should new details be added without Swift support
Grouped task related models into own directory
Uses Date objects instead of String for dates within task models
Added missing fields to existing task models
Fixed error caused by global tasks
Uses compiler-safe types in task query to improve safety
Adds total to task results response (replacing https://github.com/meilisearch/meilisearch-swift/pull/412)
Removed all instances of try! (force try) to prevent crashes in test runner

Breaking Changes

⚠️ This is a breaking change. Even with something as simple as moving to a enum for TaskType requires changes to clients. This PR looks to bring all task changes together meaning that clients can upgrade to this new and safe API design in one go.

Task.Status has a new value .canceled (handle in any switch cases)
TaskType replaces a previous String based API (use .description to access String)
TasksQuery uses compiled types instead of String APIs (example: "indexUpdate" is now .indexUpdate)
enqueuedAt now uses Date instead of ISO-8601 String

Parity

Reviewing documentation available on MeiliSearch's website, this PR brings the Tasks API 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.

Sherlouk commented 1 year ago

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.

Sherlouk commented 1 year ago

The sole test which is failing is testDeleteAllDocuments - this is not failing due to changes made in this PR. I can reproduce it locally and is caused by an extra "test movie" sitting in the index. This is added by other integration tests, and so depending on the order in which the tests are ran can occasionally fail.