Fixes WB-NNNN
Fixes #NNNN

Description

What does the PR do?

For context, we added the latest history step to the mutation that creates an artifact. This change was put in less than a month ago in the backend. The corresponding SDK PR was merged at the same time.

A Local user reported the following error when they switched to SDK versions 0.12.12 or 0.12.13. They stated that the error did not happen with 0.12.11:

ValueError: error logging artifact "{user-specific data}": {'message': 'Argument "input" has invalid value {artifactTypeName: $artifactTypeName, artifactCollectionNames: $artifactCollectionNames, entityName: $entityName, projectName: $projectName, ru
nName: $runName, description: $description, digest: $digest, digestAlgorithm: MANIFEST_MD5, labels: $labels, aliases: $aliases, metadata: $metadata, historyStep: $historyStep}.\nIn field "historyStep": Unknown field.', 'locations': [{'line': 2, 'column': 25}]}

This PR adds max_cli_version guardrails (0.12.12) for when history step was introduced in the SDK. Basically, it grabs the max_cli_version that the backend (either cloud or local) knows about and makes sure that we only include the history step info into the gql query if this max_cli_version >= 0.12.12.

We tested the following script against a version of local that is 2 months old:

import wandb

def run_experiment():
    with wandb.init() as run:
        table = wandb.Table(columns=["boom_col"])
        table.add_data(5)
        wandb.log({"data": 5})
        wandb.log({"data": 10})
        wandb.log({"table": table})

if __name__ == "__main__":
    run_experiment()

Initially, we hard-coded can_handle_history to be True, in order to trigger the GraphQL query with the added history step and error out (since a 2-month old version of local wouldn't have history in the schema). The gql query fails (as it should) and the artifact is not logged. However, the run finishes successfully (and fails silently without alerting the user, which is a separate issue).

With the guardrail, can_handle_history becomes false and the artifact is logged successfully.

Testing

This is a hotfix, in response to an issue that Local users would be experiencing.
It was tested manually against an old local release, as stated above.
In the future, we need to figure out a way to test this with unit tests, and also with regression tests against the last 5 (or other number) versions of local.

This PR adds a standalone test that is meant to be tested against local versions (and verify that the guardrail does indeed work and successfully logs an artifact).

Checklist

• Name PR "[WB-NNNN][WB-MMMM] Add support for..." similar to entries in CHANGELOG.md
• Include reference to internal ticket "Fixes WB-NNNN" (and github issue "Fixes #NNNN" if applicable)