docs should check that category ids match the specified version

[Tankanow]

Background

• OS: Mac OSX 12.2.1
• rdme: 7.2.0

Symptom

Running rdme docs ./folder --key <key> --version <version> where the category ids in the YAML Front Matter Blocks are for a different version than the one specified on the command line returns a confusing error:

Error uploading <file path>:

We couldn't save this doc (Page slug must be unique.).

If you need help, email support@readme.io and include the following link to your API log: '<log url>'.

Expected Behavior

Instead of returning a "page slug must be unique" error, the rdme CLI should check the category ids in the Front Matter Blocks against those returned by the /categories API for the version specified to the rdme docs command and return a "category not found for this version" error.

Steps to Reproduce

1. Create README project with multiple versions and categories. Create a few documents in one of the categories.
2. Grab the category ids for one of the versions, use those in the YAML Front Matter Block
3. Run rdme docs ... --version <different version id> for a different version id then the one chosen in step (2).

Worst Case

Also, if as a user you take the error message at its word (as I did) and change the page slug to be unique, then you get a really bad outcome. The category id in the YAML Front Matter block wins out over the version specified on the command line and the rdme docs command will update the version associated with the category id. This is very unexpected and in my case updated the "stable" version of my docs, duplicating all of the documents with new slugs.

[kanadgupta]

Thanks for the detailed write-up @Tankanow! This is extremely helpful. This is an issue with our API, we just need to make some improvements to that error message. I'll keep this issue open to track our progress on fixing this.

[kanadgupta]

Update: we just shipped a new release of our API earlier today which includes a fix for this. Now if the slug, category and version don't match and the CLI attempts to make a PUT request, the API will respond with a 404, which will yield a much more relevant error message. Thanks again for writing in about this!