pytestomatio sync resets self_tags and overwrites custom test titles on every run

[DL-lv-qa]

Environment
pytestomatio 2.13.0b0
Python 3.14, pytest
Windows 11, ~300 synced tests in the project

Summary
Every time pytest --testomatio sync runs (/api/load endpoint), for every test the plugin matches to a @pytest.mark.testomatio("@t...") marker in code:

self_tags is reset to [] (except tags covered by TESTOMATIO_TAG_MARKERS, if configured for that marker).
The test's title is silently overwritten with an auto-generated title derived from the Python test function name, with a ${browser_name} placeholder appended (pytest-playwright browser fixture parametrization).
Tags and titles set independently via the Testomat.io API or UI are treated as disposable by the sync, even though they were never part of the sync payload's intent.

Steps to Reproduce
In Testomat.io, set a custom, human-written title and add one or more custom tags on a test that has a corresponding @pytest.mark.testomatio("@t") marker in the pytest suite, e.g.:

PATCH /api/v2/{project}/tests/{id}
{ "title": "Verify X happens when Y", "link": [{"action":"add","type":"tag","value":"my-custom-tag"}] }
Confirm via GET /api/v2/{project}/tests/{id} — title and self_tags reflect the custom values.
Run pytest tests/ --testomatio sync --no-empty (with TESTOMATIO_TAG_MARKERS set to markers that do not include my-custom-tag, e.g. TESTOMATIO_TAG_MARKERS=e2e,no_parallel).
Fetch the same test again via GET /api/v2/{project}/tests/{id}.

Actual Behavior
Before sync:

{
  "title": "Verify X happens when Y @my-custom-tag @another-tag",
  "self_tags": ["my-custom-tag", "another-tag"],
  "code": null
}

After pytest tests/ --testomatio sync --no-empty:

{
  "title": "X happens when y ${browser_name}",
  "self_tags": [],
  "code": "    @pytest.mark.testomatio(\"@T<id>\")\n    def test_x_happens_when_y(...):\n        ...\n"
}

(code becoming populated confirms the plugin matched/processed this test in this run.) This is not limited to newly-touched tests — a single sync run resets self_tags for every matched test in the project, not just ones whose code changed.

Expected Behavior
/api/load should only sync code-derived structural fields (file path, class/function name via the marker). It should not overwrite title or self_tags set independently through the API/UI when they're absent from the sync payload.

Secondary issue: propagation delay
Immediately after the sync command finished, a GET on the affected test still returned the pre-sync values (old title, old tags, code: null). A GET issued again shortly after returned the fully updated values. Suggests an async/indexing lag between the sync write and it becoming consistently readable — worth noting for anyone scripting a read-immediately-after-sync check.

Current Workaround
We maintain a script that re-applies specific tags after every sync by scanning test files for a known pytest marker and re-PATCHing those tags via the API. This only covers tags backed by an actual pytest marker (via TESTOMATIO_TAG_MARKERS). Any tag or title set purely through the API/UI — with no corresponding pytest marker — has no recovery path and is lost on every sync. At ~300 synced tests this makes sync a lossy operation for most tagging/title metadata.

Suggested Fix
(a) Omit tags/title from the /api/load payload unless the plugin is explicitly configured to manage them, so the backend leaves existing values untouched, or
(b) Merge/preserve existing self_tags/title server-side rather than overwriting when the incoming payload doesn't explicitly specify them.

[AenEnlil]

@DL-lv-qa Hello! This is expected, not a bug. For automated tests, title (and any @tag in it) is code-derived. On each sync the incoming title is authoritative, so self_tags gets recalculated from it every run. If you want to keep them, add the tags you've set in Testomat.io directly to your local code via the testomatio_tags marker (e.g. @pytest.mark.testomatio_tags("my-custom-tag", "another-tag")), so they become part of the code and survive every future sync.

Also, If you need metadata that's managed purely via API/UI and must survive re-sync, use Labels instead of Tags. Import only ever adds labels when present in the payload; it never clears or resets existing ones

[DL-lv-qa]

@DL-lv-qa Hello! This is expected, not a bug. For automated tests, title (and any @tag in it) is code-derived. On each sync the incoming title is authoritative, so self_tags gets recalculated from it every run. If you want to keep them, add the tags you've set in Testomat.io directly to your local code via the testomatio_tags marker (e.g. @pytest.mark.testomatio_tags("my-custom-tag", "another-tag")), so they become part of the code and survive every future sync.

Also, If you need metadata that's managed purely via API/UI and must survive re-sync, use Labels instead of Tags. Import only ever adds labels when present in the payload; it never clears or resets existing ones

Thanks for the clarification — the "title/tags are code-derived, so self_tags gets recalculated every sync" explanation makes sense, and the testomatio_tags marker / Labels guidance resolves that part for us.

One thing I wanted to follow up on separately, since it wasn't covered by that explanation: a downstream consequence of the unresolved ${browser_name} placeholder in the master record's title.

Repro (confirmed on a real test):

1. A manual test case exists in Testomat.io with a human-written title, e.g. "Verify X happens when Y".
2. It gets automated: a test is added with @pytest.mark.testomatio("@T<id>") linking to that same test, e.g. def test_x_happens_when_y(self, page: Page): ... — the test uses page/context/browser (no explicit @pytest.mark.parametrize anywhere in the test itself, browser_name only comes in implicitly via the fixture chain).
3. After --testomatio sync, the master record's title is overwritten to the code-derived form, including the unresolved browser_name param:

   X happens when y ${browser_name}
   

4. Some time later, a CI test run executes this test. The execution/report title resolves the placeholder to the real value (e.g. chromium), so the reported result is keyed to something like "X happens when y chromium" — a different string from both the current master title (step 3) and the original pre-automation title (step 1).

Observed effect: filtering a Test Run report by a keyword from this test surfaces two rows for the same test_id:

• 🟠 "Verify X happens when Y" (the original, pre-automation title) — status Skipped, since no execution ever got matched to this exact string
• 🟢 "X happens when y…" (current code-derived title, chromium-resolved or with ${browser_name} depending on where in the pipeline the title is read) — status Passed/Failed, the real result

Both rows point at the same underlying test — confirmed via the Tests API, there's only one test record (self_tags: [], state: automated, one id), yet the Test Run UI displays it twice because the run report matches by title string rather than test_id, and title has drifted three times (manual → sync → execution).

This isn't just a cosmetic title issue — it reads as a duplicate/ghost test in the run report, which is confusing when reviewing CI results at any scale, especially right after a test gets automated.

Is this a known/expected side effect of the title-templating design, or is it a separate matching bug — e.g. should run-report matching key off test_id (already present via the @pytest.mark.testomatio("@T<id>") marker) instead of, or in addition to, the title string?