Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Chore] Revise the CLI flags introduced in 0.12.0

Abierto
  • ¿Algo no está bien?
#14,168 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
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, java, markdown
Área
cli, documentation

Línea de trabajo

This is a tracking parent; its concrete flag decisions must be recorded in the issue body, and each rename, merge, or removal becomes a separate leaf issue. Begin with the named packages under pkg/cmdsetup, banyand, and bydbctl/internal/cmd, then compare their flag registrations with the two flag reference pages and docs/operation/upgrade.md. Done means the review decisions and executable checks are defined for every flag; implementation is not assigned to this parent.

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

Descripción

chore CLI database

Summary

0.12.0 shipped a batch of new command-line flags. They went into the release without a single review pass over their names, types, defaults, per-role coverage, and documentation. This issue marks that review as outstanding work: revise the flags introduced in 0.12.0 before the 0.12.0 milestone is considered settled.

This is a tracking parent, not an implementation contract. It owns the completion criteria below. The review pass it asks for decides the concrete changes; every rename, merge, or removal then becomes its own executable leaf issue. Do not queue this issue for automated implementation.

Boundary

The CLI flag contract of the shipped binaries:

  • banyand standalone, banyand data, banyand liaison — the flags each role accepts, their types, defaults, and help text.
  • bydbctl data export — the flags the export command accepts, their types, defaults, and exit codes.

What a caller may rely on: a flag name, its type, its default, and the wording of its help text. What stays free to change without an issue: the implementation behind a flag, and the feature the flag configures.

Flags in scope

The surface added in this release, to be confirmed against the release diff when the review pass starts:

Server (banyand):

  • --bydbql-plan-cache-size, --bydbql-plan-cache-max-bytes, --bydbql-plan-max-compiles, --bydbql-plan-max-in-flight
  • --stream-export-snapshot-path, --measure-export-snapshot-path, --trace-export-snapshot-path, --property-export-snapshot-path

Client (bydbctl data export):

  • --dry-run, --output-format / -o, --strict-coverage, --selector, --parallelism, --nodes, --plan

Requirements

  • R1. Every flag introduced in 0.12.0 has one recorded decision — keep, rename, merge, or remove — written in this issue body (edit the body; do not leave it in a comment), together with the reason.
  • R2. A retained flag's name follows the conventions of the flags around it: kebab-case, <subject>-<qualifier> shape, no abbreviation the surrounding CLI does not already use, and no name whose meaning shifts between roles.
  • R3. One knob is not spelled as several near-duplicate flags unless the issue body says why the split is required. The four --<catalog>-export-snapshot-path flags are the case in point.
  • R4. A retained flag has one documented default, equal to the code default, and a type that rejects an invalid value at parse time with a usage error — a value that means "unbounded" or "automatic" is expressed so that 0, abc, and -1 are each rejected rather than silently falling back to a default.
  • R5. A retained flag is documented in docs/operation/configuration.md (server) or docs/interacting/bydbctl/bydbctl.md (client) with the same name, default, unit, and wording as --help prints.
  • R6. A flag is registered in every role where the feature it configures runs, and banyand <role> --help lists it in each of those roles.
  • R7. A flag that is renamed or removed after having shipped in a released version is recorded in docs/operation/upgrade.md with the old name, the new name, and the behaviour change.

Acceptance criteria

  • Every requirement above is checked by something that can be run, and the check fails before the corresponding leaf merges and passes after it.
  • The final flag names and defaults of banyand standalone --help, banyand data --help, banyand liaison --help, and bydbctl data export --help agree with docs/operation/configuration.md and docs/interacting/bydbctl/bydbctl.md.
  • End to end: a node started with the revised flags answers bydbctl data export --dry-run --nodes <addr> and renders its report; the same command with an invalid flag value exits with the usage exit code and the message the issue names.
  • Per role: for each role the flag belongs to, the flag is accepted by that role's binary and rejected by a role it does not belong to.
  • Compatibility: any renamed or removed flag that shipped in a released version appears in docs/operation/upgrade.md.

Scope

  • Packages: pkg/cmdsetup, banyand/liaison/grpc, banyand/stream, banyand/measure, banyand/trace, banyand/property, bydbctl/internal/cmd.
  • Docs: docs/operation/configuration.md, docs/interacting/bydbctl/bydbctl.md, docs/operation/upgrade.md.
  • Out of scope: the behaviour of the features the flags configure (the export session protocol, the measure QL plan cache) beyond what the flag contract itself states; flags that earlier releases already shipped; any new feature.

Size audit

  • Classification: tracking parent
  • Boundary: the CLI flag contract of the banyand standalone/data/liaison binaries and of bydbctl data export — names, types, defaults, and the documentation stating them.
  • Production activation: banyand <role> --help, bydbctl data export --help, and the two flag reference pages.
  • RED test: a flag-contract test asserting each documented flag is registered on the role's flag set with the documented default; it does not exist today, and each leaf adds the assertion that fails before it.
  • End to end: bydbctl data export --dry-run against a running node, and the rejection of an invalid flag value.
  • Format/lifecycle scope: none — no persisted bytes and no wire format change; the flag contract is a CLI surface.
  • Fixtures and oracle: none; the expected values are the flag names and defaults this issue states.
  • Focused suites: make test-ci PKG=./pkg/cmdsetup ./bydbctl/internal/cmd.
  • Dependencies present on main: yes — the 0.12.0 flags are registered in pkg/cmdsetup, banyand/liaison/grpc, banyand/{stream,measure,trace,property}, and bydbctl/internal/cmd.
  • Decision: tracking parent. The review pass names the concrete changes; each rename, merge, or removal becomes its own executable leaf, ordered by dependency.
Lenguaje dominante
Java
Estrellas
25k
Forks
6.6k
Merge medio
15 h 4 min
PR fusionados (30 d)
32

Preparar el entorno

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 apache/skywalking

Todos los issues de apache/skywalking

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.