[Bug] Several commands return results that automation cannot consume

Abierto
  • ¿Algo no está bien?
#66 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, shell
Área
cli, operating-systems

Línea de trabajo

Start by tracing the fs-git and fs commands named in the report, then consult ti-cli-reference.md and the recorded ~/.ti/logs/ti.jsonl exit data. Reproduce the JSON, status, exit-code, and macOS WebDAV unmount observations separately. Done means the five behaviors are fixed or their intended contracts are explicitly confirmed and documented.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

ti version

0.2.7 (6c950c77a601d0d55394c4b2f64483ae93d522db, 2026-09-27), bundled ti-drive9 companion 60b63d6

Command family

fs-git

Operating system and architecture

Ubuntu, linux/amd64, for the git workspace commands. macOS 14.6, darwin/arm64, for the rest.

Problems 1 and 2 are fs-git. Problems 3 and 4 are fs. Problem 5 is a mount concern. The
dropdown takes one value, so this is filed under fs-git.

Summary

Five problems that share one consequence. A script cannot learn the outcome of a command from
its result, so it has to parse human-readable text or guess.

Covers observations 1, 6, 3, 12, and 5 from a review of the TiDB Cloud Filesystem
documentation.

Problem 1: clone-git-workspace and add-git-worktree return empty JSON

Command
ti fs-git clone-git-workspace --mount-path <mounted-path> --repo-url <repo-url>
ti fs-git add-git-worktree --mount-path <mounted-path> --branch <branch>
Reproduction steps
  1. Run ti fs-git clone-git-workspace against a mounted file system path.
  2. Capture stdout and parse it.
  3. Repeat with ti fs-git add-git-worktree.
Expected behavior

The result identifies what was created, so the next command can use it.

Actual behavior

Every field in the JSON is an empty string, tree_entries is 0, and timestamps are
zero values. The real workspace ID appears only on stderr. An automated caller cannot capture
what it just created without scraping stderr.

Problem 2: remove-git-worktree warns, leaves a directory, and reports an empty ID

Command
ti fs-git remove-git-worktree --mount-path <mounted-path> --worktree-path <worktree-path>
Actual behavior

A clean removal prints a warning and still exits 0:

warning: could not remove empty worktree root ...: directory not empty

The empty directory is left on disk, and the result JSON reports an empty workspace_id,
which is the same reporting gap as problem 1. So the caller is told about a failure that is
reported as success, and cannot identify the resource it just acted on.

Problem 3: create-file-system and list-file-systems disagree on status

Command
ti fs create-file-system --display-name demo --wait
ti fs list-file-systems
Actual behavior

create-file-system reports "status": "ready". list-file-systems reports
"status": "active" for the same resource. A caller that waits for one value never sees it if
it polls the other command.

Problem 4: exit code 5 exists and is documented nowhere

Reproduction steps
ti fs delete-file-system-token --file-system-id "<fs-id>" --token-id 11111111-2222-3333-4444-555555555555
Actual behavior
ti [ERROR]: remote resource not found: DELETE /v1/tokens/11111111-2222-3333-4444-555555555555

Exit code 5, with error_category api and error_code api.not_found in
~/.ti/logs/ti.jsonl.

ti-cli-reference.md documents exit code 2 for a missing command and 130 for an interrupted
interactive configuration, and otherwise says only that failures are nonzero. No document
lists the full set. Across my local log I have observed 0, 1, 2, 3, 4, and 5 from ti fs.

A path that does not exist inside a file system returns 1 rather than 5, so the two cases need
separating in any documented list.

The request here is a decision as much as a fix: please confirm whether the exit codes are
intended to be stable, because automation that branches on them needs to know the full set.

Problem 5: on macOS over WebDAV the helper process outlives the unmount

Command
ti fs mount-file-system --mount-path ~/mnt --driver webdav
ls ~/mnt
ti fs unmount-file-system --mount-path ~/mnt
ps -eo pid,command | grep ti-drive9
Reproduction steps
  1. Mount a file system on macOS with --driver webdav.
  2. Read the mount once.
  3. Unmount, and remove the mount directory.
  4. Look for ti-drive9 in the process list.
Actual behavior

unmount-file-system reported "status": "unmounted", mount lists nothing, and the mount
directory no longer exists, yet the helper was still running hours later:

ti-drive9 mount --foreground --mode webdav :/ /Users/<user>/fix1-test

Not reproducible on Linux over FUSE, where the helper exited within about two seconds on three
consecutive unmounts. This appears specific to the macOS WebDAV path rather than to unmount in
general.

Note on version: this one was observed on 0.2.4. The other four problems in this issue were
re-measured on 0.2.7. I have not re-mounted on macOS since upgrading, so please treat problem 5
as a 0.2.4 observation until confirmed again.

Sensitive-data confirmation

No API keys, file system or Vault tokens, database credentials, connection strings, SQL, or
customer data appear above. File systems used for these measurements were deleted afterwards,
and the local user name in the process line has been replaced.

Lenguaje dominante
Go
Estrellas
3
Forks
4
Merge medio
3 d 19 h
PR fusionados (30 d)
5

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de tidbcloud/ti-cli

Todos los issues de tidbcloud/ti-cli

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.