# Fix Phrase API job abort on translation memory mismatch

## TL;DR

The job aborted because the TM leverage settings do not match what the job expects, so align the TM used at analysis with the one used at job creation. Re-run the analysis step against the same TM, then recreate the job. The mismatch usually comes from analyzing with one TM and creating the job with another.

## The error

```text
Phrase API: job aborted, translation memory mismatch
POST /v2/projects/{id}/jobs returns 422 after analysis with a different TM
```

## Fix it

### Step 1: Check which TM the analysis used

```bash
curl -s -H "your auth header https://api.phrase.com/v2/projects/$PHRASE_PROJECT/analyses | head -c 300
```

Expected: You see the TM attached to the analysis.

### Step 2: Check which TM the job creation sends

```bash
grep -n "translation_memory" scripts/phrase-job.js | head -5
```

Expected: You see the TM id in the job payload.

### Step 3: Re-run analysis with the same TM the job will use

```bash
node -e "console.log('create the analysis explicitly with the job TM id, then create the job from that analysis')"
```

Expected: Analysis and job reference the same TM.

### Step 4: Recreate the job

```bash
node scripts/phrase-job.js | tail -3
```

Expected: The job creates without the mismatch abort.

## When to use this

- Phrase job creation aborts with a translation memory mismatch
- You run analysis and job creation as separate API steps

## When NOT to use this

- The job creates but leverage numbers look wrong, check the TM content
- The error is about the glossary, that is a separate setting

## Tool and version compatibility

- Phrase Strings API v2, jobs and analyses endpoints
- Translation memory scoped per project

## Variant phrasings

### mismatch after TM was updated

Re-run the analysis. The job holds a snapshot of the old TM state.

### no TM intended at all

Omit the TM from both calls. A TM on one side and none on the other also mismatches.

## Why it happens

Phrase validates that the TM behind the word-count analysis is the TM the job will translate against. If they differ, the leverage numbers would lie, so the API aborts the job instead of creating it.

## Edge cases

- TM updates during a long analysis also mismatch, freeze the TM first
- Multiple TMs attach in priority order, keep the order identical in both calls
- The 422 body names the mismatched field, read it before changing things

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CI_7bR7P23wZjacHi4hFzQ