[bug-bash] Sequential script commands leak their result into rm as implicit pipe input

Abierto
  • ¿Algo no está bien?
#281 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
75/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
azure, cli, csharp
Área
cli, databases

Línea de trabajo

Start by reading RmCommand.ExecuteAsync and its container visitor, where the issue says pipe input is inferred from commandState.Result. Trace how sequential script statements carry CommandState into rm and compare that with a standalone rm invocation. Add or locate a regression test for the script sequence; done means exact-ID dry runs return count 1 with id and etag after an earlier command, without requiring an explicit pipeline.

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

Descripción

bug bug-bash

Environment

Windows x64, CosmosDBShell 1.1.291-preview (db49321323).
Reproduced against a disposable Azure NoSQL container with partition key /pk,
using Azure CLI authentication and Gateway mode.

Setup

PowerShell setup creates a unique disposable shared-throughput database
(400 RU/s), an Items container partitioned by /pk, and one synthetic item.
No existing data is required. Set the three account environment variables first:

foreach ($name in @('COSMOS_ENDPOINT', 'AZURE_SUBSCRIPTION_ID', 'COSMOS_RESOURCE_GROUP')) {
    if ([string]::IsNullOrWhiteSpace([Environment]::GetEnvironmentVariable($name))) {
        throw "Set $name to an authorized test account value before continuing."
    }
}
$package = "$env:USERPROFILE\.dotnet\tools\.store\cosmosdbshell\1.1.291-preview"
$shell = Join-Path $package 'cosmosdbshell.win-x64\1.1.291-preview\tools\net10.0\win-x64\CosmosDBShell.exe'
& $shell --version
$connection = @(
    '--connect', $env:COSMOS_ENDPOINT,
    '--connect-azure-cli', '--connect-mode', 'gateway',
    '--connect-subscription', $env:AZURE_SUBSCRIPTION_ID,
    '--connect-resource-group', $env:COSMOS_RESOURCE_GROUP,
    '--output', 'json', '--quiet'
)
$work = Join-Path ([IO.Path]::GetTempPath()) ('cosmos-rm-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $work | Out-Null
Set-Location $work
$db = 'BugBash_Rm_' + [guid]::NewGuid().ToString('N')
& $shell @connection -c "mkdb $db --scale=m --ru=400"
if ($LASTEXITCODE -ne 0) { throw 'Fixture database creation failed; stop.' }
& $shell @connection --database $db -c 'mkcon Items /pk'
if ($LASTEXITCODE -ne 0) { throw 'Fixture container creation failed; stop.' }
'[{"id":"safe-a","pk":"p1","count":1}]' | Set-Content -Encoding utf8 .\seed.json
& $shell @connection --database $db --container Items -c 'import seed.json --concurrency=1'
if ($LASTEXITCODE -ne 0) { throw 'Fixture import failed; stop.' }

Repro

Create and execute the exact failing script:

@"
cd /$db/Items
rm safe-a --key=id --partition-key=p1 --dry-run > preview.json
"@ | Set-Content -Encoding utf8 .\repro.csh
& $shell @connection -c 'repro.csh'
$previewExit = $LASTEXITCODE
Get-Content -Raw .\preview.json
"Exit code: $previewExit"

There is no pipe operator.

Expected

The exact-ID dry run should independently read the existing item and return
count 1, id "safe-a", partitionKey "p1", and the current etag.

Actual

The process exits 0 and preview.json contains:

{"type":"item","count":0,"dryRun":true,"partitionKey":"p1"}

The item still exists. Running the same rm command as the sole command in a
fresh invocation returns count 1 with id and etag.

Working control: run the same exact-ID dry run as the only command, selecting
the target through startup options instead of a preceding cd:

& $shell @connection --database $db --container Items -c 'rm safe-a --key=id --partition-key=p1 --dry-run'

Actual: count 1, id "safe-a", partitionKey "p1", and the current etag.

A second exact script variant also demonstrates the leak:

@'
print safe-a p1 > before.json
rm safe-a --key=id --partition-key=p1 --dry-run > after-print.json
'@ | Set-Content -Encoding utf8 .\after-print.csh
& $shell @connection --database $db --container Items -c 'after-print.csh'
Get-Content -Raw .\after-print.json

Here count is 1, but id and etag are absent. The prior point-read result is
incorrectly interpreted as piped input, bypassing exact-ID preview behavior.
An automation step that subsequently reads preview.etag therefore fails.

Controls and impact

  • The point read confirmed the item exists.
  • A fresh single-command preview returned count 1 and the current etag.
  • Explicitly clearing the previous result with a helper script containing only
    return, between cd and rm, restored count 1, id, and etag.
  • A separate single-command deletion using the verified ETag deleted exactly
    one item; a subsequent point read confirmed it absent.
  • These controls distinguish the bug from missing fixture data or failed import.
  • This can silently turn script deletion/preview steps into no-ops or remove
    fields needed by ETag-protected automation. No unintended deletion was observed.

Investigation lead

RmCommand.ExecuteAsync and its container visitor infer pipe input solely from
commandState.Result != null. Script execution carries CommandState between
sequential statements, allowing an earlier cd/print result to satisfy that test
without an explicit pipeline. Exact-ID mode is bypassed when hasPipeInput is true.

Workaround: run the exact-ID operation in a separate invocation, using startup
database/container options rather than a preceding cd statement.

Cleanup

The failing operations above are dry runs and delete no items. Delete only the
database created by the setup commands when finished:

& $shell @connection -c "rmdb $db true"

The databases used during the original tests were deleted and independently
verified absent through Azure Resource Manager. No product fix was implemented.

Lenguaje dominante
C#
Estrellas
4
Forks
7
Merge medio
2 d 2 h
PR fusionados (30 d)
24

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 Azure/CosmosDBShell

Todos los issues de Azure/CosmosDBShell

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.